In response to my last post, a few readers suggested looking at the Raspberry Pi Foundation’s RP2040 microcontroller for possible use in a future Floppy Emu hardware refresh. The RP2040 was announced in January 2021, first as part of the Raspberry Pi Pico development board, and later as a stand-alone chip. While Raspberry Pi’s other offerings are essentially full-fledged computers, the RP2040 is a traditional microcontroller that will compete directly with familiar products from Microchip, ST, Espressif, and NXP. So what does it offer that might set it apart from the competition? Is it worth a look? Here’s my take.

 
Strong Points

RP2040 is a 133 MHz dual-core ARM Cortex M0+ microcontroller, with 264 KB of RAM, and a unit price of $1 USD. Right off the bat, that looks appealing. I don’t know of any other microcontroller from a major vendor that offer a better ratio of hardware specs per dollar. 133 MHz is quite zippy, and 264 KB of RAM is substantially more than any of the alternative parts I’ve been considering. Dual core is just icing on the cake.

The hardware also includes two programmable I/O (PIO) blocks with interesting potential. These are hard to describe in a single paragraph, but they’re like high-speed specialized coprocessors that could replace much of the software-based bit-banging that’s often needed in microcontroller applications. They’re a good fit for high-speed bit twiddling, independent of the main cores. For the Floppy Emu, PIO blocks could probably be used to replace some of the specialized logic that’s currently handled by a CPLD programmable logic chip.

The documentation looks well-written. So far I’ve reviewed the chip datasheet, hardware design guide, the C/C++ SDK documentation, and the Getting Started Guide.

The RP2040 is available and shipping in large quantities right now, which is quite an accomplishment given the current shortages everywhere else in the industry. DigiKey has over 50000 in stock. You can also order the chips directly from Raspberry Pi.

 
Weak Points

There’s zero flash or non-volatile memory for program storage on the RP2040. All the application code and data must be stored in an external flash chip. Six dedicated pins are used to communicate with a separate QSPI flash, using execute-in-place (XIP) technology to run code directly from flash without needing to copy it to RAM first. A 16 KB XIP cache helps speed up this process. Relying entirely on external flash helps keep the RP2040 price down, and lets the user choose a flash chip whose storage size matches their needs, but it also has some serious drawbacks for my purposes.

The biggest worry is code execution speed. If most of the code fits into the 16 KB cache, then the code should run as fast as any other CM0+ microcontroller with similar specs. But for uncached code, and especially for application startup code when nothing is yet cached, I fear it will be slooooow, slower even than 8-bit AVRs with much lower system clock speeds. I used section 2.3 of this Atmel document to understand what XIP traffic looks like for a QSPI interface. Fetching a 32-bit value requires 20 SPI clocks, which is 80 system clocks using the RP2040’s default settings. A 32-bit value can hold two 16-bit Thumb instructions, so it looks like 40 system clocks per instruction, or 3.3 MIPS at 133 MHz. Slow.

For many time-critical routines, code can be pre-loaded into RAM with some extra effort, where it will run much faster. But for application startup code there’s really no way around this bottleneck. I’m not sure if this would be a serious problem, or if I’m worrying over nothing.

There’s no easy place to store settings information, like the EEPROM on an AVR. Presumably settings would need to be stored in the same external flash as the program code. This would require copying some section of code to RAM and executing it, which would deactivate the XIP interface and use standard SPI flash commands to update a few bytes, before re-enabling XIP and resuming the program.

The RP2040 bootloader could be considered both a strong point and a weak one. There’s a built-in USB bootloader in mask ROM, which is activated if the external flash is missing or deactivated. To the computer it appears as a USB mass storage device, so you can update the firmware with a simple drag-and-drop. This is great if your product already has a USB device (USB-B) connector on it, but the Floppy Emu doesn’t and doesn’t need one. I could roll my own pseudo-bootloader as part of the main application code, to load firmware updates from the SD card, but it wouldn’t be in protected memory like a real bootloader. If something went wrong during the update, it might corrupt the pseudo-bootloader and effectively brick the device.

While I admit I haven’t tried it, the C/C++ development toolchain doesn’t look great. Ideally I’d hope to see an IDE like Atmel Studio or STM32 Cube, with hardware-specific tools to help configure the peripherals, GUI settings for all the build options, an integrated simulator and debugger, and so on. But the reality is more like a pile of libraries, header files, and build scripts. Changing any kind of build settings relies heavily on editing CMake files and adding new defines whose existence you may not have known about. Sure you can use the VSCode IDE, but it doesn’t seem to do much more than function as a text editor, and you’ll still be tearing your hair out struggling with CMake. The build environment is also clearly geared towards Linux, and while setup is possible under Windows, it appears to be cumbersome.

My last worry is over the RP2040 development community, or really the lack of a community. If you’re developing for an AVR, or Atmel SAM, or STM32, you’ll find thousands of helpful resources on the web with example code, discussion forums, and sample projects. There’s very little of this for RP2040, and most of what does exist is geared towards Micro Python and Circuit Python, rather than bare metal C/C++ development. The only discussion forum I’ve found is a small subsection of the main Rasperry Pi forums. This doesn’t make it impossible to develop – the documentation seems thorough and there is some help on the web. But it’s a far cry from working “in the herd” and developing for a more popular microcontroller family.

 
Conclusions

So is the RP2040 the future of the Floppy Emu? It’s hard to say, but I think probably not. It may help to compare it against some other possibilities, like the Atmel SAMD21 (48 MHz CM0+ with 32 KB RAM) or SAMD51 (120 MHz CM4 with 128 KB RAM), which cost around $4 each in large quantities. Compare these to an RP2040 plus an external flash chip, with a combined cost of about $2. The RP2040 solution is half the price, but both alternatives are cheap enough, and I would choose whatever solution will make development easiest.

The extra RAM of the RP2040 is welcome, but I’m unsure what I’d do with it. 32 KB is more than enough to buffer a disk track plus other application data, and unless I had 1MB or more to buffer a whole disk, additional RAM might not be immediately useful.

133 MHz is greater than 48 MHz, so maybe the RP2040 is much faster than the SAMD21? Or maybe not, given the overhead of XIP code execution?

All these differences in favor of the RP2040 look interesting, but if they aren’t critical for my specific application, then are they worth the trade-offs of the build environment, development community, and concerns about external flash?

For the specific case of the Floppy Emu, I think the best argument in favor of the RP2040 is the PIO blocks. If those could replace all of the logic that’s currently handled by a CPLD programmable logic chip, then I could eliminate the CPLD entirely, and greatly simplify the whole design. But if the PIO blocks can only replace some of the logic, then I still need a CPLD or something similar, and the advantage of the RP2040 is much less. But that’s a difficult question to answer by just reading the docs, and I’d need to really dig in and try building it.

It’s been a while since I last shared any business updates for BMOW. The past few years have been an exciting trip, as my personal technology blog has grown into a side hustle and then into a bona fide business. Initially BMOW was something I did in my spare time away from my real job (video game development), then it was something I did while I was between jobs, and now for the past few years it has been my real job. The experience has been great, but now the global chip shortage has scrambled everything, and the future outlook is growing scary.

 
The Good

First the good news. The gradual transformation from blog to store began in 2014, when a few blog readers started asking to buy the Macintosh floppy disk emulator that I’d been writing about. I sold about $18000 of hardware that first year, doing all the assembly and fulfillment by hand. It didn’t leave a huge profit after subtracting all the cost of parts, tools, and other business expenses, but it was a thrill to be making something that people wanted.

In the time since then, sales have grown consistently every year. I’ve moved the assembly work to dedicated manufacturing partners, added many new products to the BMOW line-up, and even hired a part-time employee to help with order fulfillment and customer support. In 2021 I sold several thousand Floppy Emus, plus lots of other products too, which was amazing. Gross revenue was into the hundreds of thousands. My net income after all expenses is less than I could earn as a software developer here in Silicon Valley, but it’s still a respectable number, and being my own boss is fantastic. I couldn’t imagine going back to a regular full-time job now. Sure, I’m always complaining about the challenges of international shipping or payment processing disasters or something else, but that comes with the territory of running my own business.

 
The Bad

If there’s anything bad here, it’s the overall fragility of the business. A great business would have revenue from many diverse products, with reliable sources of supply, and a large and growing market. I have none of that. The market is owners of obsolete computers from 25+ years ago. There simply aren’t many of those, and the number is shrinking every year as some computers break and can’t be repaired. How many working Apple II and classic Macintosh systems even exist today? Ten thousand? Ten million? I really don’t know. I keep thinking that I must have saturated the market already, but it hasn’t happened yet.

Product diversity is another weak point. BMOW sells eighteen different products, but 80 percent of revenue comes from the Floppy Emu Disk Emulator. Everything else is basically just a distraction. If anything threatens the supply or sales of Floppy Emus, then the business is in big trouble.

 
The Scary

Friends, the global chip shortage is very bad. For over a year columnists keep predicting it will get better soon, but it only gets worse and worse. This won’t continue forever, but how much longer will we have to endure this crunch? Six months? A year? Two, or three? And what will the landscape look like then? Will semiconductor makers take this opportunity to discontinue some of their oldest and least-profitable chips, the chips that are needed for vintage computer hardware?

The Floppy Emu uses two primary chips: a microcontroller and a programmable logic device. The mcu is an Atmel ATMEGA1284 and the logic device is a Xilinx XC9572XL. Both are relatively old technology, like 15+ years old. Both have seen their prices double or triple in the past couple of years. And both now have very limited or zero stock everywhere, with little hope of getting more stock anytime soon. Maybe I can get more in six months, or a year? Maybe never?

The last time I did a Floppy Emu manufacturing run, it was very difficult to find parts, particularly the ATMEGA1284. I almost gave up. My manufacturing partner made a lot of calls, and eventually found a surplus parts broker who could fill the order for a nosebleed price. As of today, I have enough finished Floppy Emus to last until roughly September at my normal rate of sales. I don’t know what happens after that. If I can’t find the required parts, or redesign the board around new parts, then I’m basically out of business.

 
Strategizing

What would you do in this situation? I can’t decide, and I’m spinning my wheels trying to decide what to do, while the clock is ticking and time is running out.

One option is to redesign the Floppy Emu hardware around new parts with better availability. The existing parts are pretty old anyway, so a refresh would make sense. But what new parts should I choose? It’s not just the ATMEGA1284 that has supply problems – it’s virtually all microcontrollers from Microchip, ST, TI, everybody. And the options for programmable logic parts are even worse. There’s very scarce availability of any programmable logic parts, and the few that are available are actually less capable than the old Xilinx part, or cost five times as much. Sure, you can sometimes find parts with a few hundred at one supplier and 1000 at another, but it’s usually one specific oddball package or variant while the rest of the family is out of stock. That’s a fluke, not a reliable supply. To feel comfortable betting the farm on a new chip, I’d want to see all the members of its family with deep stock in the many thousands, at multiple suppliers.

If I redesign the Floppy Emu hardware, should I redesign around the best available parts options today, or around a blue-sky vision of the best-suited parts for the task regardless of current availability? A redesign will be a major time-consuming effort, and I can’t afford to get it wrong. It’s a gamble. If I redesign around the best available parts today, that greatly limits my choices. I could be locked into sub-optimal parts for a long time to come. That might make it much harder to add new features, or might create new supply problems in the future, or increase my costs. If I redesign around the parts I’d like to use in a perfect world, then I could have to wait a very long time before they become available again. The redesigned hardware might never see the light of day except for a few prototype units.

Given how much time any redesign would require, and the uncertain results, there’s another option I’m seriously considering: do nothing. Place some back-orders now for the ATMEGA1284 and XC9572XL, and then forget about it. Use the coming months to work on Yellowstone features or develop some cool new product, instead of redesigning the Floppy Emu. Hope that the parts become available before I need them, and if they don’t, it will be lean times at BMOW. I would still probably want to revisit the Floppy Emu hardware design in another year or two, to take advantage of the capabilities of newer parts, but I would do it after the chip shortage is over and there’s a clearer picture of what parts I can safely bet on.