EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: josuah on November 15, 2022, 05:23:34 pm
-
A lot of interesting approaches, and promising low-power, low-price, high-reliability (in various amount) in the 8-bit world.
I did not find a place that was comparing the architecture of these MCU, so I am collecting wisdom and trying to dive down this littlebig world and report what I found.
Note: I am not curious about which is better, just trying to understand what makes an 8-bit instruction set modern, and what is the way followed by 8-bit MCUs.
AVR is said to be a newer architecture, has a maintained GCC port (it was about to be dropped but survived!).
It has an interrupt system requiring the push all registers used by the ISR, which I think GCC can minimize as an optimization.
8051 have multiple register banks which dodge that problem by switching to a new set of registers while entering an interrupt and going back to the usual register set when leaving.
12T instructions (12 clocks ticks per CPU instruction) for everything... only for very old 8051, and 1T for most instructions for the modern 8051.
PIC uses paging for accessing RAM, instead of concatenating two registers (the "X", "Y", "Z" registers on AVR, or DPTR on 8051).
Mostly used with assembly, or a proprietary C toolchain or an endangered(?) SDCC compiler port.
MSP430, I do not know much about it, except it is a 16-bit arch which avoids some of the problems of 8-bit registers. I suppose 16-bit address space.
STM8 has interesting features such as having a single address space ("modified Harvard"?) for everything, I do not know much more.
PicoBlaze which is FPGA-Only is taking an interesting approach to use fewer LUT. https://en.wikipedia.org/wiki/PicoBlaze#Architectural_notes
But noone producing any of these on a foundry AFAIK.
Now in all of this, something I wonder: Why is AVR said to be a modern architecture than, say, 8051?
* The fact that it has 3 memory pointers? X, Y, Z vs just DPTR
* No limitation to just an accumulator register? Although does it much change anything in practice outside compiler optimization?
* The fact that it is 1T for most things? Which is also true for modren 8051
* A simpler instruction set encoding scheme? Like how RISC-V is said to be modern for having a easy to implement instruction decoding
Although looking at AVR and 8051, I find the AVR a bit more complex and irregular
https://en.wikipedia.org/wiki/Atmel_AVR_instruction_set#Instruction_encoding
https://en.wikipedia.org/wiki/Intel_8051#Instruction_set
* The limited set of instructions (RISC)? Recent 8051 are hardwired rather than microcoded (C8051 from these same EFM8BB), and 128 of the 256 instructions are for specifying the register to work on.
Last but not least, any hint in what makes an 8-bit power-efficient (how to get the core smaller, spend less time doing more things to go back to sleep quicker using less power, etc...) and simple to implement (say, on an FPGA) is welcome!
Thank you! :)
-
The microcontroller core is important, but not the only thing. The peripherals matter just as much, if not more.
AVR has a superb core and a port of GCC as a compiler.
The PIC core doesn't look as good to me, but PICs have a great peripheral system.
Now that Microchip has bought Atmel, some AVRs are appearing with PIC peripherals, which in my opinion is the best combination that could be made.
-
The STM8 is my favorite 8-bit MCU. It has a nice set of addressing modes, and the SP + offset is very handy. Writing to Flash and EEPROM is super easy. The interrupt vector table makes ISRs straightforward. Programming the chips is also fast and easy with ST-LINKv2 USB adapters.
-
The actual CPU part of a µC is usually only a small part of the chip. So the core size is less relevant. This makes it possible the 16 bit MSP430 to compete with the 8 bit ones. often ADC and similar mesured values are more like 10-12 bit wide and thus need 2 byte operations. So the 16 bit CPU makes absolute sense and indeed saves some hassles, e.g. with 8 bit acess to 16 bit counters or 10/12 bit ADC results.
With plenty of transistors available a small CPU is less important, it is now more about relatively small code a compiler can produce.
How much power a µC uses depends a lot on the production technology used - the instruction set is more like a small part here, though it does have some effect.
As an odd side effect the chips with more transistors may consume less power as they tend to use smaller strucktures.
The AVRs are relatively new (the 8051 and PICs (e.g. PIC16) are quite old and from times when the transistors in the actual CPU mattered a bit more).
To make a GCC port easy the AVR CPU has quite a lot of similar CPU registers and avoids the RAM / register paging of the 8051 / PIC than can make programming quite a hassel.
However the separate code / RAM adress spaces also causes some hassels for the compiler / programmer.
The more RISC like commands (seprate load/store and ALU commands) also works well with the opimization of modern compilers made with Risc processors in mind. The compilers have also changed: In the early days the stack oriented TMS1000 was easy for a compiler.
AFAIK a large point to make the AVRs quite popular was also that they were relatively fast to include flash memory instead of OTP memory.
Having to save the registers by the ISR code is a common solution, it keeps the CPU simple and in most cases only some registers are needed and this part is more like easy for the compiler.
-
A lot of interesting approaches, and promising low-power, low-price, high-reliability (in various amount) in the 8-bit world.
I did not find a place that was comparing the architecture of these MCU, so I am collecting wisdom and trying to dive down this littlebig world and report what I found.
Note: I am not curious about which is better, just trying to understand what makes an 8-bit instruction set modern, and what is the way followed by 8-bit MCUs.
It is useful to include the opcode size range, for MCU comparisons.
eg PIC's vary with 12 and 14 and 16b opcodes, for various models, and the tiny PICs have very limited HW stacks.
8051 have 1,2,3 byte opcodes
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.
You could also include parts like Zilog Z8 (8b) and Siemens (infineon) C166 (16b) FWIR those both used a register frame pointer, which allowed register banks to be moved across RAM space.
That expanded on the 8051's 4 register banks for interrupts.
Last but not least, any hint in what makes an 8-bit power-efficient (how to get the core smaller, spend less time doing more things to go back to sleep quicker using less power, etc...) and simple to implement (say, on an FPGA) is welcome!
power-efficient is mostly the process.
getting the core smaller usually means getting it simpler. eg Multiply and Divide are nice to have but costly in core area.
-
Glad to see this thread sparkling with answers. Thank you all!
The microcontroller core is important, but not the only thing. The peripherals matter just as much, if not more.
The actual CPU part of a µC is usually only a small part of the chip.
So this would mean quite some room to implement something efficient even while trying to save as much space as possible.
To quote another thread:
Quite honestly, I don't really care what core a MCU have. It's like having 30 peripherals on it, and the 31st is the core.
Now that Microchip has bought Atmel, some AVRs are appearing with PIC peripherals, which in my opinion is the best combination that could be made.
I forgot to evoke how many peripheral the PIC range had! It feels like they are adding a CPU core to an ASIC more than adding a peripheral to a MCU.
The STM8 is my favorite 8-bit MCU. It has a nice set of addressing modes, and the SP + offset is very handy. Writing to Flash and EEPROM is super easy. The interrupt vector table makes ISRs straightforward. Programming the chips is also fast and easy with ST-LINKv2 USB adapters.
Really looks like https://jaycarlson.net/ said, an ARM in disguise.
I need to try them some day!
modern compilers made with Risc processors in mind. The compilers have also changed [...] only some registers are needed and this part is more like easy for the compiler.
Interesting: the user of assembly is moving from text editor to compiler, so the MCU would likewise evolve target their new user (copmilers).
It is useful to include the opcode size range, for MCU comparisons.
Which I totally forgot.
You could also include parts like Zilog Z8 (8b) and Siemens (infineon) C166 (16b) FWIR those both used a register frame pointer, which allowed register banks to be moved across RAM space.
That expanded on the 8051's 4 register banks for interrupts.
Thank you! I was wondering about how it 8051 came-up with that strategy.
power-efficient is mostly the process.
So power efficiency would then not be so tightly coupled with architecture... Interesting.
Maybe along with some features to permit jumping to low-power modes and staying as long as possible https://ww1.microchip.com/downloads/en/Appnotes/AN2515-AVR-Low-Power-Techniques-00002515C.pdf#page=13
getting the core smaller usually means getting it simpler. eg Multiply and Divide are nice to have but costly in core area.
So a matter of trade-off at least as much as implementation.
-
Not sure if you've heard/read Jay Carlson's "The amazing 1$ microcontroller" article / post : https://jaycarlson.net/microcontrollers/
He goes through 21 microcontrollers under 1$ and discusses performance, differences, ease of compiling and other things.
-
Not sure if you've heard/read Jay Carlson's "The amazing 1$ microcontroller" article / post : https://jaycarlson.net/microcontrollers/
He goes through 21 microcontrollers under 1$ and discusses performance, differences, ease of compiling and other things.
It was a very good read! I read it about 2 times. Well 3 times now. :)
China doesn’t care about patents, just accessibility and cost. Can’t implement a core when you don’t have the design files. So everything was 8051 because the designs were readily available and free.
-- https://hackaday.com/2022/11/09/chinese-chips-are-being-artificially-slowed-to-dodge-us-export-regulations/#comment-6530447
-
You could also include parts like Zilog Z8 (8b) and Siemens (infineon) C166 (16b) FWIR those both used a register frame pointer, which allowed register banks to be moved across RAM space.
That expanded on the 8051's 4 register banks for interrupts.
Thank you! I was wondering about how it 8051 came-up with that strategy.
My wording may have been poor. The 8051 is older and used 4 register banks, and 2 bits to select which bank was used, but those 4 banks were fixed in RAM space.
The Z8 and C166 are newer, and the improved technology allows them to have larger multi-port RAM and so they have more bits to position the registers in RAM space.
power-efficient is mostly the process.
So power efficiency would then not be so tightly coupled with architecture... Interesting.
Maybe along with some features to permit jumping to low-power modes and staying as long as possible https://ww1.microchip.com/downloads/en/Appnotes/AN2515-AVR-Low-Power-Techniques-00002515C.pdf#page=13 (https://ww1.microchip.com/downloads/en/Appnotes/AN2515-AVR-Low-Power-Techniques-00002515C.pdf#page=13)
Yes. Modern MCUs have multiple internal Oscillators with lower frequency ones helping snooze control.
Many also have on chip regulators, and those have control bits to trade off quiescent power vs core speed.
They also specify wake-up times from the low power modes.
On the topic of power, one of my peeves has been the poor pre-reset power specs of even recent MCUs - many take mA when held in reset, as the default high speed oscillator is on and a lot is running.
I see just recently, Nuvoton has defined a 8051 variant part with low power pre-reset. Tho their 200uA does not seem too low, maybe that is simply a power optimised HFOSC trade off ?
they spec 7.3728 MHz MIRC oscillator with variation ±10 % within all temperature range
These days 10% is not great and 7MHz is lowish, but could be chosen if power were the main focus
https://www.nuvoton.com/products/microcontrollers/8bit-8051-mcus/low-power-mug51-series/ (https://www.nuvoton.com/products/microcontrollers/8bit-8051-mcus/low-power-mug51-series/)
• Power Management
- Integrated with Power-on Reset, Brown-out Reset and Low voltage Reset
- Normal run: 1.08 mA at 7.3728 MHz
- Power-down: 1 μA
- Power-on before Flash memory is initialized：200 μA
- Supports wake up from Power-down mode by: ACMP, GPIO, WDT, TIMER, UART, I²C, SPI, PDMA, PWM
they say Target application： Stylus pen RFID card so they must have a specific large customer ? :)
It would also be useful for mains-dropper designs, and solar cells where source is effectively current only.
-
MSP430, I do not know much about it, except it is a 16-bit arch which avoids some of the problems of 8-bit registers. I suppose 16-bit address space.
Essentially a DEC PDP-11 expanded to 16 registers instead of 8, and more instructions, in the same fixed-size 16 bit opcode by cutting the available addressing modes, especially for the result of the instruction.
Apparently they are very low power. And for sure more compact code and a lot faster than 8 bit CPUs if you actually have to deal with 16 bit quantities or larger amounts of RAM.
If you are talking about stand-alone microcontroller chips then the actual silicon inside is a relatively small part of the total cost, vs for example packaging and testing, and even 32 bit CPUs are now price-competitive. e.g. see the other thread about $0.10 RISC-V microcontrollers from WCH.
-
This is not a reasonable comparison. You list different totally unrelated features for different MCUs. You need to get a single feature which you dim is important and compare it accross different MCUs. Then proceed to the next important feature and so on ...
Modern is something that appeared recently, as opposed to ancient which appeared in some relatively distant past. There's nothing to consider here except the release date.
-
My wording may have been poor. The 8051 is older and used 4 register banks, and 2 bits to select which bank was used, but those 4 banks were fixed in RAM space.
The Z8 and C166 are newer, and the improved technology allows them to have larger multi-port RAM and so they have more bits to position the registers in RAM space.
Thank you for clarifying, it was me who read it the other direction.
On the topic of power, one of my peeves has been the poor pre-reset power specs of even recent MCUs - many take mA when held in reset, as the default high speed oscillator is on and a lot is running.
[...]
It would also be useful for mains-dropper designs, and solar cells where source is effectively current only.
If the chip keeps resetting due to brown-out, it would drain more power if pre-reset uses a lot of power. I never thought about measuring the power before chips start.
I see just recently, Nuvoton has defined a 8051 variant part with low power pre-reset.
They also look like having DMA support. That reminds me of http://elm-chan.org/docs/avr/avrdma_e.html (http://elm-chan.org/docs/avr/avrdma_e.html) which uses DMA through an external RAM chip.
These days 10% is not great and 7MHz is lowish, but could be chosen if power were the main focus
[...]
they say Target application： Stylus pen RFID card so they must have a specific large customer ? :)
After all, if a custom design just for one client can be interesting to someone else, why not sell it to everyone...
-
This is not a reasonable comparison. You list different totally unrelated features for different MCUs. You need to get a single feature which you dim is important and compare it accross different MCUs. Then proceed to the next important feature and so on ...
This is true.
Modern is something that appeared recently, as opposed to ancient which appeared in some relatively distant past. There's nothing to consider here except the release date.
I was fooled into thinking this: earlier designs used the best of what could be done, with newer designs adding "well-known improvements", with a rather linear evolution where date tells mostly which step of the common evolution we are at.
But discovering further, it looks like it is not as homogeneous and consensual, and different approaches are getting interesting performances in different cases.
-
Essentially a DEC PDP-11 expanded to 16 registers instead of 8, and more instructions, in the same fixed-size 16 bit opcode by cutting the available addressing modes, especially for the result of the instruction.
A PDP-11 fitting in a small corner of a 3mm x 3mm package!
Apparently they are very low power. And for sure more compact code and a lot faster than 8 bit CPUs if you actually have to deal with 16 bit quantities or larger amounts of RAM.
The MSP430 parts are 16-bit processors They are von Neumann architecture, and very low power.
I realize I mistook 8-bit for low-power. Afterall, it is only a matter of data bus size, not sure that takes so much power just for that point.
If you are talking about stand-alone microcontroller chips then the actual silicon inside is a relatively small part of the total cost, vs for example packaging and testing, and
It looks like I was mislead about the importance of the CPU core within an MCU.
even 32 bit CPUs are now price-competitive. e.g. see the other thread about $0.10 RISC-V microcontrollers from WCH.
Astonishing.
-
MSP430, I do not know much about it, except it is a 16-bit arch which avoids some of the problems of 8-bit registers. I suppose 16-bit address space.
Many are actually MSPX, which has a 20-bit address space but is fully backwards compatible. The MSPX core also has a slightly improved instruction set. But, personally, if a project doesn't fit in a 16-bit address space I'd rather use an ARM based processor than deal with address space segmentation hassles. But I usually enable the MSPX extensions for improved code generation, only with the plain 16-bit space.
I think where the 20-bit space might make sense is if you have an existing design and just have to squeeze a bunch more stuff in there that simply can't fit. With some adhocery sprinkled with ugly hacks it can be made to fit and work - and ship in a timely manner. It'll be on a downward slope of code maintenance hell though, so better only happen to something that is not going to need more than the occasional bug fix ever.
-
I was fooled into thinking this: earlier designs used the best of what could be done, with newer designs adding "well-known improvements", with a rather linear evolution where date tells mostly which step of the common evolution we are at.
But discovering further, it looks like it is not as homogeneous and consensual, and different approaches are getting interesting performances in different cases.
By any means, modern doesn't necessarily mean better. Comparing performance of different MCUs is at best difficult. There are little things here and there which may affect performance under certain conditions, but may be totally irrelevant in other cases. There's lots of opinions, but they're usually worthless - people like what they use (whatever it is) and they will tell you that this is the best.
-
Why is AVR said to be a modern architecture than, say, 8051?
It's designed to better support high level languages. Multiple index registers is part of that. Many general purpose registers (as in - ALU operations can occur between any two registers) is part of that. A large stack is part of that. Taking ideas from RISC research is part of that (in particular: all alu operations are between registers, only load/store operations access memory.) Not having a limit of 256bytes of "internal RAM" (with "external RAM" access limited to a couple of instructions) is part of it.
8051 have multiple register banks
most modern 8051 are 1T
Recent 8051 are ...
Better be careful. You sound like you're looking at "some" modern 8051 variants and assuming that "many" 8051s have those features. My impression is multiple register banks and 1T 8051s are relatively rare (6T seems common, though.) (oh wait. You mean R0-R7, and not AC, PSW...)
(Hmm. Anyone know of a table somewhere that lists current 8051-based processors along with which "modernizations" they support?)
A simpler instruction set encoding scheme? ...
Although looking at AVR and 8051, I find the AVR a bit more complex and irregular
The AVR instruction set is annoying to encode/decode by human (sometimes a register field in an instruction is 4 bits, sometimes it's 5 bits, sometimes a field is spread across non-contiguous bits, etc. But it's no more complex than others to a compiler or to the hardware. (another RISCy principle: design the instruction set and encoding for compilers, not for humans.)
-
8051 have multiple register banks
most modern 8051 are 1T
Recent 8051 are ...
Better be careful. You sound like you're looking at "some" modern 8051 variants and assuming that "many" 8051s have those features. My impression is multiple register banks and 1T 8051s are relatively rare (6T seems common, though.) (oh wait. You mean R0-R7, and not AC, PSW...)
(Hmm. Anyone know of a table somewhere that lists current 8051-based processors along with which "modernizations" they support?)
All 8051's since the original intel release, have multiple register banks, (4) and 2 bits in the PSW select the bank.
Intel did a revision to support 4 interrupt priority levels, up from 2, and that has propagated into many/most new designs too.
1T 8051's are by far the most common new devices in 2022, and 6T parts are very much NRND and EOL.
The differences in the 1T parts in 2022 now comes down to how wide their fetch from CODE is, so they are not all the same
STC 1T parts do a 32 bit fetch, and that means most 2,3 byte opcodes are also all 1T
SiLabs EFM8BB52 parts have 4 level interrupt priority, and their speed is mostly 1T per byte, but they have a somewhat higher SysCLK rating than STC.
However, not all vendors are fully clear on their opcode timings.
I can find SinOne timings for old SC91F parts (~ 1T/Byte) but not for their new SC95F series, that the prose suggests is faster.
-
By any means, modern doesn't necessarily mean better.
I will have to get used to it.
Comparing performance of different MCUs is at best difficult. There are little things here and there which may affect performance under certain conditions, but may be totally irrelevant in other cases. There's lots of opinions, but they're usually worthless - people like what they use (whatever it is) and they will tell you that this is the best.
Thinking again, criterion for selecting 8-bitters it is more likely a combo of peripherals, price, power, memory, and availability than actual core architecture and performance.
All things equal remains personal preferences and knowledge already invested to understand each.
It's designed to better support high level languages. [...] is part of that [...].
I have read about some 8-bit MCU architectures being harder to optimize by C compilers, and I would not wish to write too complex application logic in assembly.
encoding for compilers, not for humans
This sounds like avr-gcc is accounting for a good part of AVR popularity.
Essentially a DEC PDP-11 expanded to 16 registers.
All 8051's since the original intel release, have multiple register banks, (4) and 2 bits in the PSW select the bank.
Intel did a revision to support 4 interrupt priority levels, up from 2, and that has propagated into many/most new designs too.
1T 8051's are by far the most common new devices in 2022, and 6T parts are very much NRND and EOL.
I am surprised to see how far ago these design root from, most likely very different to today's iterations.
It might be about giving solutions people were already used to.
-
I am surprised to see how far ago these design root from, most likely very different to today's iterations.
It might be about giving solutions people were already used to.
Many old designs are rubbish, but some ideas have stood the test of time. Equally, new designs from people who have not carefully studied the best of the past are very likely to be rubbish too.
PDP-11 is one of those classic designs that works very well with single-issue non-pipelined machines with fast RAM (e.g. microcontrollers with SRAM). If you know it you will see very strong echoes in M68k (and more recent ColdFire), MSP430, and SuperH. Those successors use various techniques to expand it from 8 to 16 registers:
- M68k: 8 data registers plus 8 address registers, with when set is used implicitly determined by the instruction (plus some doubling up of opcodes)
- MSP430: expand register fields from 3 to 4 bits, decrease addressing mode fields from 3 bits to 2 (src) or 1 (dst) bits.
- SuperH: expand register fields from 3 to 4 bits, only load/store have addressing modes, arithmetic is only on registers.
In addition, M68k and SuperH expand it from 16 to 32 bits.
You could also argue that ARM is PDP-11 influenced (maybe via M68k).
Features that the above generally share (not all have them all):
- very similar condition codes and compare/branch instructions
- similar sets of addressing modes, including especially register indirect with pre-decrement and/or post-increment
- including SP and PC as general purpose registers, with addressing modes applied to them to get functionality such as push, pop, immediate and absolute addressing that require dedicated instructions in other ISAs.
-
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++")
It's pretty nice to program in assembly language as well. But I wouldn't want to have to decode a binary dump of the program memory! (fortunately, that's rarely necessary these days.)
I'd say that the instruction set is about half "real" RISC, and half "extensions for microcontroller use" (like single-instruction pin setting and bit twiddling.)
(And you look at the code produced by the compiler, and say "that's almost as I could do in assembly", instead of "eww! Well, it fits and it's good enough, I guess." (which is how I feel about C produced by PIC compilers, and I suspect 8051 is similar.))
1T 8051's are by far the most common new devices in 2022
Who cares about "new devices"? My impression is that the vast majority of 8051-architecture chips sold these days are actually Asian System-on-Chip things like MP3 players, or Mouse controllers, or flash memory controllers, or ... etc. Or "legacy" chips that aren't new at all (Microchip, for example, sells a whole range of 8051 chips that they've acquired via corporate acquisitions. 12T, 6T, 1T... Lots of choices. But I don't think they're doing any "new" 8051 chips.
-
Or that what avr-g++ implements is "real C++")
Why on Earth not? What do you/they think is missing?
Certainly, the Arduino environment uses a non-standard library, but that's an entirely different question. You can perfectly well use standard C++ with all features and the standard C++ library as well if you want to -- RAM size permitting: better be on a Mega2650, preferably with external RAM (you can get 64k total).
-
I suspect 8051 is similar.
Depends on the compiler, but you ain't gonna do much better than Keil C51.
It's the main reason the 8051 arch has survived this long IMO.
I recall finding one Chinese 8051 mcu manufacturer that had a free download of hacked Keil C51 on their website :-\
-
I think where the 20-bit space might make sense is if you have an existing design and just have to squeeze a bunch more stuff in there that simply can't fit. With some adhocery sprinkled with ugly hacks it can be made to fit and work - and ship in a timely manner. It'll be on a downward slope of code maintenance hell though, so better only happen to something that is not going to need more than the occasional bug fix ever.
The STM8 has optional 24-bit addressing, necessary to make full use of the larger parts with more than 32 KB flash (you might think it should be 64 KB, but flash starts at 0x8000). With SDCC at least, it's for the most part completely transparent. Just a question of setting the appropriate memory model command line option.
I say for the most part because there is one gotcha: function pointers are only ever 16-bit, so if you try to take a pointer to a function stored in flash at an address greater than 0xFFFF, things won't work properly.
-
At least the Keil C51 supplied with cypress parts seems to be very suboptimal in comparison with IAR.
Some problems with the '51 are that the code gets large for anything using pointers, shuffling chunks of memory around is painfully slow. The compiler (IAR) has quite a bit of smarts but pointer related, just forget it. The banks, yeah well not the panacea. Yeah, we produce chips with '51 cores in them (1), a pain to program for, too many desired features too little ROM/OTP :(. Ours is also a 1 T job with prefetch...
-
Or that what avr-g++ implements is "real C++")
Why on Earth not? What do you/they think is missing?
Exceptions. STL. Lib-g++. "new"
(there was a "not everyone" in the original sentence, right? Personally, I'm quite willing to separate the libraries from "The Language" and hunt around for the "modified" STL modules that might actually be convenient, if I really need them. But I'm sure I can find C++ programmers who will tell me that I'm not really programming in C++, I'm "just using C with Classes (https://softwareengineering.stackexchange.com/questions/48401/learning-c-properly-not-c-with-classes)")
-
All 8051's since the original intel release, have multiple register banks, (4) and 2 bits in the PSW select the bank.
Intel did a revision to support 4 interrupt priority levels, up from 2, and that has propagated into many/most new designs too.
1T 8051's are by far the most common new devices in 2022, and 6T parts are very much NRND and EOL.
I am surprised to see how far ago these design root from, most likely very different to today's iterations.
It might be about giving solutions people were already used to.
Yes, legacy is both a blessing and a curse. 8)
It shows how software costs can dominate a projects costs.
1T 8051's are by far the most common new devices in 2022
Who cares about "new devices"?
Umm, people doing new designs ? 8)
New devices also show where the MCU vendors are putting their money.
(Microchip, for example, sells a whole range of 8051 chips that they've acquired via corporate acquisitions. 12T, 6T, 1T... Lots of choices. But I don't think they're doing any "new" 8051 chips.
Correct, Atmel released the AT89LP series which were 1T parts but they did not survive the Microchip take over, which saw Microchip have too many MCUs .....
AT89LP parts are still used in production, but I'd tag them NRND as there are 'better alternatives'
1T 8051's are by far the most common new devices in 2022
My impression is that the vast majority of 8051-architecture chips sold these days are actually Asian System-on-Chip things like MP3 players, or Mouse controllers, or flash memory controllers, or ... etc. Or "legacy" chips that aren't new at all
'sold' is always hard to quantify, especially on custom parts, but there is a lot of new device activity on 8051 cores.
SiLabs has recently released their EFM8BB52, which are wide Vcc 5V operating with on chip regulators. ( 8 bit AVR's have only just caught up to on-chip regulators)
There is a lot of activity around what I'd call a 'new 20 pin pinout standard', which was pioneered by the STM8S003, and you now see a lot of '003' pin compatible parts with 8051/ARM/RiscV cores
Typically those families have 002/003/004/005 etc in the part number.
The STM8S003 parts were very cheap in asia, some years back, but then the price shot up, and second sourcing became important.
A quick check at LCSC shows the STM8S003 still well stocked, but at a premium price (100+ US$1.2075) over Nuvoton, Holychip, SinOne, RunJet, Fuman, OnBright, LnChip etc pin compatible alternatives.
-
"just using C with Classes"
I am happy with C, but when pushed toward C++, I like "C with Classes" better.
Or rather writing a C library, and wrapping it with a C++ interface.
It helps me to check if a bug is related to the data processing, or the abstraction on top of it.
-
... when pushed toward C++ ...
What is pushing you towards C++?
-
... when pushed toward C++ ...
What is pushing you towards C++?
The wind? ;D
-
The project I need to work on, or tool I need to debug.
For instance, YoSys is a bit closer to C, and Verilator is really C+++++
-
... when pushed toward C++ ...
What is pushing you towards C++?
The wind? ;D
:D
-
Someone mentioned AVRs with PIC periferical s.
Can anyone give me some examples, i am curious and want to see what would be new/better then lets say an atmega328?
-
what would be new/better then lets say an atmega328?
Presumably the AVR-Dx families (https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/8-bit-mcus/avr-mcus/avr-db), and perhaps including Mega0 (ATmega4809) Tiny-0, Tiny-1, and Tiny-2
AVR-DB, for example:
The AVR® DB family of microcontrollers feature the well-known AVR® CPU, now running at up to 24 MHz across the full supply voltage range of 1.8V to 5.5V. The family includes 32 KB, 64 KB, and 128 KB Flash variants in 28- to 64-pin package options. The AVR® DB family is designed to bring analog signal conditioning, real-time control, and multi-voltage operation to applications including industrial control, home appliance products, automotive, and Internet of Things (IoT).
The family uses the latest Core Independent Peripherals with low-power features and 5V operation for increased noise immunity. The Analog Signal Conditioning (ASC) module includes three OPAMPs, which can form gain stages and filter functions allowing signal conditioning with down to zero external components. The Multi-Voltage I/O system allows safe bi-directional communication with systems running at a different voltage. The Event System, Configurable Custom Logic (CCL), along with intelligent analog peripherals like 12-bit differential ADC, Zero-Cross Detect (ZCD), 10-bit DAC together with the ASC and MVIO makes the AVR® DB family well suited for sensor applications, IoT end nodes and other applications where signal conditioning or level-shifting is needed.
-
I think AVR is one of the best with a huge range of products , great support , nice architecture , good tools and a big community
-
Someone mentioned AVRs with PIC periferical s.
Can anyone give me some examples, i am curious and want to see what would be new/better then lets say an atmega328?
Not sure what the question entails exactly. A generic answer would be: almost any MCU available at the moment if it wasn't designed 25+ years ago.
-
Someone mentioned AVRs with PIC periferical s.
Can anyone give me some examples, i am curious and want to see what would be new/better then lets say an atmega328?
I mentioned it.
For example the CTMU module:
https://www.microchip.com/stellent/groups/SiteComm_sg/documents/DeviceDoc/en542792.pdf (https://www.microchip.com/stellent/groups/SiteComm_sg/documents/DeviceDoc/en542792.pdf)
Or the Configurable Logic Cells:
https://ww1.microchip.com/downloads/en/DeviceDoc/40002188A.pdf (https://ww1.microchip.com/downloads/en/DeviceDoc/40002188A.pdf)
Numerically Controlled Oscillator:
https://ww1.microchip.com/downloads/en/Appnotes/90003131A.pdf (https://ww1.microchip.com/downloads/en/Appnotes/90003131A.pdf)
And so on.
https://microchipdeveloper.com/8bit:peripherals (https://microchipdeveloper.com/8bit:peripherals)
-
Someone mentioned AVRs with PIC periferical s.
Can anyone give me some examples, i am curious and want to see what would be new/better then lets say an atmega328?
Not sure what the question entails exactly. A generic answer would be: almost any MCU available at the moment if it wasn't designed 25+ years ago.
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.
-
IMHO nowadays you should go for a microcontroller which has a continuous memory space of at least 64kB.
You should go for a microcontroller which is suitable for your project. That's how it's always been, that's how it is, and that's how it will be until the end of Humanity.
-
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.
That's too general a claim. Plenty of MCU tasks need nowhere near 64k.
What is happening in the general small MCU space, is the 'smallest code' parts are slowly getting larger, as process changes ripple through.
Two decades ago, there used to be 1k and 2k code size variants of small MCUs.
Fast forward to 2022, and the smallest new MCUs released tend to be 8k or 16k code, they simply do not bother with less code size.
eg I see a roadmap for a 2mm x 2mm 8 bit MCU where the smallest code size is 16k
-
IMHO nowadays you should go for a microcontroller which has a continuous memory space of at least 64kB.
You should go for a microcontroller which is suitable for your project. That's how it's always been, that's how it is, and that's how it will be until the end of Humanity.
Yes, and NRE for microcontrollers with a crappy CPU core is extremely high. Development time is hard to predict due to all the detours you need to take in order to write the firmware. And you'll need specialist software engineers as well which cost a ton of money. So yes, a microcontroller with a continuous memory space is the best choice if you want to get a product out on time without breaking the bank.
@PCB.Wiz: It is not about the amount of memory, but the ability to write C in a normal way so code can be re-used regardless the platform (instead of having glorrified assembly disguised as C). Nowadays one of the biggest assets of companies that develop electronics is their software library and the ability to keep reaping the benefits from code that has been written before. I have been doing embedded software development for a while and I have managed to get quite a few projects simply due to the fact that I have a broad library of software that runs on almost every platform as long as it supports pointers. That gets me and my customers ahead of the competition because I can keep development time & NRE costs low.
-
@PCB.Wiz: It is not about the amount of memory, but the ability to write C in a normal way so code can be re-used regardless the platform. Nowadays one of the biggest assets of companies that develop electronics is their software library and the ability to keep reaping the benefits from code that has been written before. I have been doing embedded software development for a while and I have managed to get quite a few projects simply due to the fact that I have a broad library of software that runs on almost every platform as long as it supports pointers. That gets me and my customers ahead of the competition because I can keep development time & NRE costs low.
The largest impediment to portable MCU code, is not the compiler, but the peripherals.
It sounds like your working space, is quite some distance from the Tiny MCU's mentioned in this thread title.
Over the years, we did many MCU projects in Assembler, and HLL, and had zero need to port to another MCU. Sometimes we upgraded to newer variants.
We did a few projects where we supported multiple vendors, of the same multisource cores, from a single HEX file so it did not matter which MCU products used.
For those, pointers was never a question, it was the peripherals that were the main issue, and usually we could find some SFR pattern that was unique to each vendor.
-
Fast forward to 2022, and the smallest new MCUs released tend to be 8k or 16k code
The new AVRs include Tiny-0 and Tiny-1 parts with as little as 2k of code memory (8 and 14 pin packages.) But they're generally not any cheaper than the 4k versions.
But I do remember when I bought some ATmega48 chips as "the big chips with lots of memory!" (4k instead of 1k/2k)
-
@PCB.Wiz: It is not about the amount of memory, but the ability to write C in a normal way so code can be re-used regardless the platform. Nowadays one of the biggest assets of companies that develop electronics is their software library and the ability to keep reaping the benefits from code that has been written before. I have been doing embedded software development for a while and I have managed to get quite a few projects simply due to the fact that I have a broad library of software that runs on almost every platform as long as it supports pointers. That gets me and my customers ahead of the competition because I can keep development time & NRE costs low.
The largest impediment to portable MCU code, is not the compiler, but the peripherals.
It sounds like your working space, is quite some distance from the Tiny MCU's mentioned in this thread title.
Not necessarily. I have some super lightweight APIs that are very easy to adapt to different peripherals. From there I can copy & paste in things like dealing with external I2C, SPI devices like ADCs, memories. Also UART handling and text processing, etc. Most of it originates from 8051 / MSP430 projects.
-
IMHO nowadays you should go for a microcontroller which has a continuous memory space of at least 64kB.
You should go for a microcontroller which is suitable for your project. That's how it's always been, that's how it is, and that's how it will be until the end of Humanity.
Yes, and NRE for microcontrollers with a crappy CPU core is extremely high.
Are you suggesting that all MCUs with under 64 KBytes ROM have crappy CPU cores?
-
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.
-
Fast forward to 2022, and the smallest new MCUs released tend to be 8k or 16k code
The new AVRs include Tiny-0 and Tiny-1 parts with as little as 2k of code memory (8 and 14 pin packages.) But they're generally not any cheaper than the 4k versions.
Yes, but Microchip are more unusual in generating a lot of part numbers from one die.
The Tiny-0 series derives from a 16k part, that they also release at 8k/4k/2k in the 14 pin version.
Likewise the newer AVR-DD series is 64k down to 16k, in 14 pin packages, so you can see the lower code sizes simply falling off the table.
Other vendors are moving to fewer derived part numbers, which I agree with, as it avoids distributor dilution effects..
-
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.
That's not what it was about.
The VAX was designed with two main goals:
1) support a flat 32 bit address space with page-based virtual memory
2) allow assembly-language programmers to write programs using fewer lines of code (fewer instructions), in the belief that the main productivity driver.
The VAX was to solve the "software crisis", in which computer hardware was getting exponentially cheaper while programmers were getting more expensive, and as computers got cheaper more sites bought them and they all needed more and more custom software.
DEC knew full well that the VAX 11/780 would be a little slower than a PDP 11/70 on software that fit on a PDP 11, but it DIDN'T MATTER because the machines were going to be so much cheaper (certainly by the time they got to the 2nd or 3rd model) so the customer could just buy several of them if necessary. And VAX code would get written so much more quickly with the more expressive instruction set and without the 64 KB memory limit.
As for Intel throwing silicon at the problem, that is true to a certain extent, but *both* PDP11 and VAX have fundamental problems that make them less able to use advanced implementation techniques than x86. Except for a couple of weird cases such as MOVSB, x86 instructions only ever have one memory operand and -- more importantly -- that operand only accesses one memory address.
VAX has up to six or so memory operands (with three being extremely common). PDP-11 only has two. But that is still much worse than one.
And even PDP-11 has addressing modes that load something from memory and then use the thing just loaded as a pointer to load or store the actual data somewhere completely different in memory.
You can split up these multiple operands and complex addressing modes into µops, but the *problem* is that a single instruction can cause four different TLB misses / page faults on the PDP-11 and dozens on the VAX, and this makes it really really hard to save pipeline state, call an OS handler to fix everything up, and return to the right part of the instruction that had the problem.
x86 only ever accesses one memory address with one instruction, making things much much simpler.
In fact x86 can get two page faults from a single instruction if the data being accessed is misaligned AND crosses a 4K page boundary. But this is both extremely rare AND something that the page fault handler can detect, and fix up both adjacent pages at the same time before returning. And just retry the whole instruction again from the start.
-
[new avrs include] Tiny-0, Tiny-1, and Tiny-2
hackaday just linked this nice summary of the new Tiny chips: http://www.technoblogy.com/show?3UKF (http://www.technoblogy.com/show?3UKF)
-
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.
Separate IO is a bit less critical. For 8 bit CPUs this usually means less than 64 kB of ROM to have RAM and ROM in the same 64 kB adress space.
Anyway for small programs code portability is not that much an issue.
-
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.
-
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.
-
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?
-
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.
-
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 :palm:
-
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 :palm:
-
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.
-
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.
-
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.
-
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.
-
Maybe you should try to understand what 'address space' actually means first!
-
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.
-
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.
-
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.)
-
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.
-
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).
-
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. :)
-
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...
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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 (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.
-
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.
-
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.
-
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.
-
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.
-
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.)
-
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.
-
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.
-
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 (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 (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 (http://ww1.microchip.com/downloads/en/DeviceDoc/doc7925.pdf)
Although it was still a separate product family at this point:
(https://www.eevblog.com/forum/microcontrollers/tiny-mcu-architectures-avr-pic-8051-stm8-msp430-custom-risc/?action=dlattach;attach=1651610;image)
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.
-
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...
-
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 (http://web.archive.org/web/20220511051704/https://www.avrfreaks.net/comment/2593311#comment-2593311)
https://github.com/arduino/ArduinoCore-megaavr/issues/11 (https://github.com/arduino/ArduinoCore-megaavr/issues/11)
-
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 (https://github.com/arduino/ArduinoCore-megaavr/issues/11)
Oh cool. I hadn't noticed that they actually implemented my suggestions!
-
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 ;D
-
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)
-
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 :'(
-
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 ;D
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.
-
Who said they were junk libraries?
Eh? You did, I was quoting you, although I didn't understand what you were on about either :)
-
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.
-
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
-
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.
-
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?
(https://i.stack.imgur.com/OhDoE.jpg)
-
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 (https://marc.info/?l=gcc&m=166506533426567&w=4) 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 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69549), 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 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69549) (referring to the patch on the GCC mailing list).
-
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.
-
Ignoring abuse, including excessive junction temperature, most failures I have diagnosed were contamination through the package, or contamination of the silicon during production.
-
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
-
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
I forgot how much of a budget sink the military domain could be.
And I forgot about the case of reverse-engineering and protecting the design, as opposed to protect the signal in operation.
Thank you for the feedback about durability of components, I knew very few about it.
-
I forgot how much of a budget sink the military domain could be.
And I forgot about the case of reverse-engineering and protecting the design, as opposed to protect the signal in operation.
In the multi-cultural environment, misunderstanding is a frequent event. We all are aware of that but sometimes one can make a mistake, me included. I think this is a terminology issue, when each party has different understanding of the same term.
In my understanding, encryption is a measure that protects the message from being read by an unintended recipient. In the ideal world, it's just not necessary because it brings inconvenience to everyone and effectively makes our live harder. While the other measures, such as check summing to protect message integrity, scrambling and other spectrum-shaping techniques to improve EMC, are not usually called encryption because the pursued goals are entirely different.
Perhaps that's the root cause. I really have no idea how encryption can help within a single machine. Perhaps the best use of cryptography in that case would be a digital signing to prevent proliferation of counterfeit parts. That's my best guess, I'm just trying to be open-minded to extract a bit of sense from every puzzling question. Sorry if you read something that I was not intended to convey.
---
WBR
-
In the multi-cultural environment, misunderstanding is a frequent event. We all are aware of that but sometimes one can make a mistake, me included. I think this is a terminology issue, when each party has different understanding of the same term.
For my part, "Budget Sink" might have been abusive.
In my understanding, encryption is a measure that protects the message from being read by an unintended recipient. In the ideal world, it's just not necessary because it brings inconvenience to everyone and effectively makes our live harder. While the other measures, such as check summing to protect message integrity, scrambling and other spectrum-shaping techniques to improve EMC, are not usually called encryption because the pursued goals are entirely different.
This helps finding the right questions, such as "in which context would the message be transported?", the classic "Which threat model should it be prepared for?"...
I assume checksumming is much more lightweight, and sometimes hardware-accelerated for even simple MCUs.
Perhaps that's the root cause. I really have no idea how encryption can help within a single machine. Perhaps the best use of cryptography in that case would be a digital signing to prevent proliferation of counterfeit parts. That's my best guess,
Complex vehicles might be bus protocols like CAN in cars, maybe something else in an aircraft.
If there is no cryptographic signature, any passenger close enough to the bus wires (piercing a hole) could send commands to control everything attached to that bus?
I'm just trying to be open-minded to extract a bit of sense from every puzzling question. Sorry if you read something that I was not intended to convey.
Thank you for the meaningful answers to my silly questions. :)
it is possible that I am trying to solve a problem with the wrong approach, or solving something that is not a problem.
---
Josuah.
-
A classic use case for in-system encryption is a flight data recorder for a military aircraft. It should record information including stuff likely to be of use to an enemy, such as positions and timing but which is needed for its primary purpose of accident investigation. Since the (encrypted) data, the encryption mechanism and the key will all be available to a hostile investigator, a ‘public’ key system can be used. The private key remains secure as it need never leave the accident investigation facility
-
In my understanding, encryption is a measure that protects the message from being read by an unintended recipient.
It can have more than one purpose.
Often, "secure" is a mix of three completely separate concepts:
- Privacy – the information is secure from observation by others
- Authenticity – the information is from a trusted party
- Integrity - the information was not modified or constructed by an untrusted party
Message authentication codes (MACs) do the third, and can also do the second if requirements are met. Unless the message also contains an unique value, a nonce (https://en.wikipedia.org/wiki/Cryptographic_nonce), included in the authenticated part of the message, the same message can be replayed by an outsider and therefore break authenticity (without breaking integrity).
If the nonce is observable to outsiders, being able to see all messages in order, an attacker who knows the method of generating the nonces, can use each message to exclude a small part of the vast numeric phase space, making brute-force attack the more feasible there is data observed, and eventually break the integrity and authenticity.
Message privacy is a two-sided blade. On one hand, by making the messages private, the nonce is not visible to the outsiders, and it can help keep the information authentic even when privacy itself is not a particular goal. On the other hand, by making predictable data private, one can significantly hinder the security of the cryptographic algorithms, because the predictable data (especially at the beginning) can make it very cheap to exclude significant fractions of the (admittedly vast) numeric phase space for the algorithm, making it possible to brute-force the encryption open.
The simplest, and arguably most powerful form, of symmetric encryption is exclusive-ORing the message bits with a cryptographically secure, unpredictable sequence of bits (keystream (https://en.wikipedia.org/wiki/Keystream)) that both ends can generate, but outsiders cannot guess or derive even when they see all messages passed. This itself is quite lightweight, as you can imagine; it is the establishment of such keystreams between parties when outsiders can see all messages passed that is the hard part (and nowadays typically involves public key cryptography, which is quite slow/computation-intensive).
For things like intravehicular buses, in cars and aeroplanes and such, privacy is typically not an important goal; it is the authenticity and integrity that makes encryption desirable. Professional developers in this field also use the privacy as a social tool for those not versed in cryptography or secure design in general, because laymen intuitively associate secrecy with security. In computer systems the picture is much more complicated, so making things private/secret even they really don't need to be, is often a secondary goal with basis in human policies instead of information security per se.
As nfmax wrote above, military flight data on the other hand is something you do want to keep private/secret especially after a plane crash, so encryption is an absolute must there.
Edit: WTF? The editor adds an unnecessary close-list tag at the end of my post. Post-Edit: Oooh, at some point it added one at the beginning too, so now it works as expected. Weird.
-
Editing was strange and different for me a couple of days ago (I've been on a short vacation so haven't been online much), but it has gone back to the old editor for me now.
-
Editing was strange and different for me a couple of days ago (I've been on a short vacation so haven't been online much), but it has gone back to the old editor for me now.
Yes, the old editor is much better than WYSIWYG, at least for me. I'm glad it's back :clap:
-
Often, "secure" is a mix of three completely separate concepts:
- Privacy – the information is secure from observation by others
- Authenticity – the information is from a trusted party
- Integrity - the information was not modified or constructed by an untrusted party
In French "Safety" and "Security" are both translated as the same word "Sécurité": something like "making sure that what intended happen" maybe.
It is the establishment of such keystreams between parties when outsiders can see all messages passed that is the hard part (and nowadays typically involves public key cryptography, which is quite slow/computation-intensive).
So small microcontrollers are likely to be kept away from anything like TLS and most handshakes.
For things like intravehicular buses, in cars and aeroplanes and such, privacy is typically not an important goal; it is the authenticity and integrity that makes encryption desirable.
Signing might not be as cumbersome as encryption to debug, but the overhead remains, and I imagine some communication bus involve small microcontrollers driving a simple function.
I imagine these will have a rather efficient core, eventually with 32-bit ALU, or perhaps crypto acceleration cores.
-
It is the establishment of such keystreams between parties when outsiders can see all messages passed that is the hard part (and nowadays typically involves public key cryptography, which is quite slow/computation-intensive).
So small microcontrollers are likely to be kept away from anything like TLS and most handshakes.
Small microcontrollers without external support, yes. Encryption in general is not excluded, it will just typically use prearranged keys.
However, there are cheap crypto chips like ATECC608A (https://www.microchip.com/en-us/product/ATECC608A) and ATECC608B (https://www.microchip.com/en-us/product/ATECC608B) that can do the handshake externally. With one of these, even public-key crypto is not outside small microcontrollers, even 8-bit ones.
For things like intravehicular buses, in cars and aeroplanes and such, privacy is typically not an important goal; it is the authenticity and integrity that makes encryption desirable.
Signing might not be as cumbersome as encryption to debug, but the overhead remains, and I imagine some communication bus involve small microcontrollers driving a simple function.
I imagine these will have a rather efficient core, eventually with 32-bit ALU, or perhaps crypto acceleration cores.
Well, many of the currently used cryptographic hash functions and ciphers require either look-up tables or benefit from 32-bit binary operations (bit shifts, and/or/xor), so kinda yeah.
However, even AES can be implemented on a small 8-bit microcontroller. For example, see AVR-AES-faster (https://github.com/rgrgrg/AVR-AES-faster) at github. While the achievable bandwidth is relatively low compared to 32-bitters, it can definitely be done for e.g. CAN message data (payloads only, treating each message as one 128-bit block) or UART.
As I described earlier, the reason for such encryption may not be 'secrecy', but really authenticity and integrity, which is easier to get right with encryption than it is with pure message authentication codes (due to the nonce stuff I mentioned).
-
However, there are cheap crypto chips like ATECC608A (https://www.microchip.com/en-us/product/ATECC608A) and ATECC608B (https://www.microchip.com/en-us/product/ATECC608B) that can do the handshake externally. With one of these, even public-key crypto is not outside small microcontrollers, even 8-bit ones.
I always forget to give a look at external chips.
However, even AES can be implemented on a small 8-bit microcontroller. For example, see AVR-AES-faster (https://github.com/rgrgrg/AVR-AES-faster) at github. While the achievable bandwidth is relatively low compared to 32-bitters, it can definitely be done for e.g. CAN message data (payloads only, treating each message as one 128-bit block) or UART.
Surprising to see the amount of software pushing AVR chip outside what they are expected to be able to do.
As I described earlier, the reason for such encryption may not be 'secrecy', but really authenticity and integrity, which is easier to get right with encryption than it is with pure message authentication codes (due to the nonce stuff I mentioned).
The use-cases are much more clear now.
Thank you all.
-
I say for the most part because there is one gotcha: function pointers are only ever 16-bit, so if you try to take a pointer to a function stored in flash at an address greater than 0xFFFF, things won't work properly.
Function pointers should be 24 bit in the large memory model. If you can reproduce the issue you mentioned, please file a bug report at https://sourceforge.net/p/sdcc/bugs/
For me, the following works fine when compiled via sdcc -mstm8 --model-large:
void (*p)(void);
void dummy(void) // A function just at the 64K boundary to give some tolerance to array size below.
{
dummy ();
}
void f(void)
{
}
const char array[32725] = {0}; // Large array to force f above 64 K.
void main(void)
{
p = &f;
(*p)();
}
-
Function pointers should be 24 bit in the large memory model.
Ah, so they are. I must admit last time I looked at it in detail was a few years ago, so maybe something changed since 3.x times. Or perhaps I'm mistaken.
-
Thanks to this thread i remembered how nice STM8's are.
I dug out an STM8207RB a few days ago and it's now playing 8 channel Amiga protracker tunes mixed at 31kHz (in stereo with true panning) outputting 16 bit (ish) PWM at 125Khz, I did overclock to 32Mhz but so far i'm only using about 52% cpu time!
-
So ...
I was browsing ST's website last night and ALL the STM8's are now marked as NRND! Oddly i couldn't find any mention from ST that these parts are being discontinued, has anyone here heard anything?
-
So ...
I was browsing ST's website last night and ALL the STM8's are now marked as NRND! Oddly i couldn't find any mention from ST that these parts are being discontinued, has anyone here heard anything?
I believe the STM8 was originally designed to only be marketed in China. It was later spread to other markets. It did well in China for a while, but local MCU makers are probably giving it a really hard time now. Maybe it has become non-viable.
-
Not sure if you've heard/read Jay Carlson's "The amazing 1$ microcontroller" article / post : https://jaycarlson.net/microcontrollers/
How unfortunate RP2040 did not make the list at the solid $1.00 price point, with >100,000 available to ship immediately from DigiKey
-
I was browsing ST's website last night and ALL the STM8's are now marked as NRND! Oddly i couldn't find any mention from ST that these parts are being discontinued, has anyone here heard anything?
I noticed a couple of weeks ago that the entire AF and AL lines had been marked NRND, but at that time the S and L lines had not been. But you're right, the entire STM8 line as has been now marked as NRND. :-- So much for their 10 year lifetime guarantee. Although maybe this means that they will continue to make them for 10 years from now.
An acquaintance of mine works for a company that uses a lot of STM8 in some of their product lines, and they have heard nothing.
I had a feeling something was up, though, what with the launch of the new STM32C0 line that they have been pushing marketing recently for as "a cost-effective alternative to 8-bit microcontrollers".
-
I was browsing ST's website last night and ALL the STM8's are now marked as NRND! Oddly i couldn't find any mention from ST that these parts are being discontinued, has anyone here heard anything?
I noticed a couple of weeks ago that the entire AF and AL lines had been marked NRND, but at that time the S and L lines had not been. But you're right, the entire STM8 line as has been now marked as NRND. :-- So much for their 10 year lifetime guarantee. Although maybe this means that they will continue to make them for 10 years from now.
An acquaintance of mine works for a company that uses a lot of STM8 in some of their product lines, and they have heard nothing.
I had a feeling something was up, though, what with the launch of the new STM32C0 line that they have been pushing marketing recently for as "a cost-effective alternative to 8-bit microcontrollers".
NRND has no effect on existing users, and if you have a 10 year supply agreement in place, that should not be affected either. Sometimes a vendor will try to negotiate their way out of long term commitments that its hard for them to keep, but they would need to provide reasonable compensation. NRND just means use of the family is a dead end.
-
The RP2040 lacks a clock, a flash, and an LDO (to live off 5V straight from i.e. USB), and plenty of peripherals (which can be circumvented by the presence of PIO, that being said) and has a high amount of power drawn.
Still an interesting MCU depending on the use-case though.
I agree it would have been interesting to put it in the comparison though.
-
I was browsing ST's website last night and ALL the STM8's are now marked as NRND! Oddly i couldn't find any mention from ST that these parts are being discontinued, has anyone here heard anything?
I noticed a couple of weeks ago that the entire AF and AL lines had been marked NRND, but at that time the S and L lines had not been. But you're right, the entire STM8 line as has been now marked as NRND. :-- So much for their 10 year lifetime guarantee. Although maybe this means that they will continue to make them for 10 years from now.
An acquaintance of mine works for a company that uses a lot of STM8 in some of their product lines, and they have heard nothing.
I had a feeling something was up, though, what with the launch of the new STM32C0 line that they have been pushing marketing recently for as "a cost-effective alternative to 8-bit microcontrollers".
Yes, price and availability of STM8 have worsened a lot, and there are now shiploads of pin-compatible alternates on offer, at lower prices.
The 8051 core is popular in Asia, and seems to have many vendors offering STM8 pinout variants, and many with better peripherals.
SiLabs have recently released their 5V wide Vcc 50MHz 8051's and smaller packages are coming in 2023.
-
The 8051 core is popular in Asia, and seems to have many vendors offering STM8 pinout variants, and many with better peripherals. SiLabs have recently released their 5V wide Vcc 50MHz 8051's and smaller packages are coming in 2023.
This looks interesting to me. I haven't messed with the 8051 for years. I will definitely check out these recent 8051-compatible chips. For my projects "full 5V I/O" is often required.
-
Not sure if you've heard/read Jay Carlson's "The amazing 1$ microcontroller" article / post : https://jaycarlson.net/microcontrollers/
How unfortunate RP2040 did not make the list at the solid $1.00 price point, with >100,000 available to ship immediately from DigiKey
The extra $1 for QSPI FLASH busts the budget, but then you are getting two cores :-)