Tiny MCU architectures: AVR, PIC, 8051, STM8, MSP430, custom RISC...

[David Hess]

The oldest NMOS 8051's had a 6 clock phase, and needed 12 or 24 clocks for most opcodes.
The more modern 1T 8051 started with mostly 1 clock per byte, but some recent models use a 32 bit fetch, and on those models a 24bit opcode can execute in 1 sysclk.

One has to be a little bit careful about clocks and instructions.  PIC for instance divides the oscillator clock into 4 phases for the instruction clock, so the instruction clock is 1/4 of the oscillator clock, yet they like to call this single cycle execution with a 2 stage pipeline.  Various ancient 80 series microcontrollers used a 12 phase clock and no pipelining.

What often matters more is how the clock is used to generate the memory cycle.  Some processors allow more time for memory access at a given instruction clock and it is the memory access time which limits instruction throughput.  ARM microcontrollers face this a lot but a comparison between the 8080, 6502, and Z80 is instructive.

[nctnico]

IMHO nowadays you should go for a microcontroller which has a continuous memory space of at least 64kB. The 8051 and PIC with seperate memories are great to program in assembly but a C compiler chokes on them. These architectures simply don't support pointers. Keil and IAR got really clever but if you are not carefull, your code will be slow so even though you might be programming these in C, it is with your arm tied behind your back and the code isn't portable to any other architecture.

I don't know about AVR but the MSP430 with it's 16 bit architecture is pretty good and very low power.

The difficulty for the C compilers is not with the memory size, with µCs with a split adress range. This complicates things and one needs work arounds like seprate pointer types for ROM, RAM and IO.

That is exactly what I wrote. The point is: Having a single, continuous address space of at least 64kB is a good indication that a microcontroller is not hampered by seperate address spaces.

Anyway for small programs code portability is not that much an issue.

I beg to differ. I'd like to be able to re-use code across different microcontrollers. Things like dealing with EEPROMs, storing data in EEPROMs, reading ADCs, etc, etc are common 'patterns' that are nice to write once and use many times. Being able to use pointers without a massive speed penalty helps a lot to create simple & yet powerfull APIs.

[NorthGuy]

That is exactly what I wrote. The point is: Having a single, continuous address space of at least 64kB is a good indication that a microcontroller is not hampered by seperate address spaces.

That's the Harward architecture where there are separate instruction spaces for instructions and data. So, technically there are two types of pointers - instruction pointers and data pointers. It would be easier for the programmer to deal with this by himself, but in C pointers are unified, so modern C compilers use extra bits to distinguish between spaces. Is that what you don't like?

I don't understand the buzz. When I program in C I write to the C standard (C-99 at the moment). This compiles and works anywhere, from PIC16, to amd64. I don't really care about implementation. The architecture doesn't matter for me at all. I don't even look at the disassembly.

And then, if my whole program requires 3k of memory, why in the hell do I need 64k?

[bson]

That is exactly what I wrote. The point is: Having a single, continuous address space of at least 64kB is a good indication that a microcontroller is not hampered by seperate address spaces.

That's the Harward architecture where there are separate instruction spaces for instructions and data. So, technically there are two types of pointers - instruction pointers and data pointers. It would be easier for the programmer to deal with this by himself, but in C pointers are unified, so modern C compilers use extra bits to distinguish between spaces. Is that what you don't like?

I don't understand the buzz. When I program in C I write to the C standard (C-99 at the moment). This compiles and works anywhere, from PIC16, to amd64. I don't really care about implementation. The architecture doesn't matter for me at all. I don't even look at the disassembly.

And then, if my whole program requires 3k of memory, why in the hell do I need 64k?

You will in the future when you reuse existing, working, well-tested and trusted code in a different project.  And then you find the old project had tables in code space, with pointer parameters carefully flagged as code (compilers don't use bits, they use static typing to distinguish address spaces), but your new project wants to operate on data in well, data space.  So you can't just use your existing code as-is, but have to strip, or change, or #define-box them with yet another layer of cruft.  Then find it doesn't work - was it all your pointer fixing or something about platform compatibility?  You can't run the tests you might have created before, because they would need the same cleanup, and may not be generic enough.  This is just messy sh*t that productive engineers have long since kicked to the curb.  In an era where controllers with unified address spaces proliferate there's no need to ever go down ratholes like this.

[nctnico]

And then, if my whole program requires 3k of memory, why in the hell do I need 64k?

Address space is not amount of memory 

[NorthGuy]

Evolution of thoughts:

IMHO nowadays you should go for a microcontroller which has a continuous memory space of at least 64kB.

That is exactly what I wrote. The point is: Having a single, continuous address space of at least 64kB is a good indication that a microcontroller is not hampered by seperate address spaces.

Address space is not amount of memory 

[SiliconWizard]

That is exactly what I wrote. The point is: Having a single, continuous address space of at least 64kB is a good indication that a microcontroller is not hampered by seperate address spaces.

That's the Harward architecture where there are separate instruction spaces for instructions and data. So, technically there are two types of pointers - instruction pointers and data pointers. It would be easier for the programmer to deal with this by himself, but in C pointers are unified, so modern C compilers use extra bits to distinguish between spaces. Is that what you don't like?

I don't understand the buzz. When I program in C I write to the C standard (C-99 at the moment). This compiles and works anywhere, from PIC16, to amd64. I don't really care about implementation. The architecture doesn't matter for me at all. I don't even look at the disassembly.

Yep. Well, good if you can do that, but that requires relatively modern architectures. Many things can't compile the same from PIC16 to amd64, due for instance to requiring specific keywords to place some variables in some memory regions on PIC stuff. Even on the dsPIC you have this with the EDS, requiring properly declared variables and properly qualified pointers. This is not portable. If you stick to 100% portable C code, you end up not being able to use some resources or use them in an extremely inefficient way. This doesn't work. This EDS stuff on the 16-bit PIC architecture works well but it's pretty annoying - the code for using that properly is certainly not portable.

And then, if my whole program requires 3k of memory, why in the hell do I need 64k?

Not sure I understand the question. You mostly get what the market (and technology) dictates, the rest being non-viable and thus not available.
You can absolutely find Cortex M0 stuff with as little as 16 KB of Flash and 2/4 KB of RAM, at mind-blowingly low prices. Why would you want less while the prices are already rock bottom and the market for less would be nearly non-existent unless vendors could release that at even lower prices, which then becomes a niche. But if you really want that, you get odd chinese 8-bitters for a few cents, with crippled architectures, very little memory, docs in chinese and funky dev tools. Otherwise, you can grab any small Cortex-M0-based MCU or even RISC-V-based now with a few KB of Flash and RAM, and move on.

[NorthGuy]

You will in the future when you reuse existing, working, well-tested and trusted code in a different project.  And then you find the old project had tables in code space, with pointer parameters carefully flagged as code (compilers don't use bits, they use static typing to distinguish address spaces), but your new project wants to operate on data in well, data space.

That's how it looked in distant past. Now there's C standard and the compilers comply with it. You can mix objects from RAM and ROM and the compiler keeps track of them on its own. How the compilers do this. Very simple. ROM pointer may have the high bit set, while RAM has it cleared. Say, if the pointer's value is 0x8057, the compiler knows that this is 0x57 in ROM space, while 0x0057 would be a pointer in RAM space. Should you care about this? No. The most important thing about MCU is periphery. If you're lucky enough, you'll get everything working through periphery interconnections and DMA, may be short ISRs, while the CPU sleeps or slowly wanders through the main loop.

As to the "productive engineers", are those the ones who produced all those bloated and buggy things around me? Like I bought a TV last year. It has so many bugs, you wouldn't believe.

[nctnico]

I guess you never have programmed anything speed sensitive on 8 bit PIC or 8051. Using augmented pointers will slow your program down to a crawl and introduces a massive amount of bloat. Been there, done that. Won't do it again. The lack of support of normal pointers made me move away from 8051 to MSP430 about 20 years ago.

[NorthGuy]

Many things can't compile the same from PIC16 to amd64

Like what?

Of course there will be stuff like periphery register names, and attributes for interrupts. You need to use these, but this has nothing to do with memory model.

Similarly, there are various C intrinsics which are not portable, but this doesn't change much. They are present in any architecture.

due for instance to requiring specific keywords to place some variables in some memory regions on PIC stuff.

Totally not necessary.

Even on the dsPIC you have this with the EDS, requiring properly declared variables and properly qualified pointers. This is not portable. If you stick to 100% portable C code, you end up not being able to use some resources or use them in an extremely inefficient way. This doesn't work. This EDS stuff on the 16-bit PIC architecture works well but it's pretty annoying - the code for using that properly is certainly not portable.

EDS is a very bad design idea. However, there are only handful of dsPICs which have enough memory to go into EDS space. I've never used any of them, but if I remember correctly you don't have to specify anything unless you specifically want EDS.

And then, if my whole program requires 3k of memory, why in the hell do I need 64k?

Not sure I understand the question. You mostly get what the market (and technology) dictates, the rest being non-viable and thus not available.

This was a question to nctnico who insists an MCU must have at least 64k of continuous memory (not sure if he meant RAM or ROM). BTW, his rule would reject all the dsPIC33, which are very powerful when used in a suitable project.

[nctnico]

Maybe you should try to understand what 'address space' actually means first!

[NorthGuy]

I guess you never have programmed anything speed sensitive on 8 bit PIC or 8051.

Not in C. If you want to push the limit you have to use assembler. If you have chosen C, you have chosen convenience over performance. In my C projects, there's usually decent timing margin, so the compiler can add some bloat without doing any harm.

Using augmented pointers will slow your program down to a crawl and introduces a massive amount of bloat. Been there, done that. Won't do it again.

It's not that bad. Usually, you don't use the same pointer to access both ROM and RAM. Say, if you're using linked lists then all the objects will be in RAM and hence all pointers will be RAM pointers. Or, if you have a pointer which refers to static things (such as menu descriptions, or strings), or function pointer for that matter, the object will always be in ROM. The compiler can figure this out and use specific pointers instead of universal ones.

[NorthGuy]

Maybe you should try to understand what 'address space' actually means first!

Is that a question to me?

Address space is a range of addresses. There may be a single address space. There may be multiple address spaces. The same address in different address spaces will point to different things.

"continuous" means without gaps.

64k is the amount of memory.

"continuous 64k" refers to a range of that size in an address space. This range may represent ROM, or RAM,  whether the CPU has a single address space or multiple address spaces.

Two "continuous 64k" memory ranges may be located in the same address space or in different address spaces.

I guess, there must be "continuous 64k" somewhere, or you will never use the MCU

It appears that an ancient PIC18F8680 with 64k of continuous program memory is Ok to you, but STM32F03 with 32k ROM is not. Sounds bizarre to me. But I guess we'll never know unless you explain.

[westfw]

The difficulty for the C compilers is not with the memory size, with µCs with a split adress range.

I can't say that that the separate address spaces on AVR have ever been too bothersome.  Compilers and libraries seem to deal with it just fine.  I mean, it's nice to have constant data show up in (big) program space instead of (limited) RAM, but the biggest user of such data tends to be strings and tables that are easy to deal with as "special."

Banked address spaces for either data or program spaces are more difficult to deal with, and the whole "special data vs external data" that is characteristic of 8051 seems especially anti-C.  Assuming that you need RAM beyond the limited "special" bit.  For a long timer, microcontrollers have been very RAM-poor compared to microprocessors (which is changing, more recently.)

[coppice]

Many old designs are rubbish, but some ideas have stood the test of time.

Most curiously, the VAX was also loosely based on the PDP-11 (orthogonal src/dst, register file, addr modes) but turned out to be rubbish.  The microcoded design just couldn't be scaled, and DEC couldn't throw real estate at the problem the way Intel did a couple of decades later with the x86.

The VAX was OK. VMS just made it look bad.

[nctnico]

Maybe you should try to understand what 'address space' actually means first!

Is that a question to me?

Address space is a range of addresses. There may be a single address space. There may be multiple address spaces. The same address in different address spaces will point to different things.

"continuous" means without gaps.

64k is the amount of memory.

"continuous 64k" refers to a range of that size in an address space. This range may represent ROM, or RAM,  whether the CPU has a single address space or multiple address spaces.

Two "continuous 64k" memory ranges may be located in the same address space or in different address spaces.

I guess, there must be "continuous 64k" somewhere, or you will never use the MCU

It appears that an ancient PIC18F8680 with 64k of continuous program memory is Ok to you, but STM32F03 with 32k ROM is not. Sounds bizarre to me. But I guess we'll never know unless you explain.

Yes, that was a question for you and if this was an exam, you failed. Next time, just look up what 'address space' or any other technical term actually means before making up stories about what you think it means (but in reality does not).

[coppice]

This sounds like avr-gcc is accounting for a good part of AVR popularity.

Yes, I would say so.  Also avr-g++ (as used in ... Arduino.  But there aren't many 8bit CPUs that have C++ compilers available.  Not that everyone agrees that it's a good idea.  Or that what avr-g++ implements is "real C++")

Once you have implemented a processor back end for GNU C, its just a recompile to generate code for any of the languages supported by the GNU language suite. How useful this is depends on how much the library is a part of the programming experience. We tried this with GNU C for the MSP430, and generated some amusing, if not very useful, code from Fortran source code.

[westfw]

But there aren't many 8bit CPUs that have C++ compilers available. ...

Once you have implemented a processor back end for GNU C, its just a recompile to generate code for any of the languages supported by the GNU language suite.

Sure, but gcc (the collection) does not support many 8bit CPUs, so I stand by my original statement...

[nctnico]

But there aren't many 8bit CPUs that have C++ compilers available. ...

Once you have implemented a processor back end for GNU C, its just a recompile to generate code for any of the languages supported by the GNU language suite.

Sure, but gcc (the collection) does not support many 8bit CPUs, so I stand by my original statement...

Yes and no. Gcc simply is unsuitable for the most popular 8 bitters like 8051 and PIC. A compiler for those requires an entirely different approach. I have used Keil for the 8051 and I have to admit their compiler is a real work of art (even though it still does not support everything that C has to offer). OTOH gcc does support the Hitachi (now Renesas) H8/300 series which -IIRC- are 8 bit.

[coppice]

Sure, but gcc (the collection) does not support many 8bit CPUs, so I stand by my original statement...

Yes and no. Gcc simply is unsuitable for the most popular 8 bitters like 8051 and PIC. A compiler for those requires an entirely different approach. I have used Keil for the 8051 and I have to admit their compiler is a real work of art (even though it still does not support everything that C has to offer). OTOH gcc does support the Hitachi (now Renesas) H8/300 series which -IIRC- are 8 bit.

The Keil compiler is pretty weak compared to what the Hi-Tech compiler could do for the 8051. Sadly Microchip killed the 8051 version when they bought the company.

[voltsandjolts]

The Keil compiler is pretty weak compared to what the Hi-Tech compiler could do for the 8051.

Hmm, call me sceptical.
I bought the HiTech PIC18 C-Pro 'Omniescent' many years ago and what a shit show that was. And they knew it, because it came with a free license for the older compiler which was at least usable.
I used Keil C51 for a number of years and find it hard to believe HiTech could better it, based on my experience of their PIC compilers.

[coppice]

The Keil compiler is pretty weak compared to what the Hi-Tech compiler could do for the 8051.

Hmm, call me sceptical.
I bought the HiTech PIC18 C-Pro 'Omniescent' many years ago and what a shit show that was. And they knew it, because it came with a free license for the older compiler which was at least usable.
I used Keil C51 for a number of years and find it hard to believe HiTech could better it, based on my experience of their PIC compilers.

I'm judging by some applications I've seen people putting on 8051s that used complex junks of library, taken from the desktop, written in C, with no allowance for limited machines. These were fairly large protocol libraries needed for application specific 8051 MCUs to communicate with the outside world. They compiled much better with the Hi-Tech compiler, both for density and speed, than with the Keil one. I don't know how they compare for more typical small MCU work, like port twiddling.

[bson]

That's how it looked in distant past. Now there's C standard and the compilers comply with it. You can mix objects from RAM and ROM and the compiler keeps track of them on its own.

So you spend a week creating a set of functions with signatures like:

void render_text(struct panel* panel, const uint8_t* compressed_font, const struct render_params* params, const char* text);

How does the compiler know in the code generation for this function whether the font and rendering params are in ROM or RAM?  It will assume one or the other, most typically that it's in RAM.  But a font may not fit in RAM.  The rendering params might be in RAM though in one case, in ROM in another.  Do you want the compiler to emit code for both?  Or dynamically select one or the other - that would make text rendering VERY slow.  Same with the text. 

[NorthGuy]

That's how it looked in distant past. Now there's C standard and the compilers comply with it. You can mix objects from RAM and ROM and the compiler keeps track of them on its own.

So you spend a week creating a set of functions with signatures like:

void render_text(struct panel* panel, const uint8_t* compressed_font, const struct render_params* params, const char* text);

How does the compiler know in the code generation for this function whether the font and rendering params are in ROM or RAM?  It will assume one or the other, most typically that it's in RAM.  But a font may not fit in RAM.  The rendering params might be in RAM though in one case, in ROM in another.  Do you want the compiler to emit code for both?  Or dynamically select one or the other - that would make text rendering VERY slow.  Same with the text.

It certainly cannot guess, but it can track what pointers are passed to the function. If it can conclude that it's always RAM it emits the RAM access code. If it can conclude that it's always ROM it emits the ROM access code. If it cannot figure this out, or if it sees both, it certainly must emit code for both.

[brucehoult]

That's how it looked in distant past. Now there's C standard and the compilers comply with it. You can mix objects from RAM and ROM and the compiler keeps track of them on its own.

So you spend a week creating a set of functions with signatures like:

void render_text(struct panel* panel, const uint8_t* compressed_font, const struct render_params* params, const char* text);

How does the compiler know in the code generation for this function whether the font and rendering params are in ROM or RAM?  It will assume one or the other, most typically that it's in RAM.  But a font may not fit in RAM.  The rendering params might be in RAM though in one case, in ROM in another.  Do you want the compiler to emit code for both?  Or dynamically select one or the other - that would make text rendering VERY slow.  Same with the text.

It certainly cannot guess, but it can track what pointers are passed to the function. If it can conclude that it's always RAM it emits the RAM access code. If it can conclude that it's always ROM it emits the ROM access code. If it cannot figure this out, or if it sees both, it certainly must emit code for both.

So a function with (as seen here) 4 pointer arguments must be compiled in up to 16 different versions to accomodate whether each pointer is in RAM or ROM address space?