Use cases for RAM-less microcontrollers

Question

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".

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.