# Use cases for RAM-less microcontrollers

In a different question around a specific microcontroller (ATtiny12 - datasheet) I came to ask myself: What are the intended use cases for such devices?

Does it target the segment: Too "complex" for a small PLD/CPLD and too "simple" for a FPGA/"conventional" microcontroller?

I have problems coming up with use cases to form a better picture of this type of microcontroller in my mind.

If you have used these devices, what for?

What is the intended use case?

Why not use an 8-bit controller with RAM in a, e.g., 8-pin package, or maybe even a 32-bit core controller in a 10-pin package (seen those)?

What should it not be used for, besides "fitting the bill"?

EDIT 1:

As so many answers were given and the question was of rather "open-type", i would like to do a summary:

1. These Devices are used in high volume, low complexity designs were cost is a prime objective and dedicated ASICs do not exist or are too power hungry. (Remotes, Toys, Tactile/LED HMI)

2. For low power applications or stand-by operation blocks of a design. (SMPS, Stand-By with main controller powered down)

3. For mid-volume applications were cost is sort of an objective and the required functionallity is not available in a ready-made ASIC. (E.g. ADC sampling with some math and giving an ISR to a controller in sleep-mode)

4. I also deduced that, if not only cost, but also time-to-market is an objective, these devices can be used to implement low complexity functionality faster compared to a "custom ASIC".

• You can do a lot without RAM. Jan 13 at 8:01
• I am not sure if questions asking for opinions are OK here, did you check for example this help page? Jan 13 at 8:14
• "I have problems coming up with use-cases to form a better picture of this type of uC in my mind." When something gets that cheap you usually don't even know it's in the product. Think...throw-away $1-$5 throw away toys, gadgets, and items. Jan 13 at 18:24
• That's not RAMless. That's a CPU with 32 bytes of RAM. Yes, it's less RAM than what I've personally used before (The smallest I've used is 68 bytes of RAM) but it's more memory than what I've needed in some applications. That's basically 32 variables. Look at a simple script you've written. I'm sure you've had programs with around 10 variables or less. 32 is a lot in comparison. Jan 14 at 12:30
• @slebetman, Whether or not those 32 bytes should be called "RAM" is a matter of opinion. They are, in fact, the processor's general purpose registers, but one quirk of that particular instruction set architecture is that the GP registers are overlaid over the first 32 bytes of addressable "data space." Jan 14 at 15:19

It is very low power.

The chip does have RAM: 32 registers that are preserved over power-down mode, which draws less than 1µA. It also has EEPROM.

You'd typically use a chip like this for data logging (wake up every minute, take an analog reading, write to EEPROM, go back to sleep) or as a power management controller (turn regulator on on button press, turn regulator off on long button press or a few milliseconds after a poweroff command from the main device).

FPGAs and CPLDs draw a lot more power for such an application.

• Is this generally true, as CPLD/FPGA families exist that address super-low power requirements? Jan 13 at 8:15
• Yes, low-power CPLDs are still around 20µA, and I'm not even sure if that includes keeping 256 bits of state. FPGAs are way more hungry. There are applications that combine a low-power CPLD with an ATtiny to get a higher pin count. Jan 13 at 8:24
• We should note that this particular chip is not very impressive any more. Just few years later we have the Attiny10 with even lower power (and a bit of RAM) and for about the same power there's the much larger Atmega328PB. Jan 13 at 10:23
• 1 uA with only registers is not low power, not nowadays. An STM32L0 can do 500 nA sleep while keeping 2 kB of SRAM... Jan 13 at 17:21
• Back in about 1982 I saw a demo of a decoder for the UK national time radio time signal [en.wikipedia.org/wiki/Time_from_NPL_(MSF)] that was made using a Z80 processor, EPROM, radio receiver circuitry and an alphanumeric display. There was no RAM at all. The Z80 was chosen because it had enough processor registers to hold the data required for the task in hand.
– uɐɪ
Jan 16 at 10:19

Such very low end microcontrollers are pretty much intended exclusively for high volume commercial consumer electronics where the price is everything and one can compromise a lot about quality and best practices. Historically they were also common for low current consumption applications.

Although I've used similar ones for "PLD replacement", as in very simple GPIO logic, essentially just instead of a bunch of 74HC logic gates. These were historically replaced by a SPLD, some very simple, VHDL programmable logic with EPROM. With the advent of flash memories, low end MCUs were about as cheap to use, but easier to re-program and also relatively much more powerful.

It doesn't make much sense to use 8 bit MCUs for low current applications any longer though. Most modern Cortex M0 32 bitters come with a built-in low speed RC oscillator for low current applications. When speaking of current consumption, it's pretty much just the clock speed that matters, far more so than architecture or hardware peripherals. What draws current is internal transistors toggling on/off repeatedly based on the system clock.

The incredibly common design mistake is to stare at the minimum current consumption by the MCU, instead of the average. 8-bitters are pretty horrible when it comes to code efficiency vs Ampere. If you have some C code like my_uint32a / myuint32b, then an 8 bitter will need hundreds of instructions to finish it. Whereas a 32-bitter might finish the calculation in a single instruction. So the 32-bitter in this example draws some hundred of times less current for that calculation, even if it happens to have a higher idle current than the 8 bitter.

The point is not about having no RAM. The point is, you can use it in any application where you need some kind of chip that does very simple things cheaply, but such an ASIC does not already exist or it makes no sense cost-wise to do an ASIC.

As an example, all flashlights, bike lights, camping lights, festive lights etc, with one pushbutton to turn the light on/off and select different brightnesses and blinking partern modes (including a SOS morse code sending).

Or an application where you have some chip or module and you just need to initialize it to do something or go to correct operating mode at boot.

• The question was not about ASIC, but CPLD/FPGA. Anyway, even these are commonly more expensive than small controllers. Jan 13 at 12:15
• really we should say the point is you don't need the RAM, and you still want the cheapest chip possible (which means one without RAM) Jan 13 at 13:54

I've used an ATTINY10 like this, and it's low pin count and very low power.

It can't do much, it only fits 1k of FLASH, that's less than 1 thousand instructions. You can barely compile any C code for it without exceeding the registers or flash.
Put it this way, a function call uses basically all the ram you have.

But, when you need a small chip for a very simple function these chips are great. In my case we needed a custom battery monitoring LED/Alarm, and this chip fits the bill. You can also use these as standby controller for capactivie touch and features like that where keeping the big MCU online just draws too much power.

I mean: Idle Mode 25µA at 1MHz and 1.8V.

• That's exactly how I used ATTiny12 as well - battery monitoring as part of a smart charger. Wake up, measure, give an interrupt pulse on GPIO if above or below threshold, go sleep. Jan 14 at 15:00

One application is IR TV remotes. There are ASICs that are designed for this, but maybe your design has some LEDs and the ASICs don't quite do everything you want. 32 bytes of "ram" is plenty to play back hard-coded IR sequences, and to make things better this is available as a 5v chip, so it can drive LEDs and and an IR transmitter with nothing more than a few resistors.

First off, such MCUs are almost used exclusively where assembly-only is involved. I almost never use them in combination with a C compiler.

Second, such MCUs are often used for cost-sensitive applications and where only a small number of I/O pins are needed, but where some internal state and processing makes sense.

Third, where power consumption matters, as well.

In short, where low cost, small pinout and size, and low power makes sense and where using only assembly code also makes sense for the application space.

(It's also the case that power-up configuration is relatively simple for these MCUs -- as compared to the far more complex [and varying with each stepping of the MCU design] required I/O configuration.)

It's possible to create a small, real-time operating system for these devices. Multi-threaded and per-process messaging, as well as sleep and semaphore queues, are possible. But it requires care and thought and all of it still must be in assembly. (Though I have done it in C using carefully crafted C code.)

If a sophisticated operating system is required, or complex libraries or 'stacks' developed by 3rd parties are involved, then these kinds of MCUs are likely not in consideration.

There isn't much qualitative difference between a microcontroller with a handful of registers and 16 bytes of "RAM", versus one with 32 registers and zero bytes of RAM. Programmable logic devices are rather expensive for the amount of functionality they provide because they require that the memory which holds their configuration be interspersed with the logic it controls. By contrast, the code storage for a microcontroller can be packed much more tightly. There is consequently no size of programmable logic device which would be smaller and cheaper than a simple 4-bit or 8-bit micro with a dozen or so bytes' worth of register or RAM storage. For many tasks, an 8-bit micro wouldn't require much more code than a 16-bit or 32-bit micro, but would require less code than a 4-bit micro. In many cases, the size of the extra cost storage needed when using a 4-bit micro would outweigh any savings in the size of the rest of the CPU, and thus 4-bit micros have largely fallen by the wayside.

In the 1970s and 1980s, the cost to set up a custom mask for a mask-programmed four-bit micro would have been a tiny fraction of the cost to produce a fully custom chip. It thus made sense to use microcontrollers with mask ROMs, which occupy a small fraction of the die space per bit of field-programmable ROM. When using mask ROMs with a small area per bit, it made sense to minimize the amount of space used for the rest of a microcontroller, even at the expense of increasing the amount of ROM required. Today, however, the kinds of applications that would have sufficient production volumes to justify mask-programmed controllers often have sufficient volumes to justify fully custom chips, and when using field-programmed ROMs the break-even point between four-bit and 8-bit controllers shifts toward 8-bit ones.