Microprocessor (MPU 8/16) that can be programmed using C programming language

[aiq25]

Hi. I want to learn about 8 and 16 bit microprocessors but all of the ones I can find seem to be programmed using assembly language.

Are there any microprocessors that can be programmed using C (embedded) programming language?

Edit (some clarifications): I would like to build a retro computer using modern IC’s that’s why I’m looking for a 8 or 16 bit MPU specifically. I would like an MPU that can run program code from the external memory.

This project is for fun. I would like to get back into more embedded projects and programming. I like C programming. I never enjoyed assembly language.

[Ian.M]

Nowadays its *RARE* to find a MCU still in production that isn't supported by a C compiler, either GCC, SDCC, or the manufacturer's or a third party's proprietary C compiler.  Many MCU families have more than one C compiler to choose from.

You must be doing something wrong in your search or simply giving up when you see mention of an assembly language instruction set.

Edit: I misread the O.P's question.  However everything above is equally applicable to MPUs.

[ataradov]

Can you name a few that you were looking at? I would really struggle to find something without C support. Some are more limited than the others, but even 3 cent Padauk MCUs have some sort of C-like high level language (although arguably they don't really need it).

[aiq25]

Thanks for the responses. I don’t think I was clear in my original post.

I’m not looking for an microcontroller but rather microprocessors (like Z80) with external RAM/ROM.

I have used Microchip PIC16, PIC18 and NXP S12G but they don’t have external RAM or ROM.

One of the reason I’m looking for an MPU is I want to build a retro computer but using a modern IC with C language support.

[ataradov]

There are a lot of devices that have more embedded Flash/SRAM than any small computers ever had on the board.

But even if you take most Cortex-M7 devices, they would have interface to external memories that typically can support NOR flash and SRAM. SDRAM is also often supported.

Some less powerful devices will have external memory interface too.

There is not anything like Z80 though. Those devices would make no sense in a modern world. So you would have to adapt to what is available.

Although if you are limiting yourself to 8- or 16-bit devices only, then things get much harder. It is not clear why you would complicate your life this way.

[greenpossum]

Z80 has SDCC. 8051 and descendants cater for external code and data memory and is supported by SDCC. Although I don't know what you have against built-in flash program memory which can be as large as external program memory.

[westfw]

The 68000 and derivatives were one of the initial targets of gcc.  And the Intel x86 chips.

Z80, 6502, and 6809 all have C compilers.
I'm afraid I haven't kept track of which 8/16 bit pure "microprocessors" have survived.  You can find microcontrollers that support external memory buses...  (be careful whether they can execute code from the external memory.  For example, the larger AVRs can have external data memory, but can't run code from data memory.  Most 8051 derivatives can support both external data and external program memory.  Usually at significant performance penalty...

[aiq25]

There are a lot of devices that have more embedded Flash/SRAM than any small computers ever had on the board.

But even if you take most Cortex-M7 devices, they would have interface to external memories that typically can support NOR flash and SRAM. SDRAM is also often supported.

Some less powerful devices will have external memory interface too.

There is not anything like Z80 though. Those devices would make no sense in a modern world. So you would have to adapt to what is available.

Although if you are limiting yourself to 8- or 16-bit devices only, then things get much harder. It is not clear why you would complicate your life this way.

I have looked at 32-bit devices but wanted to use an 8 or 16 bit device.

This is only for fun and for me to get back into doing more embedded projects and programming.

[aiq25]

Z80 has SDCC. 8051 and descendants cater for external code and data memory and is supported by SDCC. Although I don't know what you have against built-in flash program memory which can be as large as external program memory.

I would like to use external program memory, easy to test out new codes.

[Ian.M]

You'd really have to look at some family that's totally obsolete  or really exotic to find something that doesn't support C.  Heck, even the Novix NC4016 native FORTH MPU had a C compiler.

Therefore it comes down to finding a MPU, or a MCU that can execute code from external RAM, that's preferably still in production, or at least cheap and readily available as N.O.S, has an affordable toolchain, is in a package you can work with as a hobbyist without too much hassle and doesn't need too much support hardware for a minimal system.  There's also the possibility of running a soft-core implementation of a popular MPU in a FPGA.  The problem isn't finding one, as there are more than most people can hope to master in their lifetime, its finding one you like!

Incidentally, the Z80 has evolved into the Zilog eZ80 family which is still Z80 instruction set compatible, and is still in active production.

[greenpossum]

I would like to use external program memory, easy to test out new codes.

These days In System Programming is faster than taking an EEPROM out, flashing it, and putting it back.

[brucehoult]

Z80 has SDCC. 8051 and descendants cater for external code and data memory and is supported by SDCC. Although I don't know what you have against built-in flash program memory which can be as large as external program memory.

I would like to use external program memory, easy to test out new codes.

I don't understand why you say or think that. Why do you think so?

Insisting on supporting external ROM and SRAM -- let alone DRAM -- is far more expensive and lower performance than SRAM internal to the chip, at least for the 64 KB possible on an 8/16 bit CPU with 16 bit addresses, because of the large number of package pins needed (24 plus some control).

There are C compilers available for everything, although on older 8 bit designs such as the PIC, 8051, 6502, or Z80 compiled code is necessarily much bigger and slower than hand-written code. Also compilers for those funky ISAs are so different from anything modern that they can't be supported (or well supported) in gcc or llvm so their compilers tend to be much less sophisticated. On the other hand the AVR is a good target for C, as of course are 6809, 8086, 68000, msp430

[ataradov]

This is only for fun and for me to get back into doing more embedded projects and programming.

I would argue that it is more fun to work with 32-bit devices. You are intentionally creating friction and all sorts of possible issues that are not related to actually programming things.

And yes, the argument that is is easier with external memory is completely invalid. It is much harder to work with external memories.

I feel like you are not up to speed on modern MCUs. Get some chap STM board and play with the existing board to see how it all works before building your own.

[westfw]

You can build one of these:  https://hackaday.io/project/159973-z80-mbc2-a-4-ics-homebrew-z80-computer(or it's predecessor, or the followon V20-based board.)
It's runs near-standard CP/M, supports native BASIC, Pascal, Assembler, and Modula2, and has available SDCC and other languages) via cross-compilation.  There was LOTS of CP/M software that should run on this, and much of it is still online (thanks to the US Army!)

[Doctorandus_P]

For any kind of retro computing without something concrete in mind it's hard to give some decent advice.

Recently I had a peek at the book
"STM32_Beginning_Developing_with_FreeRTOS_libopencm3_and_GCC.pdf"

And sure, it's Arm Cortex M3, but it's C (or C++ if you like).
The smaller 8-bitters tend to have a very limited amount of RAM, and can not execute code from it. While this thing can run code from RAM. But I have a better reason for mentioning this book. It has a whole section devoted to "overlays". Which is a technique to load functions from external storage into RAM to execute them. This used to be popular in the old days when RAM in PC's was very limited.

An 8-bitter that can rode from RAM, and has a C compiler is the Cypress CY7C68013A. It is used in all the cheap Sigrok/Pulseview Logic Analyzers, and you can use the "FX2LAFW" firmware as a starting point for your own experiments.

On hackaday a lot of articles have been written about retro computing. Lots of Z80 boards, but the 68000 also seems to be popular.

But what aspect of "retro computing" attracts you so?
For me it mostly equals lots of separate chips, which translate to lots of soldering and big expensive PCB's. Also lots of opportunity to make hardware errors.

Apparently you do not know yet which processor you want to use. I also find it strange that you can only "find assembly". C compilers have been available for nearly any platform since the 80's.

[rstofer]

Programming the Z80 in C is pretty straightforward.  First you build up a development machine running the CP/M operating system and then you install BDS C.  The output would be native code.

https://www.bdsoft.com/resources/bdsc.html

I have a couple of these systems (I see there is an Arcade blog):

https://rc2014.co.uk/

Based on the number of kits they sell, they must have a source for real Z80 chips.  There are thousands of 40 pin PDIP devices in stock at DigiKey.  Apparently, Zilog is still making them.

I also have a Zilog EZ80 development board running CP/M and all its friends at 50 MHz - that system just screams!  I built a daughter card to provide the Compact Flash disk system and UART->USB serial ports.

Those are 8 bit solutions running all 8 bit software.

When I wanted to build PacMan, I used an FPGA board to run the T80 (Z80 workalike) core from OpenCores.org and I found the ROM images in the MAME CDs.  I used the Digilent Nexys 2 board (now obsolete) and built an add-on card to deal with breaking out the audio, video and controls.  Search around for things like 'arcade' 'retro arcade' 'fpga arcade' and so on.

[SiliconWizard]

Nowadays its *RARE* to find a MCU still in production that isn't supported by a C compiler, either GCC, SDCC, or the manufacturer's or a third party's proprietary C compiler.  Many MCU families have more than one C compiler to choose from.

Yes, it's more than rare. It's even an oddity. And by nowadays, you can make that at least for the last 20 years.

Now a few, "recent" niche MCUs do not have a C compiler, likely because their architecture is too simplistic for that. We can think of the Padauk MCUs, which are ultra simple (and ultra cheap), and come with a vendor-supplied compiler supporting some kind of very stripped-down C. But this is really part of the few exceptions, and it still looks like C, even though the language is a lot more limited than C.

I'd be curious to hear about other examples.

[brucehoult]

Nowadays its *RARE* to find a MCU still in production that isn't supported by a C compiler, either GCC, SDCC, or the manufacturer's or a third party's proprietary C compiler.  Many MCU families have more than one C compiler to choose from.

Yes, it's more than rare. It's even an oddity. And by nowadays, you can make that at least for the last 20 years.

Now a few, "recent" niche MCUs do not have a C compiler, likely because their architecture is too simplistic for that. We can think of the Padauk MCUs, which are ultra simple (and ultra cheap), and come with a vendor-supplied compiler supporting some kind of very stripped-down C. But this is really part of the few exceptions, and it still looks like C, even though the language is a lot more limited than C.

I'd be curious to hear about other examples.

It's interesting to think (as a compiler writer) what would prevent something from running C reasonably efficiently.

Severe lack of RAM, but it has to be really severe. You can write C programs on a 512 byte ATTiny85 no problems, or even its smaller sisters the 45 and 25, to the extent that you can write anything on them at all.

You need a way to load literals. You need bitwise boolean operations. NAND or NOR would be enough. You need addition. (Synthesizing from bitwise is too slow because you have to ripple carries). You need conditional branch based on zero / not zero. You need a right shift. You need at least 16 bit arithmetic (the preceding is sufficient to synthesize it from smaller units)

On a von Neumann architecture (which I'll define as one where you can run code from RAM) you can cover up many of the following sins with self-modifying code, at reduced but still reasonable efficiency. By definition a Turing machine (which is effectively a restricted form of a Harvard architecture, as the FSM is fixed) can compute anything, but it can be extremely inefficient.

You need pointers to arbitrary RAM addressees, and to add integers to pointers and subtract pointers, and to be able to load and store via these pointers.

You need to be able to call subroutines, and return from them. You need to have arbitrary (or at least large) return stack depth, or be able to access the return address easily and manipulate it as data. You need to be able to call subroutines via pointer, though not arbitrary pointer. Note on a Harvard architecture these can be a different kind of pointer than data pointers.

[westfw]

Avr-gcc does not support the ramless avrs like the at90s1200 or attiny11.
(I don’t think there are any “current” such.)


You might have a hard time finding c compiler that support romable code for some of the old 8bit chips.  A cp/m compiler would usually assume run-from-Ram.

[brucehoult]

You might have a hard time finding c compiler that support romable code for some of the old 8bit chips.  A cp/m compiler would usually assume run-from-Ram.

A given compiler might or might not support it, but I don't think there's any obstacle or performance hit for 8080/z80 or 6502. There might be for older chips.

If I was to write a compiler for those things now I'd generate very different (and more efficient) code than was done at the time. Especially if I could use gcc or llvm and run the compiler on a modern host. But even with a simple non-optimizing compiler running on the target itself the code could be much better now.

[Ian.M]

Avr-gcc does not support the ramless avrs like the at90s1200 or attiny11.
(I don’t think there are any “current” such.)

OTOH Hi-Tech PICC and its successor Microchip XC8 quite happily support programming the PIC10F200 in C, and that chip has similar limitations, with only 16 bytes of general purpose registers.  That pretty much points the finger at it either being a GCC issue, or just lack of interest by the AVR-GCC developers in targeting minimal ATtinys due to the poor return for the effort involved.

[GeorgeOfTheJungle]

Although if you are limiting yourself to 8- or 16-bit devices only, then things get much harder. It is not clear why you would complicate your life this way.

Hear, hear !!!

[brucehoult]

Avr-gcc does not support the ramless avrs like the at90s1200 or attiny11.
(I don’t think there are any “current” such.)

OTOH Hi-Tech PICC and its successor Microchip XC8 quite happily support programming the PIC10F200 in C, and that chip has similar limitations, with only 16 bytes of general purpose registers.  That pretty much points the finger at it either being a GCC issue, or just lack of interest by the AVR-GCC developers in targeting minimal ATtinys due to the poor return for the effort involved.

16 bytes of registers/memory, 256 instructions (er .. I think? 384 bytes and I think 12 bit opcodes?), 2 level subroutine return stack. Any programs will certainly be small!
 

[Mazo]

I have programmed the PIC10F202 in C,and it certainly works.As there are no interrupts CCP or anything like that just for fun I wrote a PWM generator using the one and only timer(the duty cycle and frequency were hardcoded ofcourse).
This took around a third of its resources if memory serves me correctly

[aiq25]

You can build one of these:  https://hackaday.io/project/159973-z80-mbc2-a-4-ics-homebrew-z80-computer(or it's predecessor, or the followon V20-based board.)
It's runs near-standard CP/M, supports native BASIC, Pascal, Assembler, and Modula2, and has available SDCC and other languages) via cross-compilation.  There was LOTS of CP/M software that should run on this, and much of it is still online (thanks to the US Army!)

Thanks. I think I will start with something like this.

Programming the Z80 in C is pretty straightforward.  First you build up a development machine running the CP/M operating system and then you install BDS C.  The output would be native code.

https://www.bdsoft.com/resources/bdsc.html

I have a couple of these systems (I see there is an Arcade blog):

https://rc2014.co.uk/

Based on the number of kits they sell, they must have a source for real Z80 chips.  There are thousands of 40 pin PDIP devices in stock at DigiKey.  Apparently, Zilog is still making them.

I also have a Zilog EZ80 development board running CP/M and all its friends at 50 MHz - that system just screams!  I built a daughter card to provide the Compact Flash disk system and UART->USB serial ports.

Those are 8 bit solutions running all 8 bit software.

When I wanted to build PacMan, I used an FPGA board to run the T80 (Z80 workalike) core from OpenCores.org and I found the ROM images in the MAME CDs.  I used the Digilent Nexys 2 board (now obsolete) and built an add-on card to deal with breaking out the audio, video and controls.  Search around for things like 'arcade' 'retro arcade' 'fpga arcade' and so on.

Thanks. Will look into this as an option.

Also thank you for all the others who have commented on this thread. Although I understand the limitations of 8-bit and 16-bit MCU's, these are the MCU's I started programming in. I would like to get back into programming by using something that I am familiar with. I know 32-bit dev boards now a days are very cheap and available from various sources. Someday I will move onto 32-bit MCU's but for now I think I will stick with 8 and 16 bit devices. The limitations of these devices is what should make it fun to work with. Also, I want to build a "modern" retro computer and I feel like using a 32-bit MCU will take away from that.