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

[josuah]

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?

Can this really work? Imagine pointers contained within structs, or an array of pointers with the length passed as another variable...

From https://www.nongnu.org/avr-libc/user-manual/FAQ.html

avr-gcc internally adds 0x800000 to all data/bss variable addresses

So maybe the pointers can carry that 0x800000, and before accessing any pointer, the compiler issues code to first check one bit, and use one version or another depending on it.
That would save from doing so many identical functions.
No idea what is really done in practice.

[brucehoult]

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?

Can this really work? Imagine pointers contained within structs, or an array of pointers with the length passed as another variable...

All the pointers have to be typed as PROGMEM or not. Including pointers in arrays or structs etc.

avr-gcc internally adds 0x800000 to all data/bss variable addresses

So maybe the pointers can carry that 0x800000, and before accessing any pointer, the compiler issues code to first check one bit, and use one version or another depending on it.

That's going to bloat the code a lot too -- and also be much slower.

That would save from doing so many identical functions.

In practice there would probably be very few functions that would need any duplication at all.

[NorthGuy]

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?

I don't think so. When the pointer gets actually used they check if the pointer applies to program or data space and dereference it accordingly.

Many chips have some sort of mapping, where the program space is mapped to a range of addresses in data space. Then the same code can access both, but there's still a performance penalty for accessing program space this way.

[brucehoult]

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?

I don't think so. When the pointer gets actually used they check if the pointer applies to program or data space and dereference it accordingly.

That's awful big slow code.

Many chips have some sort of mapping, where the program space is mapped to a range of addresses in data space. Then the same code can access both, but there's still a performance penalty for accessing program space this way.

Almost ALL modern ISAs have a unified address space with ROM, RAM, and IO. And there is no performance penalty penalty for program space unless you have flash with wait states and no cache.

[NorthGuy]

Almost ALL modern ISAs have a unified address space with ROM, RAM, and IO. And there is no performance penalty penalty for program space unless you have flash with wait states and no cache.

Harvard architecture was designed to separate buses - instruction bus and data bus - which allowed to access data and fetch instructions at the same time. That was long time ago. Since then they figured you can have multiple buses and still a single address space, which simplifies things.

[westfw]

Code: [Select]

void render_text(struct panel* panel, const uint8_t* compressed_font, const struct render_params* params, const char* text);
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?

Yes, theoretically.  But in real life not all of them have all the choices, so you usually end up with only two functions.  One with text in flash, and one with text in RAM.  "Panel" is not const, so it's never in flash, the font is always in flash, and the rendering params are small enough to be in RAM as well.

For instance, avr-libc has printf_P() and a "%S" format to handle the case where the format string, or the string argument, is in flash (respectively.)

Of course, implementing a bitmapped text display (or html) with multiple fonts and rendering parameters on an 8bit CPU with 64k or less (total) of memory is likely to be pretty painful, anyway, and maybe you should look for some other CPU.

The avr-gcc compiler (current version) has both a memory space __flash qualifier for data that is always in flash and gets a 16bit pointer) and a 24bit generic __memx pointer that is decoded at runtime to access either flash or RAM. (assuming you don't have one of the newer AVRs that maps 32k of flash into the RAM address space.)  __memx is presumably slow and bloaty; I can't say that I've ever looked at how well or badly it gets implemented/optimized.  AFAIK, avr-libc hasn't been updated with __memx support.

there is no performance penalty penalty for program space unless you have flash with wait states and no cache.

"Flash with wait states and no data cache" describes most low-end cores, even the "new" 32bit cores (ARM Cortex-M0, M3, M4, and those low-end RISC-V cpus that have been showing up.  ESP8266 has some weird requirements for accessing data in flash, in spite of it's large address space.  I'm not sure about ESP32.)

[brucehoult]

Code: [Select]

void render_text(struct panel* panel, const uint8_t* compressed_font, const struct render_params* params, const char* text);
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?

Yes, theoretically.  But in real life not all of them have all the choices, so you usually end up with only two functions.

Yup, as pointed out in one of the other messages you didn't pull a quote from :-)  The main point is that you know statically which ones you actually needs, and it's usually 1, sometimes 2, seldom many more.

there is no performance penalty penalty for program space unless you have flash with wait states and no cache.

"Flash with wait states and no data cache" describes most low-end cores, even the "new" 32bit cores (ARM Cortex-M0, M3, M4, and those low-end RISC-V cpus that have been showing up.

Those 10c or 12c RISC-V cores say they are zero wait states if run at 24 MHz, so I presume 1 at their maximum 48 MHz.

Also, as regards running code, each ROM fetch gets 4 bytes, so the 2-byte C-extension instructions can run at 1 IPC / 1 CPI and only the 4-byte instructions get a wait state. I guess it must be pre-fetching 4 bytes ahead as well as the current instruction(s) 4 bytes to achieve that. With the typical 60% C 40% I instruction mix that must average out to about 1.4 CPI. OR 1.5 CPI if you have a 50/50 mix. Without taken branches, of course.

[gf]

Code: [Select]

void render_text(struct panel* panel, const uint8_t* compressed_font, const struct render_params* params, const char* text);
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?

Yes, theoretically.  But in real life not all of them have all the choices, so you usually end up with only two functions.

Yup, as pointed out in one of the other messages you didn't pull a quote from :-)  The main point is that you know statically which ones you actually needs, and it's usually 1, sometimes 2, seldom many more.

Or a single template function in C++, where the compiler instantiates the overloads which are actually used.

[josuah]

Almost ALL modern ISAs have a unified address space with ROM, RAM, and IO.

It looks like the move AVR is doing as well:

The XMEGA cores do not add new instructions per se, but make some significant changes:

The memory map is reorganized, eliminating memory-mapping of the processor register file (so I/O ports begin at RAM address 0) and expanding the I/O port range. Now the first 4K is special function registers, the second 4K is data flash, and normal RAM begins at 8K.

https://en.wikipedia.org/wiki/Atmel_AVR_instruction_set#Core_CPU_instructions (at "The XMEGA cores [...]").

According to this: https://en.wikipedia.org/wiki/ATtiny_microcontroller_comparison_chart
the newer AVR chips use the avrxmega3, with XMEGA introduced by Atmel, eventually changed over time:

The AVR XMEGA uses the AVR RiSC CPU which is created for high level C code development.

http://ww1.microchip.com/downloads/en/DeviceDoc/doc7925.pdf

Although it was still a separate product family at this point:


While it seems like a trimmed-down version is the same for all new AVR from Microchip.

So they loook like aware of these problems and try to address it.
Sorry for the information scattered around here, I have yet to find a single authoritative source about that avrxmega3 architecture of these new AVR chips.

[westfw]

Quote

Or a single template function in C++, where the compiler instantiates the overloads which are actually used.

That might be nice, but C++ doesn't support the "named address space" feature that gives you __flash (and __memx?), and attributes apparently aren't part of types (ie subject to creating a different function signature), so you have to go to some lengths to get C++ to do good things...

[josuah]

Some more input about that "address space merge" I was dubitative about:

The 0-seriese "megaavr" chips have a unified address space where flash is accessible the same as RAM, and so LPM instructions are no longer needed to access constant tables stored in flash. An LDx from flash isn't actually any faster than an LPM, but there are a lot of extra addressing modes available
(indexing using X, Y, and Z, rather than only Z, for example), so I'd expect some overall improvement in behavior once the compiler gets it's register allocation optimization fingers in there.

That means that the various tables (notably the digital_pin_to* tables) can be allocated without specifying PROGMEM, and we don't need "pgm_read_*" functions to access them.

See also http://web.archive.org/web/20220511051704/https://www.avrfreaks.net/comment/2593311#comment-2593311

https://github.com/arduino/ArduinoCore-megaavr/issues/11

[westfw]

It looks like the move AVR is doing [unified address space] as well:

Unfortunately, the new chips with more than 48k of flash can only map 32k at a time into the RAM address space.
(And the xmega3 memory map isn't quite the same as the xmega description you found.  There's a 32kB flash section mapped into the last 32k of the RAM area, and actual RAM is just before that.  Also, there aren't any xmega3 chips that support external memory, and internal memory is likely to be limited to 24k or so (so far, nothing has more than 16k of RAM.))

https://github.com/arduino/ArduinoCore-megaavr/issues/11

Oh cool.  I hadn't noticed that they actually implemented my suggestions!

[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.

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.

Complex 'junk' libraries written for the desktop, compiled to run in 8051? I'm even more sceptical now. Also, an 8051 inside an ASIC/SoC is a bit twiddler. It's a royalty-free, small area core with a usable C compiler and it's purpose is simply setting up the SoC hardware for the specific application. When you see an 8051 in there, you know its not part of the signal processing flow

[josuah]

In case I aim C embedded application development for a microcontroller, an architecture (multiple of them offer that) with an unified address, I/O and memory space will be most welcome.

If I am focused upon peripherals, which would do all the work, the split address space found on the smallest 8-bit might not get too much in the way, and just some C or assembly to configure the peripherals and react to the interrupts would work nicely.

Some very tiny (in price or power) MCUs also only offer 8-bit architectures with all sort of work around small alddress space, such as memory paging, bank switching, or fancier like the padauk FPPA which offer some hardware-controlled context switching to have "threads" to bit-bang various things...

Some sensors also feature an MCU core, for instance:
* WCH USB MCUs with an 8051 mostly there to configure the peripherals
* possibly the whole PIC family ("motor/LCD/... driver? there's a PIC for that!"),
* more surprisingly, the expensive LMS7002M radio trasceiver, which features an 8051!

https://limemicro.com/technology/lms7002m/
https://limemicro.com/app/uploads/2018/07/LMS7002M-block-diagram-large.png (at the right on that image)
https://siliconpr0n.org/map/lime/lms7002m/mz_mit20x/ (the die itself in a map, no idea where the 8051 is though)

[gf]

That might be nice, but C++ doesn't support the "named address space" feature that gives you __flash (and __memx?), and attributes apparently aren't part of types (ie subject to creating a different function signature), so you have to go to some lengths to get C++ to do good things...

You are right, seems that AVR g++ does not support __flash at all, not even as GNU extension

[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.

Complex 'junk' libraries written for the desktop, compiled to run in 8051? I'm even more sceptical now. Also, an 8051 inside an ASIC/SoC is a bit twiddler. It's a royalty-free, small area core with a usable C compiler and it's purpose is simply setting up the SoC hardware for the specific application. When you see an 8051 in there, you know its not part of the signal processing flow

Who said they were junk libraries? There are a number of SoCs for things like smart meters, water meters, and so on, which have a dedicated measurement cell and an MCU core to talk to the outside world, There are widely used ones, like the Teridian line of energy metering devices, which have an 8051 core. People run fairly complex protocols, like DLMS, on these 8051 cores. The newer devices are moving to more powerful cores, like ARM, and bigger memories, because the market is demanding more complex interactions. However, millions and millions of 8051 cores are out there right now running the DLMS protocol to communicate electricity, gas or water results to the utility.

[voltsandjolts]

Who said they were junk libraries?

Eh? You did, I was quoting you, although I didn't understand what you were on about either

[coppice]

Who said they were junk libraries?

Eh? You did, I was quoting you, although I didn't understand what you were on about either

Oh, sorry. I think I must have intended to write chunks of library.

[Njk]

Who said they were junk libraries? There are a number of SoCs for things like smart meters, water meters, and so on, which have a dedicated measurement cell and an MCU core to talk to the outside world, There are widely used ones, like the Teridian line of energy metering devices, which have an 8051 core. People run fairly complex protocols, like DLMS, on these 8051 cores. The newer devices are moving to more powerful cores, like ARM, and bigger memories, because the market is demanding more complex interactions. However, millions and millions of 8051 cores are out there right now running the DLMS protocol to communicate electricity, gas or water results to the utility.

There are still many application areas for 8-bit MCUs. Sometimes, an attempt to use a more capable MCU is counterproductive.

For example, I have an old microwave oven with 8048 inside. I'm not going to replace this oven because it's an old machine, durable and robust, it's built with buy-once-use-for-life idea in mind, and it just works. The binary code now looks so tiny, I once disassembled it just for fun, to tweak it a bit removing some annoying moments, assembled again and programmed it back. It was not a "hack", it was a standard engineering approach to implement a change. It was not a problem to re-write the code in C and compile it as a Linux app (or form it in a python script) for BeagleBone or RPi, and put that stuff inside the oven (there are plenty of room). But it was just pointless because the existing solution works perfectly and it's easy to customize it in a case of necessity.

Try to do the same thing with modern ovens, which are superior electronically but inferior materially so they can't compete with the old ones in the service life category. Add to that the modern appliances are doing their job essentially similar but are far less owner-frendly and durable, and one can say it's some kind of degradation. In my opinion, the whole consumption paradigm will start changing very soon. We just can't afford so many "innovators", it's not sustainable. So a bad guys will ask what does the thing cost while a good guys will ask how long it last.

As for DLMS and other industrial protocols, for sure it's not a problem to implement it in, say, 8051. There are no time criticalities, but DLMS basically has two protocols, cleartext and secure, where the payload or whole message are encrypted. Again, not a problem, it will just take more time to process. Also, DLMS is designed to accommodate many security suites so in case the current suite is suddenly assumed broken, it's easy to replace it with new, more computationally heavy suite which is more difficult to crack. It just getting worse over time, not better. So the command processing will be more and more painfully slow, contradicting to the modern trend to poll the meters more frequently.

One possible evolutionary improvement is to use a security co-processor, external (e.g. a standard TPM chip, which, BTW were initially also based on a 8-bit MCUs) or internal. The external one seems not the best option because everyone can eavesdrop on the inter-chip bus, while the internal one will lock you on the vendor. Instead, it's better to drop that approach and use a general-purpose 32-bit MCU (e.g. ARM-based), that allows for less security-related overhead.

So I think security is the main limiting factor for 8-bit MCU applications today. That MCUs are inherently insecure as of today, they can and should be used only where it does not matter. It's still a very wide area though

---
WBR

[MarkR42]

Really I just like the newer AVR 8-bit chips (e.g. attiny1614 and its family, plus the 2-series and DA series).

They are like the older AVR chips, but the "flat" memory model means that more "normal" C code is possible, we can just use initialisers for arrays (e.g. strings) and have them "just work" (previously various macros were needed to copy the data in/out of flash, or the startup code would automatically copy variables into ram, rapidly using up the limited ram). This feels like when DOS went 32-bit and the old "near or far" pointers were no longer needed.

I've used the tinier, older AVRs and they are a pain in the arse; their peripherals are also much worse.

But mostly it's because the newer Microchip documentation actually (mostly) makes sense and I've been able to make almost all the peripherals do what I wanted.

[josuah]

For example, I have an old microwave oven with 8048 inside. I'm not going to replace this oven because it's an old machine, durable and robust, it's built with buy-once-use-for-life idea in mind, and it just works. The binary code now looks so tiny, I once disassembled it just for fun, to tweak it a bit removing some annoying moments, assembled again and
programmed it back. It was not a "hack", it was a standard engineering approach to implement a change. It was not a problem to re-write the code in C and compile it as a Linux app (or form it in a python script) for BeagleBone or RPi, and put that stuff inside the oven (there are plenty of room). But it was just pointless because the existing solution works perfectly and it's easy to customize it in a case of necessity.

Interesting, if something is written in low-level language like assembly, it might be much easier to reverse engineer it. Much harder with a C++ binary for instance.

So a bad guys will ask what does the thing cost while a good guys will ask how long it last.

Datasheet does not seem to specify a lot about the expected lifetime of the components.
What could be a reference, experience with various chips, automotive/aerospace certifications, reputation?
I wonder what makes doped silicon last longer or fewer...

So I think security is the main limiting factor for 8-bit MCU applications today. That MCUs are inherently insecure as of today, they can and should be used only where it does not matter. It's still a very wide area though

I always wonder where to split...
Encrypting everything makes it a nightmare to debug.
Encrypting nothing might expose dangerous things to Internet.

For instance, would you encrypt communication between the various parts of a same machine, like an airplane flap and the cockpit?

[Nominal Animal]

With respect to MCUs with Harvard architecture (separate address spaces for code and data), Clang wins over GCC (gcc and g++).

On AVRs, using Clang (either C or C++),
    int get(__attribute__((address_space (1))) const int *p) { return *p; }
reads a byte from the Flash using LPM instruction.  Both also allow you to define types that specifically use an address space, i.e.
    typedef  unsigned char  uchar_flash  __attribute_((address_space (1)));
    unsigned char get(const uchar_flash *p) { return *p; }

The same is wired on x86-64 for using FS and GS segments (address spaces 257 and 256, respectively).

GCC does have the attribute, but it doesn't seem to be wired to anything.
g++ (C++) does not support address spaces.
gcc (C) does support address spaces, but via custom qualifiers: __flash on AVR, __seg_fs on x86-64, and so on.

Paul Iannetta did very recently post a patch to g++ that would fix this –– simply wiring the existing support together ––, but I haven't tested the patch to check if that suffices for AVR or if a tiny additional patch is needed to register the keywords on the AVR arches; but, I do believe it allows the __flash qualifier to work on g++ also.  Which would be a HUGE improvement, actually.  (A simple preprocessor macro could then declare a C and C++ PROGMEM macro that would work on clang, clang++, gcc, and g++.  Thus far, only clang, clang++, and gcc can support one.)

Yet, because it's GCC, I give it about 3% chance of actually being accepted upstream within the next five years.  After all, the issue was only raised in 2016, which is "yesterday" in GCC terms.  Give it a decade or two, after it has been hashed out in academia first.

Full disclosure: I'd test the patch, but I'm on a laptop whose fan gets awfully loud when compiling GCC.  If anyone is up to it, and willing to check, I'd recommend doing so and reporting success to both GCC mailing list as well as the GCC bug 69549 (referring to the patch on the GCC mailing list).

[Kleinstein]

Datasheet does not seem to specify a lot about the expected lifetime of the components.
What could be a reference, experience with various chips, automotive/aerospace certifications, reputation?
I wonder what makes doped silicon last longer or fewer...

Silicon devices are generally slow aging. There was a big problem with the purple plague - but this is not the silcon itself but with the metal layers on top.
With modern µCs the limiting part can be the flash memory. Here the usually somewhat larger structures in the 8 bit parts should have a slight advantage, though the more advanced parts could include more error correction.

A limited lifetime was/is an issue with germanium parts - there the diffusion is fast enough to become a problem over long time, even at rrom temperature. Some sensitive GE detector want cooling 24/7 just to slow down the aging.

Even the modern 10 nm process parts seem to be stable for a least a few years. With diffusion processes the time scales with the ditance square and the coarser structured (e.g. 60 nm and up) parts should thus have no real problem with a diffusion limited lifetime.

[David Hess]

Ignoring abuse, including excessive junction temperature, most failures I have diagnosed were contamination through the package, or contamination of the silicon during production.

[Njk]

Interesting, if something is written in low-level language like assembly, it might be much easier to reverse engineer it. Much harder with a C++ binary for instance.

Typically, assembly language implies small code size, and that's the primary factor that makes it easier

Datasheet does not seem to specify a lot about the expected lifetime of the components.
What could be a reference, experience with various chips, automotive/aerospace certifications, reputation?
I wonder what makes doped silicon last longer or fewer...

It depends on datasheet. It's not unusual to see that data in the silicon vendor's documentation.

There are tons of papers on the subject, in the industry and academia. I just copy-pasted.

The primary wearout mechanisms in CMOS circuits:
- hot carrier injection (HCI);
- bias temperature instability (NBTI and PBTI);
- time-dependent dielectric breakdown (TDDB);
- electromigration (the electron wind in conductors).

The geometry contributes a lot. Generally, less nm number implies less MTBF so more advanced chips are not better from that perspective.

Perhaps that's statistically true, but I have a small TV streaming box. Such type of equipment is not designed to last long. The bottom side of the case is made of steel sheet and it's quite hot (about 40-50 degree C), so the thermally coupled heat-generating SoC inside the box is even more hot. And it's operating daily. In the next year we'll celebrate first decade of service life...

I always wonder where to split...
Encrypting everything makes it a nightmare to debug.
Encrypting nothing might expose dangerous things to Internet.

Indeed. Even with encryption, it's very easy to do something wrong. The Infinion issue is well-known. Someone did discover that with the Infinion RSA implementation it's possible to derive the private key from the public key. It was a disaster for Infinion. Entire countries were affected (e.g. Estonia).

For instance, would you encrypt communication between the various parts of a same machine, like an airplane flap and the cockpit?

I think it depends on application. If it's a military machine, why not? First, it'll force enemy to allocate more resources for reverse engineering of the captured machine, and it also provides the opportunity for the manufacturer to charge the customer more

---
WBR