What "non-mainstream" microcontrollers do people use?

[JPortici]

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.

XC8 which has all of that is also C99
 
That's why we abandoned mikroe and CCS when XC8 came out (which yeah, started as a continuation of the hitech compiler but is now its own product)

[tggzzz]

You don't need much of an ISA if you're just implementing an FSM.

If you mean receiving an event, changing an output, and changing state, then yes I agree.

But in general more is needed to create an event from an arbitrary source, and computation to determine the outputs and next state.

[brucehoult]

You don't need much of an ISA if you're just implementing an FSM.

If you mean receiving an event, changing an output, and changing state, then yes I agree.

But in general more is needed to create an event from an arbitrary source, and computation to determine the outputs and next state.

It's unlikely to need:

- KBs of RAM

- calls through function pointers / C++ virtual functions

- recursion

- function calls more than 8 levels deep

- setjmp/longjmp

.. all of which are required for C.

[westfw]

14 bit PIC is better than 8080/z80 in that it has 128 registers (plus W) vs 6 on 8080

That doesn’t sound quite right…
Oh!   If you count the data area as “128 registers”, or even the less than that that don’t have special functions, there is nothing left to call “ram”…
And no addressable stack, either.

[brucehoult]

14 bit PIC is better than 8080/z80 in that it has 128 registers (plus W) vs 6 on 8080

That doesn’t sound quite right…
Oh!   If you count the data area as “128 registers”, or even the less than that that don’t have special functions, there is nothing left to call “ram”…
And no addressable stack, either.

32 of them have special uses, yes, so 96 for general use.

- Microchip calls them registers not RAM. In some ways that's an arbitrary distinction, especially with on-chip SRAM, but ...

- the address is built into each instruction as a literal, so they act more like names than numbers. 8080 has A,B,C,D,E,H,L ... 8051 has A,R0,R1,R2,R3,R4,R5,R6,R7 .. what is the conceptual difference, really?

[tggzzz]

You don't need much of an ISA if you're just implementing an FSM.

If you mean receiving an event, changing an output, and changing state, then yes I agree.

But in general more is needed to create an event from an arbitrary source, and computation to determine the outputs and next state.

It's unlikely to need:

- KBs of RAM

- calls through function pointers / C++ virtual functions

- recursion

- function calls more than 8 levels deep

- setjmp/longjmp

.. all of which are required for C.

That is a separate issue: I didn't (and wouldn't) claim that you need C when programming in FSMs. Hells teeth, I unknowingly invented/implemented an FSM in assembler before C even existed!

But for the processing you will typically need many of the instructions that are also useful for C.
And calls through a 2D table function pointers are an excellent (visible, exhaustive, modifiable) way of dispatching on the combination event+currentState.

[temperance]

Hells teeth, I unknowingly invented/implemented an FSM in assembler before C even existed!

Unless you are maybe over 2000 years old you should remove "invented".

https://en.wikipedia.org/wiki/Hero_of_Alexandria

[tggzzz]

Hells teeth, I unknowingly invented/implemented an FSM in assembler before C even existed!

Unless you are maybe over 2000 years old you should remove "invented".

https://en.wikipedia.org/wiki/Hero_of_Alexandria

I invented all by myself, simply by thinking and finding a way to do something. Another person tried to do the same thing with if-then-elses and failed miserably   Yes, it turns out it wasn't an original concept or implementation, but then there were very few available code examples for the only available (39bit) machine.

A few years later I did the same with microprogramming. I didn't know about Maurice Wilkes pioneering contribution; I just thought and found a way to implement a computer. It made it easy for me to understand the i3000 and amd2900 series when they appeared.

[Sal Ammoniac]

- 12 bit PIC, 32 registers

- 14 bit PIC, 128 registers

12-bit and 14-bit PICs? Never heard of them. There are 8-, 16-, and 32-bit PICs.

[brucehoult]

- 12 bit PIC, 32 registers

- 14 bit PIC, 128 registers

12-bit and 14-bit PICs? Never heard of them. There are 8-, 16-, and 32-bit PICs.

Perhaps you are not familiar with PIC microcontrollers from Microchip. They all have 8 bit registers and ALUs, the number above refers to the size of the instructions. Microchip have models with 12, 14, and 16 bit instructions, with instructions containing 5, 7, or 9 bit register/memory addresses inside them (8 bit offset and 1 bit for absolute or banked addressing for the 16 bit instruction chips). Even more confusingly, the marketing name e.g. PIC12, PIC14, PIC16 is mostly a number 2 higher than the instruction size.

PIC24 is a quite different ISA with 16 bit registers and ALU. PIC32 was originally MIPS but can now be RISC-V. PIC64 is RISC-V.

[NorthGuy]

Lean, please. Say no to bloat.

You cannot cure bloat with a slightly more compact ISA, or with super-optimized compiler for that matter.

[Sal Ammoniac]

Perhaps you are not familiar with PIC microcontrollers from Microchip.

I'm not familiar with the 8-bit PICs. I wouldn't touch those monstrosities with a ten foot pole. 

[westfw]

You only actually need about 10 simple RISC instructions to efficiently support C.

Is there elaboration on this somewhere?

Sound almost possible (for some definitions of "efficiently"), but it seems like you'd need a pretty "modern RISC" architecture as well (in particular, registers that are really "general purpose"), whereas a PIC has impediments like having only one sort-of index register, non-contiguous "ram", memory banking, and other oddities in pointers to code.

(Some of these are improved in the "enhanced midrange" PICs.  TWO index registers, and access to contiguous data memory via them...)

[Reece]

It's unlikely to need:

- KBs of RAM
- calls through function pointers / C++ virtual functions
- recursion
- function calls more than 8 levels deep
- setjmp/longjmp

.. all of which are required for C.

Utter nonsense. Tell that to the folk who have LLVM compiling 'C' code for the MOS Technology 6502 and you'll get laughed at.

Sure, there are limitations on what you can do. But for most microcontroller applications it's easier and generally more maintainable than coding in assembly.

[brucehoult]

It's unlikely to need:

- KBs of RAM
- calls through function pointers / C++ virtual functions
- recursion
- function calls more than 8 levels deep
- setjmp/longjmp

.. all of which are required for C.

Utter nonsense. Tell that to the folk who have LLVM compiling 'C' code for the MOS Technology 6502 and you'll get laughed at.

I'm not sure what you're talking about here. 6502 is not a microcontroller intended only for replacing discrete logic, it's a full-on microprocessor capable of running an operating system or any programming language, including full C/C++.

- KBs of RAM

6502 supports 64KB RAM, enough for real programs and compilers. I was running a Pascal compiler on an Apple ][ 45 years ago. That compiled to bytecode not native, but that's just an extra compiler pass, the hard part is done. I helped write a back end from the very similar OCODE to the slightly better than 6502 M6809 a couple of years later.

8 bit PICs can never dream of doing any such thing.

- calls through function pointers / C++ virtual functions

6502 directly supports JMP (zp) through a function pointer. JSR through function pointer can be simply achieved via a JSR to a JMP (zp) shim.

- recursion

6502 has no problems supporting recursion

- function calls more than 8 levels deep

6502 directly supports function calls 128 levels deep

- setjmp/longjmp

Easily supported on 6502 since you have so few registers to save/restore and addressing modes easily supporting a struct in RAM to store them in.

I'm not sure why you took a discussion about 8 bit PIC and brought the far more general and powerful 6502 into it, let alone why I would think 6502 can't support C.

[brucehoult]

You only actually need about 10 simple RISC instructions to efficiently support C.

Is there elaboration on this somewhere?

https://www.reddit.com/r/RISCV/comments/w0iufg/how_much_could_you_cut_down_rv32i_and_still_have/

Sound almost possible (for some definitions of "efficiently")

My final 10 instruction ISA (after dropping BLTU, since you can add/sub/xor 0xF0000000 to both operands then do BLT) needs at most 4 instructions to emulate dropped RV32I instructions, except for byte and halfword load/store which, ironically, are instructions that real-world ISAs actually have left out e.g. the first DEC Alpha.

Recoding my primes benchmark to use the reduced ISA made the code 30% bigger but only 3% slower. But it doesn't use byte/half load/store.

but it seems like you'd need a pretty "modern RISC" architecture as well (in particular, registers that are really "general purpose"), whereas a PIC has impediments like having only one sort-of index register, non-contiguous "ram", memory banking, and other oddities in pointers to code.

I based it on RISC-V, but 1985 MIPS would work equally well. Is 1985 still "modern"?

[Andy Chee]

- 12 bit PIC, 32 registers

- 14 bit PIC, 128 registers

12-bit and 14-bit PICs? Never heard of them. There are 8-, 16-, and 32-bit PICs.

The 12C509A is an 8-bit microcontroller with 12-bit opcodes.  Refer to page 48 of the pdf.

https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/40139e.pdf

The 16F84A is also an 8-bit microcontroller but with 14-bit opcodes.  Refer to page 38 of the pdf.

https://ww1.microchip.com/downloads/en/devicedoc/35007b.pdf

The 18F252 is also an 8-bit microcontroller, but with 16-bit opcodes.  Refer to page 216 of the pdf.

https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/39564c.pdf

[westfw]

["Needs a modern RISC"]Is 1985 still "modern"?

In the sense that Microchip claimed that the 8bit PICs were "RISC" just because they didn't have many instructions.
So: modern RISC (to me) means general purpose and orthogonal registers and load/store memory access.

But "supports C" is all or nothing

Architecture wise, or environment?  Because the various non-standard HLLs (like "Min-C" for Padauk, or JAL for PICs, etc) are still pretty useful.

[brucehoult]

["Needs a modern RISC"]Is 1985 still "modern"?

In the sense that Microchip claimed that the 8bit PICs were "RISC" just because they didn't have many instructions.
So: modern RISC (to me) means general purpose and orthogonal registers and load/store memory access.

Agreed.

Microchip and TI claim PIC and MSP430 are RISC, but they are not. Doing everything via an accumulator is not RISC. On the opposite extreme memory to memory arithmetic like ADD 123(R5), 567(R6) is not RISC.

But "supports C" is all or nothing

Architecture wise, or environment?  Because the various non-standard HLLs (like "Min-C" for Padauk, or JAL for PICs, etc) are still pretty useful.

Something doesn't have to be C to be useful, but it has to support all C language features to be C.

You can give a pass on a lot of the standard library, as things such as file and network access may simply not exist in the environment.

There is a specific spec for "Freestanding C" which says which headers and features must be supported. malloc() and free() are not included, or string functions that implicitly use them, but you do need bsearch() and qsort() which pass pointers to functions and then call them via the pointer.

qsort() is exactly the kind of thing that earlier generations of PIC can not efficiently do, both because of the function pointer and because of recursion. The library qsort() could be written to use iterative code with an explicitly-managed stack of work to do, but lack of support for recursion as a language feature already rules out those "mini C"s before even looking at the library.

PL/M is useful. BCPL is useful. Forth is useful. They are not C.

Any CPU that has arithmetic, conditional branching, and the ability to read/write memory at a calculated address can be used to implement an interpreter for a more powerful ISA, treating that ISA's instructions as data, maintaining a pseudo-PC and pseudo-SP, and implement all of C in that way. The cost is one or two orders of magnitude slower program execution. ZPU could be a good option for that as it is very small and simple but is supported by GCC. The Wikipedia page claims there is a 16 bit variant, but I can't find evidence of that.

[runblade]

Did anybody used NEC microcontroller uPD78xx? Now Renesas RL78.
I made a couple of project with uPD78014 and later with uPD78F0363.
The uPD78xx core is a Z80 clone.
I used also Renesas R5F21256 later.

[JPortici]

Something doesn't have to be C to be useful, but it has to support all C language features to be C.

Fine.
XC8 on PIC18 supports every C feature.
Enhanced midrange PIC16 (so 15yo parts) can as well but there is too little memory for it to be useful, so they chose to not implement them in the compiler

[brucehoult]

Something doesn't have to be C to be useful, but it has to support all C language features to be C.

Fine.
XC8 on PIC18 supports every C feature.

Sure. PIC18 is considerably better in this regard than the earlier ones.

Enhanced midrange PIC16 (so 15yo parts) can as well but there is too little memory for it to be useful, so they chose to not implement them in the compiler

"too little memory" doesn't make sense. PIC16F18877 = 4k RAM and 56k flash.

That's double the size of the extremely popular ATMega328, which the entire C++-based Arduino ecosystem grew up around. Or the present day CH32V003, for that matter(2k RAM, 16k flash).

Heck, before the CH32V003 happened I regularly programmed the 512 byte RAM, 8k flash ATTiny85 in C/C++. There are of course severe limits on how MUCH of anything you can do, but no limit on what C features you can use to do it: pointers, pointers to functions, recursion ... it's all fine. The biggest hassle with all the AVRs is that you need to use an extension to C to use special pointers to access constant data in flash instead of having them copied to RAM at program startup. Everything works if you don't do that -- you just gobble up RAM quickly if you have a lot of string constants etc.

The truth is that enhanced midrange PIC16 can NOT properly support C using native code. It's not a question of "chose to not implement them in the compiler". It is simply impossible.

The better support for pointers to data is of course welcome.

But recursion is extremely limited with only an 8 level return address stack that is not accessible by software: no PUSH or POP etc.

But, worst, function pointers are not properly supported. You can fake them within a single compilation unit by knowing all possible functions that a given pointer can point to, and then make a jump table to them, and represent the function pointer as an index into the table.

That does not permit such standard C uses of function pointers as qsort() or bsearch().

Ironically, on PIC16 you can support C++ virtual functions more easily than C function pointers.

Even Tiny AVR has no problems with any of this. The stack is in RAM, fully accessible, limited only by RAM size. Function pointers are fully supported using ICALL. Recursion is limited only by RAM.

[westfw]

The biggest hassle with all the AVRs is that you need to use an extension to C to use special pointers to access constant data in flash instead of having them copied to RAM at program startup.

Newer AVRs with up to 48k of flash no longer have this hassle...
(Now, if only there were a few more of the 48k chips (AFAIK, there is only the ATmega480x.)  Quite a few 32k AVR-xx chips and "xTinys", though.  And even the larger flash chips can map 32k of their flash into the 64k data address space (though I'm not sure the compiler knows about that.))

[brucehoult]

The biggest hassle with all the AVRs is that you need to use an extension to C to use special pointers to access constant data in flash instead of having them copied to RAM at program startup.

Newer AVRs with up to 48k of flash no longer have this hassle...
(Now, if only there were a few more of the 48k chips (AFAIK, there is only the ATmega480x.)  Quite a few 32k AVR-xx chips and "xTinys", though.  And even the larger flash chips can map 32k of their flash into the 64k data address space (though I'm not sure the compiler knows about that.))

Yes, apparently that was first in ATxmega in 2008 (before I even started using ATMega328s!) but became more common with 2016-2018 models ... by which time my attention was switching to RISC-V SiFive FE310, GigaDevice GD32VF103 (e.g. Sipeed Longan Nano), Kendryte K210 (Sipeed MaixDuino etc). Especially the Longan Nano, a 46mm x 20mm board with a 108 MHz CPU 128KB Flash 32KB SRAM 28 GPIOs SD card and a 160x80 RGB LCD all for under $5.

[cunningfellow]

Ever on and on I continue circling
With nothing but my hate of PICs a certainty