What "non-mainstream" microcontrollers do people use?

[DavidJRobertson]

Recently had the misfortune of having to make changes to assembly code for a legacy product using PSoC 1.

[tggzzz]

Recently had the misfortune of having to make changes to assembly code for a legacy product using PSoC 1.

XMOS xCORE I like having 32 cores, hard realtime performance guaranteed before execution[1], and programming in a better[2] C.

[1] none of this "measure and hope you have blundered across the worse case" rubbish

[2] added CSP constructs (as found in several newer languages) for i/o and inter-core comms, removed constructs that cause problems when parallel programming (e.g. pointer aliasing).

[alex_]

I use PIC24s everyday for applications that need to work reliably. They are really fast even running at low clock / low power compared with others because they don't have "modern" BS to deal with (looking at you STM32, Nordic, ESP...). One instruction = one clock cycle most of the time, no HAL and safeties to deal with.

Not many YT/influencer use them because they lack big numbers but you find them pretty much everywhere.

They used to be hobbyist friendly, then disappeared but they try to come back. I am initiating a friend with a 8$ dev board incl. debugger and he is getting on board quickly
https://ww1.microchip.com/downloads/aemDocuments/documents/MCU16/ProductDocuments/UserGuides/PIC24FJ64GU205-Curiosity-Development-Board-Nano-User-Guide-DS50003124.pdf

[laugensalm]

I'm very fond of the ZPU architecture (if this counts as 'microcontroller', as there is no hard silicon of it in the wild as far as I'm aware of).
It's a stack machine hybrid architecture, not to mix up with any samples from the weapon domain.

It's kinda 'niche' though, as stack machines aren't very popular, plus, arguably, the GCC port doesn't optimize very well for a non-register architecture.

It has some interesting features though that make it unbeaten in its field:
- 32 bit data path, only 14 (depending on implementation) basic 8 bit opcodes, very compact code possible (beats ARM thumb mode)
- gcc support as mentioned
- Very extendable by safety features, and/or very lean multitasking/context switching, as well as specific microcode instructions

The minimum-configured architecture is the most resource-saving one I've ever come across, with some sacrifices to speed compared to a RISC-V.
I'm using it as drop-in solution for all sorts of networked FPGA projects where data chunks need to be streamed and where tricky hardware extensions compensate for the sometimes inefficient software routines.

The microcode trickery involved in this architecture is the most interesting part, actually. Last but not least to mention the author of this brain child: Øyvind Harboe, now obviously on a new path for novel processing solutions, where hardware and software melts.

My disclaimer: I'm not affiliated, I've just written a pipelined 'next generation' with JTAG-debugger variant of it.

[JPortici]

The PIC24FJ GU series is one of my gotos: Lots of memory, fair number of peripherals, Crystal-less USB, Cheap.
Compiler is excellent, the architecture is sane, no need of configurator bullshit (the USB can be taken straight away from the MLA, and can do everything. Unlike the bullshit stack in MCC which while a continuation of the MLA is artificially constrained because they can't seem to decide how to do shit in the GUI)
FreeRTOS works if one needs that (whereas -larger- dsPICs do have problems because of how freeRTOS wants to do context switching)

[brucehoult]

I'm very fond of the ZPU architecture (if this counts as 'microcontroller', as there is no hard silicon of it in the wild as far as I'm aware of).
It's a stack machine hybrid architecture, not to mix up with any samples from the weapon domain.

It's kinda 'niche' though, as stack machines aren't very popular, plus, arguably, the GCC port doesn't optimize very well for a non-register architecture.

It has some interesting features though that make it unbeaten in its field:
- 32 bit data path, only 14 (depending on implementation) basic 8 bit opcodes, very compact code possible (beats ARM thumb mode)

I very highly doubt any bytecode machine -- especially a stack machine -- with 8 bit opcodes can beat ARMv7-M or RV32IC (or RV32EC like CH32V003) on real world code for a whole useful program.

[brucehoult]

I very highly doubt any bytecode machine -- especially a stack machine -- with 8 bit opcodes can beat ARMv7-M or RV32IC (or RV32EC like CH32V003) on real world code for a whole useful program.

I checked out https://github.com/robinsonb5/zpugcc and used the prebuilt amd64 linux zpugcc.

On my primes benchmark [1], the countPrimes() function is 297 bytes with my standard -O1, 236 bytes with -Os.

The 236 bytes for -Os is not horrible, but it's also not better than 178 bytes for RISC-V 32 bit for the 2016 HiFive1 (first ever RISC-V hardware) or 204 bytes for Thumb2 (Cortex M7, A15, A53 etc) -- and those were with -O1 not -Os.

MSP430 btw is a similarly simple ISA with just 26 instructions, but 16 registers and 2-address instructions. It uses 264 bytes for countPrimes() as written, despite it needing two instructions to manipulate the 32 bit numbers as it's a 16 bit ISA. Dropping the variables down to 16 bit types makes that 158 bytes.

[1] http://hoult.org/primes.txt

[laugensalm]

With due respect, prime calculation is not a very representative real world example. Plus, the zpugcc does not optimize very well, apart from some linker relaxation that is occuring later. But even then, it turns out compact enough, see attached image for a typical remote control application. MSP430 wins the race, obviously, this is also due to better compiler optimization.
GCC just can't handle stack machines well, even with LLVM, this is a bit painful. The retargeting LCC does best, but there are maintenance issues.
In this example, the binary has crappy entropy due to many 32 bit immediate loads which consume 5 bytes on this architecture.

[brucehoult]

With due respect, prime calculation is not a very representative real world example.

It correlates well with other things. The exact task is not important, what is important is to have a similar mix of calculation, loads and stores, control logic. The main reason to use primes calculation is to give small code that a compiler is not going to be able to optimise away.

Plus, the zpugcc does not optimize very well, apart from some linker relaxation that is occuring later.

Then that is a black mark against ZPU as no one is going to program any significant application in assembly language.

I looked at the code size in a ready to run executable, so any linker relaxation had already been done.

But even then, it turns out compact enough, see attached image for a typical remote control application. MSP430 wins the race, obviously

It does, but I don't see why it's "obviously". MSP430 has a number of features that make its code density worse than it could be in a more complex ISA, including all branch offsets and all offsets from pointers and all constants for 16 bit arithmetic (except -1, 0, 1, 2, 4, are a full 16 bits in the code. Many competing ISAs include 5, 8, or 12 bit constants and offsets.

Also I notice the Thumb listing in the table is ARMv5, which is quite limited compared to ARMv7 or RISC-V, especially in only being able to conveniently work with 8 registers.

I would think Thumb2 and RISC-V would both be smaller than ZPU on this "netpp" code.

this is also due to better compiler optimization. GCC just can't handle stack machines well

As an ISA designer and compiler engineer I can't see any reason why this would be true. GCC does just fine with the register-poor i386 where many functions have most of their variables on the stack.

ZPU's STORESP_n and LOADSP_n provide quick and easy access to the top 32 stack elements and ADDSP_n is also very convenient to add any of the top 16 elements in the stack to TOS.

32 local variables -- essentially virtual registers -- is really quite generous.

ZPUs code size suffers from being a STACK MACHINE with byte-oriented instructions because something like x += n needs IM_n; ADDSP_x; STORESP_x if x is one of the top 16 variables, or LOADSP_x;IM_n;ADD;STORESP_x for variables 16..31, which are 3 and 4 bytes respectively while Thumb and RISC-V and M68000 can all add or subtract a small constant with a 2 byte instruction -- and 8086 can INC/DEC with a single byte.

There are numerous other examples. Stack machines gain over register machines only in the case of complex arithmetic expressions, and the fact is that most statements in most programs are very simple.

This is not a question of a compiler not being clever enough to optimise stack code. A human can't do any better.

In this example, the binary has crappy entropy due to many 32 bit immediate loads which consume 5 bytes on this architecture.

32 bit immediate loads use 6 bytes in Thumb (PC-relative load from a constant pool) and 8 bytes in RISC-V (LUI;ADDI). So that's not it.

[laugensalm]

You're welcome to dive into the GIMPLE internals to get more out of it, but when you look at GCC emitted ZPU assembly, you will find scenarios where a human does better. Not that I'm saying it's worth it. The code density is good enough as the numbers show, it could just be better - in theory.
I've also run RISC-V (and compressed) on that library, I'm afraid it doesn't get any more compact than the MIPS/MIPS16 numbers in the slide.

Just a sidenote: Where the thumb code performs better in this case is the peripheral access, like `*((uint32_t *) 0x84000000) = x` when using a base address with offsets, as CMSIS uses structs translating nicely into relative addressing. This is where the 5 byte immediates on the ZPU cost more, let aside taking 5 cycles. With optimized C code, the ZPU would probably beat the msp430 compactness in this particular case, but I'm not aiming at a code density contest, so...

[NorthGuy]

I don't think code compactness plays any role in MCUs. If you use a big out-of-order CPUs then code size directly translates to performance because smaller code fits in caches and loads faster. For MCUs, you typically would need other kind of performance - where you need to do something really fast, you need an ISA that allows you to do this, as well as an ability to take out factors such as cache delays and bus collisions which has a potential to slow things down. But nowadays even this may not matter because you can do things with periphery and DMA, thus making the CPU speed totally irrelevant.

[brucehoult]

I don't think code compactness plays any role in MCUs. If you use a big out-of-order CPUs then code size directly translates to performance because smaller code fits in caches and loads faster.

I frequently hear the exact opposite argument! It goes something like this: "The customer has 32k of flash stuffed to the brim with functionality in their existing C-M3 product -- if RISC-V code is 10% bigger then they'd have to increase their BoM with a 64k flash part (if it even exists), or remove features."

That was back in the early days almost 10 years ago when RV32IMAC code was in fact a little bigger than Thumb2. Now with a few more extensions as e.g. seen in the Hazard3 core in the RP2350, RISC-V code is more compact than Cortex-M33 code (except for floating point, which isn't implemented in Hazard3 ... or in the previous RP2040's C-M0 either).

So now the story is that code compactness is not important in MCUs.

When Apple moved from ARMv7-A to ARMv8-A they increased the L1 icache from to 32KB in A6{X} to 64KB in A7, quite likely because of the adverse effects of the poor Aarch64 code density.

Intel stayed with 32KB L1 icache for their P cores as recently as 13/14th gen.

Personally, I think code size matters everywhere -- not the last 1% or even 10%, but 30% is quite significant. If the cost of having dense code is small then why not have it?

[radiolistener]

Microchip PIC was THE microcontroller of choice way back, but now you hear practically nothing about them. Meanwhile, they still go into a zillion items.

Yeah, I remember — the PIC16F84 was the very first microcontroller I used for a bunch of home pet projects: a DTMF decoder, a caller-ID receiver, a portable EEPROM chip editor with display and keypad, a thermometer, and many other little gadgets. Writing code for it was pure joy — the instruction set was simple, and the configuration was straightforward. It was cheap and easy. Nowadays, I don’t even remember its instructions anymore. 

[cunningfellow]

Writing code for it was pure joy

That is not something I ever would have thought I would hear someone say about the 12 bit PICs.

I went from Z80 to 68K to x86.  When I started with x86 I thought "well at least it can't ever get worse"

But then I discovered PIC 16F and 12C

The day I got given an AT90S2313 was a joyous day.  I never made a new project with a PIC ever again.

[radiolistener]

I went from Z80 to 68K to x86.  When I started with x86 I thought "well at least it can't ever get worse"

But then I discovered PIC 16F and 12C

I’m not sure why, but the PIC16F84 felt remarkably simple to me back then. I had started with the Z80 and was already writing code for x86 at the time, so perhaps that perspective helped. Before that, I had some experience with the 8048 and 8051 families — I never really liked those, though I didn’t have them for home experiments. The PIC16F84 was my first real “toy” for personal projects.

I remember that right after buying it (it was about 1997), I built an RS232 programmer in just one evening, read the datasheet, and wrote my first programs (blink and beeps) — which, to my surprise, worked with no issue on the first try. I distinctly recall how simple and intuitive the instruction set felt, even though I can’t remember any of it now It had very little memory, but I still managed to fit quite a complex menu into it, including a text editor on an LCD display. For the caller-ID project (was sent with DTMF-like sequence), though, I ran just a bit short on memory, even after optimization, and had to simplify some of the functionality.

Later I finding the instruction set of the ATtiny noticeably more complicated, and I even wondered why they couldn’t have made it as straightforward as the one on the PIC16F84. And later, when I switched to the MSP430, I had the same impression — the PIC16F84 still felt much simpler. That’s how I remember it — as the simplest and most enjoyable MCU I’ve ever worked with. 

[cunningfellow]

Ah - there is the difference.  You never got to experience the luxury of having 32 registers in the 68K.

32 registers in the AVR meant you didn't always have to be shuffling values around.

The PIC was a little bit better at I/O twiddling until later AVR got the pin toggle registers.

You are not going to get any arguments from me about 8051 not being any fun

[5U4GB]

MSP430 btw is a similarly simple ISA with just 26 instructions, but 16 registers and 2-address instructions. It uses 264 bytes for countPrimes() as written, despite it needing two instructions to manipulate the 32 bit numbers as it's a 16 bit ISA. Dropping the variables down to 16 bit types makes that 158 bytes.

The downside is that you then have to work with an MSP430.  Not quite as bad as non-PIC32 PIC, but still pretty awful to work with.

[5U4GB]

the PIC16F84 was the very first microcontroller I used [...] Nowadays, I don’t even remember its instructions anymore. 

That would be due to traumatic amnesia.

[laugensalm]

The downside is that you then have to work with an MSP430.  Not quite as bad as non-PIC32 PIC, but still pretty awful to work with.

The processor or the tools? Apart from the early series brownout detection bugs and occasionally stuck flash breakpoints, I never had any issues - with the OpenSource tools (gcc, mspdebug/gdbproxy). I have seen a horrible mess based on IAR though that was chucked into the corner to begin with.
I would consider msp430 pretty much mainstream, though. Although, not everyone using it was made aware of the DEC PDP11.

[5U4GB]

The processor.  I think it was a combination of two things, firstly having come from the 68K and PPC working with the MSP430 seemed incredibly constricting, and secondly it seemed to involve an inordinate amount of bit-fiddling and moving magic values into and out of registers and if you didn't get it exactly right things broke.  It was like going from a VAX back to a PDP-11.  Sure, the PDP-11 was nice enough by itself (and at least it had a multiply instruction), but not if you'd started with a VAX.  The MSP430 seemed more like a microsequencer for running the peripherals than something you'd want to do serious programming on.

Oh, and an aside for people who think the 12-bit PICs are a pain to work with: TMS320, specifically the 32010/32020 family.

[dmendesf]

CCS compiler made working with any PIC trivial. It hides bank switching, has good libraries and produces decent code (albeit not the way you are accustomed to). As there's no stack to push/pop functions arguments and returns it uses all the memory as registers and keeps track of what functions use what memory positions. If function A never calls function B and vice-versa their variables can share the same positions. Other strange optimizations are used to bypass the Harvard architecture, but overall they work well (but people keep complaining that it's not "ANSI C"... well, you can't have function pointers in a sane way, nor relocatable code... but it's a damn small microcontroller, just live with it.

[SiliconWizard]

I don't think code compactness plays any role in MCUs. If you use a big out-of-order CPUs then code size directly translates to performance because smaller code fits in caches and loads faster.

I frequently hear the exact opposite argument! It goes something like this: "The customer has 32k of flash stuffed to the brim with functionality in their existing C-M3 product -- if RISC-V code is 10% bigger then they'd have to increase their BoM with a 64k flash part (if it even exists), or remove features."
(...)
Personally, I think code size matters everywhere -- not the last 1% or even 10%, but 30% is quite significant. If the cost of having dense code is small then why not have it?

Yes. A hard statement such as "I don't think code compactness plays any role in MCUs" looks pretty odd. Obviously, like with anything engineering, it all depends on the constraints and requirements. If the expected max code size is much smaller than the available flash size on a given MCU, it can certainly be a completely secondary consideration, but otherwise it can be critical.

Even when it's not critical, I agree with the general benefit of using more efficient solutions when they're available at a cost compatible with the development budget. It applies both to code size and code efficiency. We can refer to the recent thread about software quality. Even when the benefits are not obvious upfront, they most often turn out beneficial in the long run. I haven't witnessed a single case where they weren't.

Lean, please. Say no to bloat.

[westfw]

people who think the 12-bit PICs are a pain to work with

Note that the (in)famous PIC16x84 is a 14bit PIC, which is much less of a pain to work with than the 12bit PICs like the 16C54.

Say what you want about the 8bit (ALU) PICs - but there have been substantial incremental improvements from "baseline" to "midrange" to "enhanced midrange" to PIC18...

Also, there seems to substantial differences between "unpleasant to program in assembly language" vs "frustrating to program in a HLL."

[brucehoult]

Also, there seems to substantial differences between "unpleasant to program in assembly language" vs "frustrating to program in a HLL."

You don't need much of an ISA if you're just implementing an FSM. But "supports C" is all or nothing -- standard code either works or it doesn't. You only actually need about 10 simple RISC instructions to efficiently support C.

As 8 bit accumulator machines go, 14 bit PIC is better than 8080/z80 in that it has 128 registers (plus W) vs 6 on 8080, 10 on z80. And you can add random register A to random register B with two instructions vs three on z80.

- Z80 8 bit instructions, 6 registers. (prefix needed for 10)

- 12 bit PIC, 32 registers

- 14 bit PIC, 128 registers

- 6502, 256 pseudo-registers with 16 bit instructions

[SiliconWizard]

I did program 8-bit PICs in C starting with the PIC18F. I used PIC16F MCUs before that, but used assembly with these. It wasn't so much a problem of compiled C code efficiency on the 16F, but the limited available flash which would fill up very quickly with compiled C. Otherwise, on the 18F series, C was certainly usable.