The Microcontroller That Just Won’t Die(eejournal.com)
eejournal.com
The Microcontroller That Just Won’t Die
https://www.eejournal.com/article/the-microcontroller-that-just-wont-die/
9 comments
It's astonishing how many places the 8051 shows up. Got an in-car Tire Pressure Monitoring System (TPMS)? It's almost certainly an 8051. Getting accurate shipment numbers (without paying for the reports) is hard, but there's clearly still billions of 8051 variants shipping every year.
> Getting accurate shipment numbers (without paying for the reports) is hard
And even those reports are likely to involve a lot of guesswork. There are probably hundreds of different 8051-class IP cores, and a nontrivial number of them are royalty-free -- even the designers of those cores may not know how many chips they've been used in.
Many 8051 cores aren't even fully acknowledged by the IC manufacturer -- it's not uncommon for one to be described as vaguely as an "8-bit RISC microprocessor", especially when it's being used in an application where the firmware is embedded in the part (like a USB hub controller or a battery charge controller).
And even those reports are likely to involve a lot of guesswork. There are probably hundreds of different 8051-class IP cores, and a nontrivial number of them are royalty-free -- even the designers of those cores may not know how many chips they've been used in.
Many 8051 cores aren't even fully acknowledged by the IC manufacturer -- it's not uncommon for one to be described as vaguely as an "8-bit RISC microprocessor", especially when it's being used in an application where the firmware is embedded in the part (like a USB hub controller or a battery charge controller).
Completely accurate, particularly around the "don't tell them it's an 8051" clones.
I have a friend that used to reverse engineers all sorts of embedded black box products and he's said "when there's no markings or other clues, assume it's some kind of 8051 and see where you get". That might not be as true these days with ubiquitous ARMs and sub 10 cent Chinese/Taiwanese microcontrollers (many apparently PIC12 knockoffs[1]), but it apparently worked for a long time.
[1] https://cpldcpu.wordpress.com/2019/08/12/the-terrible-3-cent...
I have a friend that used to reverse engineers all sorts of embedded black box products and he's said "when there's no markings or other clues, assume it's some kind of 8051 and see where you get". That might not be as true these days with ubiquitous ARMs and sub 10 cent Chinese/Taiwanese microcontrollers (many apparently PIC12 knockoffs[1]), but it apparently worked for a long time.
[1] https://cpldcpu.wordpress.com/2019/08/12/the-terrible-3-cent...
Note current retail (qty 1+) prices in China are <1RMB/chip = $0.10USD which places it well below most newer rivals if you want to mass-manufacture a cheap product with basic MCU logic.
I guess this is an advertorial for the MUG51, but $0.73 is vastly more expensive than $0.10.
Haha, I had a feeling from the title it would be about the 8051. I've only recently learned about it. I ended up with a bunch of TTL / LVDS / eDP display panel driver boards on hand. They're based around a family of Realtek chips which are hugely powerful for having in some cases a single digit dollar cost - the silicon has a whole bunch of peripherals like analogue video decoders, HDMI/VGA/DisplayPort decoders, colour processing, an OSD generator and signal muxer, DDC/CI interface, IrDA demodulator, PWM / DAC for audio, and many many more things; all with parameters configurable by an embedded 8051-compatible processor (by the same principle as memory mapped peripheral). As someone with next to no serious experience in embedded software, trying to write software to target these devices has been quite the departure and an eye opener in many ways.
The development tools just feel so antiquated. The Keil compiler mentioned in the article has a per-seat license cost in the thousands and runs on Windows, and it feels like it has not received any serious upgrades since the mid-2000s. It runs fine on Wine (with a free trial license, of course), but has basically unusable UX on a hidpi screen. Of course I can pretty much get away with coding in vscode and writing a Makefile which calls `wine ~/.wine/drive_c/Keil/BIN/C52.exe` but it's not ideal, plus, my trial license will of course expire, and this is a hobby project.
I tried switching to using SDCC. Preface, my honest opinion is that the small handful of people who maintain this are doing a wonderful job and have been for years - it's a thankless task for a small audience. But for serious features that a modern day user might expect, like code banking, the implementation is inflexible, supports half of the implementation methods that Keil does, and generates larger code. And of course, there are currently very few people capable of making contributions to improve the situation. The documentation is extensive but split across PDF files for the compiler, TXT files for the linker, unstyled HTML files for the simulator, and various README and errata "NOTES" files for other components.
Meanwhile the only copies of the original Intel documentation for the 8051 I could find were scanned images of a printed book. A lot of random entry level tutorials for beginners are dotted around the net, on websites like http://8052mcu.com/ or in Youtube video lectures uploaded by universities based in non-English speaking countries; but high quality written reference guides seem to be difficult to find. Of course, maybe it's not as bad as that, but just was not easy for me to grok; I realised in hindsight I have the assumptions of von Neumann architecture more or less internalised, so it took a while to get my head around the concept of having three separate address spaces (one for code, another for internal RAM, another for external RAM).
I would not be surprised if this were the case for an equally old but now-niche chip, like the Z80 and its derivatives. But given the neighbouring comments estimating just how widespread this MCU is (billions of units per year?!) it does seem kinda surprising that modern open source embedded development tools of the kind available for platforms like the RP2040, STM32, ESP8266, etc, just haven't reached the 8051 platform. (edit to add: I don't think it's necessarily bad if development tools are simply "old", fwiw, and I do think software can be finished. But in this case there is something of a gulf between the open source solution and the paid solution, and progress to close this has only slowed, not accelerated.)
My only guess as to why (as a layperson) is that the Harvard architecture plus 8-bit stack address space makes it difficult to target with modern compiler tools or something. Of course the modern derivatives being heavily burdened by IP rights also can't help; I suppose the only people who have access to datasheets detailed enough to implement simulators / advanced compiler features, have a day job which affords them access to the "good enough for enterprise" Keil solution : )
The development tools just feel so antiquated. The Keil compiler mentioned in the article has a per-seat license cost in the thousands and runs on Windows, and it feels like it has not received any serious upgrades since the mid-2000s. It runs fine on Wine (with a free trial license, of course), but has basically unusable UX on a hidpi screen. Of course I can pretty much get away with coding in vscode and writing a Makefile which calls `wine ~/.wine/drive_c/Keil/BIN/C52.exe` but it's not ideal, plus, my trial license will of course expire, and this is a hobby project.
I tried switching to using SDCC. Preface, my honest opinion is that the small handful of people who maintain this are doing a wonderful job and have been for years - it's a thankless task for a small audience. But for serious features that a modern day user might expect, like code banking, the implementation is inflexible, supports half of the implementation methods that Keil does, and generates larger code. And of course, there are currently very few people capable of making contributions to improve the situation. The documentation is extensive but split across PDF files for the compiler, TXT files for the linker, unstyled HTML files for the simulator, and various README and errata "NOTES" files for other components.
Meanwhile the only copies of the original Intel documentation for the 8051 I could find were scanned images of a printed book. A lot of random entry level tutorials for beginners are dotted around the net, on websites like http://8052mcu.com/ or in Youtube video lectures uploaded by universities based in non-English speaking countries; but high quality written reference guides seem to be difficult to find. Of course, maybe it's not as bad as that, but just was not easy for me to grok; I realised in hindsight I have the assumptions of von Neumann architecture more or less internalised, so it took a while to get my head around the concept of having three separate address spaces (one for code, another for internal RAM, another for external RAM).
I would not be surprised if this were the case for an equally old but now-niche chip, like the Z80 and its derivatives. But given the neighbouring comments estimating just how widespread this MCU is (billions of units per year?!) it does seem kinda surprising that modern open source embedded development tools of the kind available for platforms like the RP2040, STM32, ESP8266, etc, just haven't reached the 8051 platform. (edit to add: I don't think it's necessarily bad if development tools are simply "old", fwiw, and I do think software can be finished. But in this case there is something of a gulf between the open source solution and the paid solution, and progress to close this has only slowed, not accelerated.)
My only guess as to why (as a layperson) is that the Harvard architecture plus 8-bit stack address space makes it difficult to target with modern compiler tools or something. Of course the modern derivatives being heavily burdened by IP rights also can't help; I suppose the only people who have access to datasheets detailed enough to implement simulators / advanced compiler features, have a day job which affords them access to the "good enough for enterprise" Keil solution : )
You say it might be the same for the Z80? I think, happily, the situation there is a lot more open and well-documented.
There are specific sites such as http://z80.info which are good resources to describe the chip. The Z80 was also the main processor of a lot of computers, in the UK the Sinclair Spectrum sold in the millions, and there are an awful lot of coders who started their careers, or childhoods, playing with them. People of my age would be reasonably familiar with assembly and the things it can do.
The fact that the Z80 was also used in consoles also provides another avenue for information. There are a lot of emulators out there which have implementations if not necessarily good documentation.
(On a similar note there's a lot of legacy code out there, as the Z80 was one of the targets for CP/M, which is itself source-available these days.)
Compiling CP/M, Pascal, C, FORTH, and running BASIC on a z80 are all trivial - with the right supporting hardware/circuitry for I/O.
There are specific sites such as http://z80.info which are good resources to describe the chip. The Z80 was also the main processor of a lot of computers, in the UK the Sinclair Spectrum sold in the millions, and there are an awful lot of coders who started their careers, or childhoods, playing with them. People of my age would be reasonably familiar with assembly and the things it can do.
The fact that the Z80 was also used in consoles also provides another avenue for information. There are a lot of emulators out there which have implementations if not necessarily good documentation.
(On a similar note there's a lot of legacy code out there, as the Z80 was one of the targets for CP/M, which is itself source-available these days.)
Compiling CP/M, Pascal, C, FORTH, and running BASIC on a z80 are all trivial - with the right supporting hardware/circuitry for I/O.
>>> new 8048 variants and the microcontroller family’s weaknesses
Like, for example, only one external interrupt and one timer, which was 8-bit.
I did some reverse engineering on an 80s Porsche engine management computer[1] that used the 8048. The engineers had to get really clever to work with these 2 issues. They used the reset pin as a second pseudo ext interrupt, which works ok but has a few side effects you have to deal with.
The lack of a 16 bit timer was single-handedly responsible for adding massive complexity all over the code. Basically the loops had to be capable of scaling themselves for engine speeds below a certain threshold because otherwise the timer would overflow!
You have to wonder if it was worth what they saved vs just using an 8051, especially considering that this car had 2 engine management computers, and the main one used an 8051!
[1] https://jhnbyrn.github.io/951-KLR-PAGES/
Like, for example, only one external interrupt and one timer, which was 8-bit.
I did some reverse engineering on an 80s Porsche engine management computer[1] that used the 8048. The engineers had to get really clever to work with these 2 issues. They used the reset pin as a second pseudo ext interrupt, which works ok but has a few side effects you have to deal with.
The lack of a 16 bit timer was single-handedly responsible for adding massive complexity all over the code. Basically the loops had to be capable of scaling themselves for engine speeds below a certain threshold because otherwise the timer would overflow!
You have to wonder if it was worth what they saved vs just using an 8051, especially considering that this car had 2 engine management computers, and the main one used an 8051!
[1] https://jhnbyrn.github.io/951-KLR-PAGES/
You have to wonder if it was worth what they saved vs just using an 8051
There are all sorts of direct and indirect costs in something like this. Did they perhaps reuse an older design? I've run into all sorts of weird/obsolescent bits in manufacturing environments (like industrial controllers) where the answer was "yeah...newer tech would be nice, but we already had this design on the shelf and it fit the minimum need and the NRE costs were covered and it's been debugged within an inch of it's life and the regulatory hurdles have been cleared and the manufacturing/supply chain kinks have long since been worked out and our customer support people are up to speed, soooo...".
Cool RE job @injb, BTW.
There are all sorts of direct and indirect costs in something like this. Did they perhaps reuse an older design? I've run into all sorts of weird/obsolescent bits in manufacturing environments (like industrial controllers) where the answer was "yeah...newer tech would be nice, but we already had this design on the shelf and it fit the minimum need and the NRE costs were covered and it's been debugged within an inch of it's life and the regulatory hurdles have been cleared and the manufacturing/supply chain kinks have long since been worked out and our customer support people are up to speed, soooo...".
Cool RE job @injb, BTW.