TI MSPM0C1104

24MHz ARM CORTEX-M0+ MCU WITH 16KB flash, 1KB SRAM




MSPM0C1104S8YCJR 1.6 mm x 0.86 mm



MSPM0C1104SDSGR 2 mm x 2 mm
Price: US$0.53

Reference: https://www.electronicsweekly.com/n...ld-worlds-smallest-mcu-and-its-32bit-2025-03/

 

Don't sneeze.

 

 

Man ... imagine the things one could've done with 1kb SRAM back in 1983 !!!

 

It is hard for me to imagine an application for a processor with so few pins and so little RAM needing a 24MHz 32-bit processor.

 

Hearing aid.

 

Hearing aid.

Too little RAM to run any serious DSP algorithm.

 

It is hard for me to imagine an application for a processor with so few pins and so little RAM

I did a number of projects with 16 bytes of RAM and 5 or 6 pins.

The dumbest "computer" I used went into those blinky ball toys. It is a micro sequencer. It has 16/32/64 ROM and zero RAM. It simply steps through ROM, does simple conditional jump instructions, has a counter/timer.

 

I did a number of projects with 16 bytes of RAM and 5 or 6 pins.
View attachment 362828
The dumbest "computer" I used went into those blinky ball toys. It is a micro sequencer. It has 16/32/64 ROM and zero RAM. It simply steps through ROM, does simple conditional jump instructions, has a counter/timer.
View attachment 362829

But did they need a 32 bit 24MHz processor? That is the mismatch I am pointing out.

 

It is hard for me to imagine an application for a processor with so few pins and so little RAM needing a 24MHz 32-bit processor.

Need, no but it's what you know. ARM gotta ARM.

The chip has very limited DMA. That's a show stopper for the things I build.

The DMA in these devices support the following key features:
• 1 DMA transfer channel
• Direct peripheral to DMA trigger is supported only from ADC.
• Byte (8-bit), short word (16-bit), word (32-bit) and long word (64-bit) or mixed byte and word transfer
capability
• Transfer counter block size supports up to 64k transfers of any data type
• Configurable DMA transfer trigger selection

https://www.ti.com/lit/er/slaz753c/slaz753c.pdf?ts=1769545522830&ref_url=https%3A%2F%2Fwww.ti.com%2Fproduct%2FMSPM0C1104%3Fhqs%3Depd-msp-procbr-mspm0_small-pr-pf-ew25-wwe
This document describes the known exceptions to the functional specifications (advisories).

The SP, UART and several other modules have some nasty errata.

 

I wonder if an external SRAM chip could be used to extend the memory? The datasheet does say that it supports SPI interface peripherals (albeit limited to 12Mbps). Then again, for that matter, I guess you could just go with an MCU with more memory....

 

That is the mismatch I am pointing out.

I agree.
I remember a 32bit 8-core ARM microcomputer that had no smart IO blocks. If you wanted a UART or more, you dedicated one core to that. Another core might become several counter/timers. The idea was that you had so much CPU power that you can make "smart hardware in firmware".
When you have silicon that will run 24mhz why not? It is hard to slow down silicon when everyone wants it to run faster.

 

I worked with an outfit that did a controller for a tea kettle with an 8 pin Motorola microcontroller. It used serial to parallel to gain enough outputs for a 3 digit LED display. It had one analog input that was used to read the kettle temperature. The guys that programmed it came up with an algorithm that would read the rise in temperature to determine if the kettle was underfilled or empty. All in all, it was pretty impressive.

 

You don't use a pocket knife if it is a sledge hammer that you need.
There are hundreds or thousands of other MCUs that will get the job done for whatever situation you might have.

 

You don't use a pocket knife if it is a sledge hammer that you need.

MSPM0C1104SDSGR = $0.58 @ 1
PIC10f200t-I/OT = $0.58 @ 1
They are the same price at Digikey.com

 

Some passive devices can be more expensive than $0.58

 

Umpty years ago the "death" of 8- and 16-Bit microcontrollers was proclaimed. Still has to happen.
This fancy uC is great for those programmers that only know ARM (and maybe IA64).

Some time ago I developed a duty-cycle-to-frequency converter (input adapter for a PLC that could evaluate frequencies but not duty-cycles). Used some 8-Bit PIC16F (latest generation) that could do the trick with 1 % precision even without a crystal. 4 pins would have been sufficient, with 8 pins I could even debug on the final hardware.
RAM and flash usage? Negligible, although the software being implemented in C. And the PICs have something the ARMs lack: powerful peripherals: capture/compare plus a configurable clock generator didn't call for more than initialization plus a minimum of calculation.
Another project has been a SENT-to-analog converter: the smallest package that provided 2 (redundancy required) DAC channels (5 pins would have basically been sufficient, IIRC I ended up with a 14 pin package), no crystal and 8 MIPS. This one needed around 128 Bytes RAM (64 Bytes just to store the capture events required) and a tricky signal evaluation that could go with little RAM. No need for 32 Bits although 16 MIPS would have been great.

 

Don't sneeze.

sneeze!? i'd be afraid to breathe or blink. if it goes missing nobody would be able to find it.
it would be nice to use it for hand soldering olympics.

 

Related to the component’s tiny size, I’ve an anecdote. (Sorry for hijacking the thread)

I was employed at an automotive Tier-1 electronics module manufacturer. One of my main responsibilities was managing a large group in charge of failure analysis, FA. Those of you who have worked for an automotive supplier, DO KNOW the amount of pain that auto manufacturers can extract from their suppliers.
We once received a failed module where the vehicle’s high priority CAN busses were routed to, which had its severity-class labeled as a major loss of vehicle functionality. Severe enough to get many VP’s and Director’s unmitigated attention.
Long story short: the failure was traced to a subminiature IC, which was desoldered and being prepared to be sent back to the semiconductor vendor for analysis As we were doing this, it was accidentally dropped to the floor!
Several of us got on our hands and knees and desperately looked for it. I can attest to the immense amount of debris that can accumulate below a test bench.
After a couple of hours sifting through dust bunnies we still couldn’t find it, and in a gloomy mood we went home, knowing that we would catch hell next morning.
Back home, after dinner and as I was undressing to take a shower, a slight twinkle from one of my socks caught my attention. Upon closer inspection, with joy I realized that it was the lost device!!

Moral of the story; use PDIPs exclusively