There are a lot of things I don't miss! x86 segmented architecture, for example. Even modern embedded programming on an ARM Cortex-M feels luxurious compared to not that long ago.
If you enjoyed this article, you might also enjoy The Man Who Mistook His Wife for a Hat and Other Clinical Tales by Oliver Sacks. It’s a book of essays about brain function and disorders, but each begins with an individual who exhibits particularly unusual symptoms. They don’t have tidy resolutions like this article, but the book is well-written and engaging—-as are the rest of Dr. Sack’s writings.
It was also for a low-cost audio application, but it wasn't a toy. This was back in 2001 or so. The MCUs in this article all only have ~1KB ROM, which wouldn't have been enough for our audio samples. We needed >256KB. The "4-bitness" was just incidentally what Winbond offered with a large ROM at the time. However, the SunPlus that we later used in the toy also offered a large ROM with an 8-bit CPU for a similar cost. So, while I can't authoritatively say that 4-bit is dead, it does seem like there are a lot of alternatives in similar price ranges now.
That sounds very similar to my experience with toy development. For a toy that played a bunch of pre-recorded sounds, we used a 4-bit Winbond MCU (their MCU division is now Nuvoton) that had a tiny bit of RAM and a ton of mask ROM. Firmware development was done in assembly and targeted a huge (physically large) emulator for test/debug. When we were satisfied with the firmware, we'd send it off to our CM, who would then order the parts with our FW in ROM. They'd get back bare die parts, which were wire bonded to the PCB and then epoxied over (that miserable "glop top" packaging, which is the bane of many teardowns). Development was a bit painful, but high volume production was extremely cheap.
Edit: Oops. I conflated projects. The toy project actually used a SunPlus MCU, not a Winbond MCU. It was an 8-bit RISC CPU running at 5MHz with 128 bytes RAM and 256KB mask ROM. The ROM held both the program and audio samples. I don't recall what encoding was used for the audio.
This is a friend’s project. It’s a public domain, header-only vsnprintf that supports floats. It has zero dependencies, zero libc calls, no allocations, < 100B stack, < 5K on a Cortex-M with optimizations on. It’s meant for small systems where you need a full-featured printf without a huge footprint.
Ah, you're correct. I did think it was odd that they were able to make the debugger do anything in RDP2, but I misread it. That attack was indeed performed in RDP1.
The tl;dr is that researchers found 3 weaknesses in an STM32's flash protection scheme. For those not familiar, these chips offer three protection levels:
RDP 0 - unlocked, all flash/ram is accessible via the debug interface
RDP 1 - flash locked, you can connect a debugger and read out RAM/peripherals, but not flash. This is intended to prevent you from dumping the flash firmware image, but allow you to perform some diagnostics via the debugger.
RDP 2 - everything's locked down. The debugger cannot access RAM, Flash, or other peripherals.
The 3 exploits are roughly:
* In RDP 1, you can't read flash directly, but you can read anything that the firmware puts in RAM. The researchers were able to extract an entire flash firmware image by watching the results of a CRC self-check that the firmware performs upon boot. By resetting the microcontroller and very precisely controlling the amount of time it's allowed to run before halting it and dumping RAM, the researchers were able to back out the firmware image by observing the CRC progression in RAM.
* The researchers noted that the bit patterns used to represent the different RDP levels in flash were sub-optimal in that only a single bit needs to be flipped to downgrade from RDP 2 to RDP 1. By deencapsulating an RDP 2 microcontroller and exposing it to UV using a carefully-constructed mask, they were able to perform such a downgrade.
* The researchers crafted their own SWD debugger interface that performed less initialization than ST's stock debugger and thus didn't immediately lock down a microcontroller in RDP 1 mode when the debugger was attached. With this modified debugger, they discovered that they could issue a flash read that would lock down the micro as expected, but would also occasionally result in the protected flash data actually appearing in the read buffer (likely due to some internal race condition bug in the microcontroller's hardware). Thus it's possible to automate a brute force extraction of the entire flash in RDP 1 mode.
Edit: Changed RDP 2 to RDP 1 in description of 3rd exploit.
Hi HN! You found my site again. Here's the previous discussion from almost exactly year ago (warning, this links to the profane version): https://news.ycombinator.com/item?id=13437182
According to the site, "Quickly and easily connect a receipt printer, kitchen printer, cash drawer, and barcode scanner. Get your hardware up and running in minutes."
So, I'd assume you print the receipt to a receipt printer that you connect to the stand.