The Microcontroller That Just Won’t Die
Haha, I had a feeling from the title it would be about the 8051. I&#x27;ve only recently learned about it. I ended up with a bunch of TTL &#x2F; LVDS &#x2F; eDP display panel driver boards on hand. They&#x27;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&#x2F;VGA&#x2F;DisplayPort decoders, colour processing, an OSD generator and signal muxer, DDC&#x2F;CI interface, IrDA demodulator, PWM &#x2F; 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.<p>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 ~&#x2F;.wine&#x2F;drive_c&#x2F;Keil&#x2F;BIN&#x2F;C52.exe` but it&#x27;s not ideal, plus, my trial license will of course expire, and this is a hobby project.<p>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&#x27;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 &quot;NOTES&quot; files for other components.<p>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 <a href="http:&#x2F;&#x2F;8052mcu.com&#x2F;" rel="nofollow noreferrer">http:&#x2F;&#x2F;8052mcu.com&#x2F;</a> 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&#x27;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).<p>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&#x27;t reached the 8051 platform. (edit to add: I don&#x27;t think it&#x27;s necessarily bad if development tools are simply &quot;old&quot;, 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.)<p>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&#x27;t help; I suppose the only people who have access to datasheets detailed enough to implement simulators &#x2F; advanced compiler features, have a day job which affords them access to the &quot;good enough for enterprise&quot; Keil solution : )