> So, which pins could be combined with SDIO's three? After much thinking, the solution is obvious. RAM's nCS can be the SD card's CLK. RAM's CLK can be the SD card's CMD. RAM's MOSI can be the SD card's DAT. Try and figure out all the possible interactions with each device and what that would look like to the other, to convince yourself that it will work safely.
This is truly a brilliant hack, well worth publishing at Hacker News.
There was an old joke. University math class. Professor writes a huge formula on the board. Says, "and from this, it is obvious that," and writes another very different large formula on the board. He stands for a second, says "hm...", and walks out of the lecture hall. He returns 30 minutes later, throws a stack of papers freshly-covered in writing unto the desk, mutters "yeah, that indeed was obvious", and continues the lecture.
I'm always a bit saddened to see that a separate chip is the go-to method to interface with USB. Unfortunately USB is an incredibly-complex protocol that it seems anything beyond a basic V-USB running USB 1.1 at low-speed is generally not doable without specialized hardware and a significant software stack. Meanwhile a protocol like SPI is ridiculously simple...the minimum hardware needed is a shift register that can be clocked fast enough. I miss how desktop and labtops used to have an exposed serial and parallel port, which could communicate at this low level. I often wonder if instead of USB existing that we instead stuck with UART, I2C, or SPI multidrop (using a small set of standard clock rates) for simple peripherals (maybe over a single connector like the 4-pin JST SH cable for Stemma QT, Qwiic and Grove) over a short distance, and then jumped to IEEE 802.3 Ethernet links for data-heavy peripherals like monitors and external drives. Then instead of having to have separate support for USB and Ethernet, you just would support Ethernet links.
> Meanwhile a protocol like SPI is ridiculously simple
Yes, it is. It was intended to require as little silicon as possible to minimize the cost to the transistor budget. SPI doesn't contemplate power supply, hot-plug, discovery, bit errors, or any other of a host of affordances you get with USB.
I think there is some value for software developers to understanding SPI and the idioms used by hardware designers with SPI. Typically, SPI is used to fill registers of peripherals: the communication is not the sort of high level, asynchronous stuff you typically see with USB or Ethernet and all the layers of abstraction built upon them. Although there is no universal standard for SPI frames, they do follow idiomatic patterns, and this has proven sufficient for an uncountably vast number of applications.
I feel like you could support hot-plug, discovery, and bit errors with a protocol orders of magnitude simpler than USB, something you could bitbang on an ATTiny45. (And without Neywiny's list: 'bit ordering, half-duplex, the 4 modes, chip select to first clock setup times, bits per word, "strobing" nCS between words.' Those incompatibilities are mostly just people taking shortcuts.) And, unless you're talking about USB-C PD, which isn't involved here, the power-supply question isn't really related to the software complexity; it's just a question of making the power and ground traces on the USB-A plug (and the corresponding parts of other connectors) longer than the data traces so they make contact first.
You couldn't make it quite as simple as (a given flavor of) SPI, but something close to I²C should be feasible.
Very true. And dealing with bit ordering, half-duplex, the 4 modes, chip select to first clock setup times, bits per word, "strobing" nCS between words, the list goes on. But when you see "USB 1.1 device" you know a large majority of what it can support and what it'll do.
The article goes through a long list of 8 pin chips but ignores the very popular $0.10 CH32V003, which has 2k RAM and 16k Flash running at 48 MHz and 1 CPI -- or the new CH570 (I have a dev board on the way) which is also $0.10 in SOIC8 but now runs at 100 MHz with 16k RAM and 256k flash and has USB and a 2.4 GHz packet radio.
oops .. my brain of course knows but my fingers didn't in this instance. Fixed.
I think it's compatible with the old nRF24 chips -- I'll test when mine arrives in a week or so. The CH572 version has BLE5 ... I think the same hardware but including a software stack.
If there has to be a chip to facilitate coms, I feel like you could go on a similar hunt for 8 pin microcontrollers that could serve that function and maybe also provide some extra functionality. It would be interesting if it could connect to a PC though a DDC connection.
So you want to replace a USB PHY with a serial to Ethernet converter and an Ethernet PHY.
The reality is that the simple protocols like SPI and I2C just are not good enough. They aren't fast, the single-ended signal scheme makes them very sensitive to noise, and there is no error correction. These protocols make sense and work extremely well for their intended purpose: connecting ICs on a PCB. If you expose an unterminated port to the outside world, all bets are off.
These protocols and variations thereof are still in heavy use in modern PCs. But they're internal busses, as the protocols intend.
I haven't looked closely at the USB spec, but I imagine the main problem with bit-banging is simply the speed required. You have to have dedicated hardware because no microcontroller is fast enough to toggle the pins while also running the software stack to decode the protocol and manage error correction.
You can run into this exact problem bit-banging I2C. With a 20MHz CPU, the maximum clock speed you can get is about 250KHz. Just a bit more than half the typical maximum rate of 400KHz. You can absolutely forget about the 1MHz version.
PHYs exist for one very good reason: it is vastly cheaper to offload comms protocols to hardware. Without that, you have to over-spec your CPU by quite a lot to get enough resources to manually manage communication. This is why every modern microcontroller contains hardware for I2C, SPI, serial, etc.
In summary, the simple serial protocols like SPI and I2C and UART are just absolutely terrible choices for external peripherals. They can't operate at reasonable speeds, they can't tolerate long cables, they can't tolerate noise. The nature and design of these protocols (excepting RS232 which is not UART) means that they cannot be used this way. There's no change to the spec you could make to support this without reinventing USB.
USB is also tough to bitbang also it has pretty strict timing requirements. Compared to something like i2c where the clock only advances when the pin is explicitly toggled.
You may have intended to say SPI. I²C does support "clock stretching" to delay until ready, but that's only in one particular case; otherwise the I²C clock advances all the time at whatever your baud rate is, not only when a pin is explicitly toggled.
i mean... someone did try this with i2c. a couple of dead computer companies shipped a bus that i forget the name of, based on this concept. its descendant is the vga hdmi control channel spec (which was implemented as a de facto separate standard but is very similar)
ACCESS.bus by Philips (who developed I²C) and DEC, and the DEC variant SERIAL.bus (with different voltage levels) used by their keyboards and mice for a little while.
USB is something that is possible to understand, and apparently bit-bang at at least low speed 1.5Mbps. Probably full speed 12Mbps as well on a modern MCU. I don't understand it, but one can.
In that sense it's like SPI, or perhaps more like CAN or SD: when you don't understand it, you reach for someone else to have done it for you, but you can choose to understand it and once you understand it you can implement it.
If you're the slave you have tight timing requirements but you only have to respond with certain fixed bit patterns to certain other bit patterns. If you're the master, you can do more things concurrently because the slave won't notice a little jitter in how often you poll it, but you have the problem of dealing with a wider variety of slaves that can be connected.
I've dabbled in microcontrollers and enjoy how the limitations force me to find creative solutions, but this is truly next level. I'm not great with a soldering iron but I'm seriously considering assembling one of these.
You can use a chip clip, but presumably you rejected that idea because your objective is for this to be replicable by the kind of people who don't know what a chip clip is.
I'd be very surprised if there isn't a filesystem driver for SPI flash. Linux obviously can speak SPI and SPI flash is extremely common in a lot of applications.
It looks like a passive mechanical adapter. I'd argue that a SOIC-8 programming clip thing would be better. This looks like you need to write a decent amount of code for a computer to talk to it as easily as a FAT-16 SD card.
This pleasantly reminds me of the little 6502 or 1802 Altoids-tin computers you can buy and assemble, but arguably more "useful" (though I get a lot of use out of a 6502 ;-).
Was there no native ARM linux you could have used? As I recall, you have used this emulated MIPs technique in many of your published projects, so it's good to prove that the hardware is working?
Or why not just go full native....grab some MIPS-core IP and make your own with an FPGA?
The main hang-up is that ARM uses PC as a general register a lot and in ways that make translating ARM instrs rather messy.
ADD R0, SP, PC, ROR SP
is entirely valid, even if nonsensical, instruction. But you must translate all valid inputs, else you risk breaking things. That may be a contrived example, but here is a common one: if one has a jumptable of relative offsets somewhere, pointed to by R10, even this is valid:
Interesting, I hadn't thought about this. Is the issue that the JIT output is likely to be a different number of bytes away? tbb/tbh seems like a more common version of that problem, TBH.
As I understand it, this kind of thing was a big problem for ARM in the mid-90s when they finally wrote the ARM ARM and outlawed things like ldmia r2!, {r0-r4}.
Different number of bytes out than in is not an issue. Efficiently translating such constructs in the general case is hard. Imagine what it would look like.
ENIG is gold coated not solid gold so it'll wear off and the metals under it will likely corrode. I think the majority of my USB connectors I eventually see wear marks on them.
> So, which pins could be combined with SDIO's three? After much thinking, the solution is obvious. RAM's nCS can be the SD card's CLK. RAM's CLK can be the SD card's CMD. RAM's MOSI can be the SD card's DAT. Try and figure out all the possible interactions with each device and what that would look like to the other, to convince yourself that it will work safely.
This is truly a brilliant hack, well worth publishing at Hacker News.
And worth a shirt "After much thinking, the solution is obvious."
Write down the problem. Think real hard. Write down the solution.
(The Feynman method—described by someone who observed him, though, not the man himself).
There was an old joke. University math class. Professor writes a huge formula on the board. Says, "and from this, it is obvious that," and writes another very different large formula on the board. He stands for a second, says "hm...", and walks out of the lecture hall. He returns 30 minutes later, throws a stack of papers freshly-covered in writing unto the desk, mutters "yeah, that indeed was obvious", and continues the lecture.
I'm always a bit saddened to see that a separate chip is the go-to method to interface with USB. Unfortunately USB is an incredibly-complex protocol that it seems anything beyond a basic V-USB running USB 1.1 at low-speed is generally not doable without specialized hardware and a significant software stack. Meanwhile a protocol like SPI is ridiculously simple...the minimum hardware needed is a shift register that can be clocked fast enough. I miss how desktop and labtops used to have an exposed serial and parallel port, which could communicate at this low level. I often wonder if instead of USB existing that we instead stuck with UART, I2C, or SPI multidrop (using a small set of standard clock rates) for simple peripherals (maybe over a single connector like the 4-pin JST SH cable for Stemma QT, Qwiic and Grove) over a short distance, and then jumped to IEEE 802.3 Ethernet links for data-heavy peripherals like monitors and external drives. Then instead of having to have separate support for USB and Ethernet, you just would support Ethernet links.
> Meanwhile a protocol like SPI is ridiculously simple
Yes, it is. It was intended to require as little silicon as possible to minimize the cost to the transistor budget. SPI doesn't contemplate power supply, hot-plug, discovery, bit errors, or any other of a host of affordances you get with USB.
I think there is some value for software developers to understanding SPI and the idioms used by hardware designers with SPI. Typically, SPI is used to fill registers of peripherals: the communication is not the sort of high level, asynchronous stuff you typically see with USB or Ethernet and all the layers of abstraction built upon them. Although there is no universal standard for SPI frames, they do follow idiomatic patterns, and this has proven sufficient for an uncountably vast number of applications.
I feel like you could support hot-plug, discovery, and bit errors with a protocol orders of magnitude simpler than USB, something you could bitbang on an ATTiny45. (And without Neywiny's list: 'bit ordering, half-duplex, the 4 modes, chip select to first clock setup times, bits per word, "strobing" nCS between words.' Those incompatibilities are mostly just people taking shortcuts.) And, unless you're talking about USB-C PD, which isn't involved here, the power-supply question isn't really related to the software complexity; it's just a question of making the power and ground traces on the USB-A plug (and the corresponding parts of other connectors) longer than the data traces so they make contact first.
You couldn't make it quite as simple as (a given flavor of) SPI, but something close to I²C should be feasible.
Very true. And dealing with bit ordering, half-duplex, the 4 modes, chip select to first clock setup times, bits per word, "strobing" nCS between words, the list goes on. But when you see "USB 1.1 device" you know a large majority of what it can support and what it'll do.
The article goes through a long list of 8 pin chips but ignores the very popular $0.10 CH32V003, which has 2k RAM and 16k Flash running at 48 MHz and 1 CPI -- or the new CH570 (I have a dev board on the way) which is also $0.10 in SOIC8 but now runs at 100 MHz with 16k RAM and 256k flash and has USB and a 2.4 GHz packet radio.
CH32V003 is not available on mouser.com or digikey.com
Googling for "CH570" produces results about tractors. Got a link?
EDIT: found info here: https://www.cnx-software.com/2025/04/02/10-cents-wch-ch570-c...
8-pin part lacks USB AND only has 3 I/O pins. It would be disqualified due to being too I/O-poor. Wasting 5 pins out of 8 is a joke!
As for the old one, CH32V003: 48MHz is slower than the STM's 150MHz, half the flash, 1/4 the RAM. It is still not the best option.
I did update the article with them, though :)
> 8-pin part lacks USB AND only has 3 I/O pins
But you get radio (BLE in the CH572 version), which means you don't need USB.
My comment was not that you didn't choose them but that you didn't consider them.
You do NOT get BLE in the 8-pin part
I just considered them and added them to my writeup :)
You get the radio in the 8 pin part. That's the "ANT" connection, pin 8, one of the three "wasted" pins (along with the crystal) you complain about.
2.4Ghz. I was really wondering about the 24Ghz.
oops .. my brain of course knows but my fingers didn't in this instance. Fixed.
I think it's compatible with the old nRF24 chips -- I'll test when mine arrives in a week or so. The CH572 version has BLE5 ... I think the same hardware but including a software stack.
There are plenty of MCUs that will work as a USB device, they were just ruled out by the package restriction.
If there has to be a chip to facilitate coms, I feel like you could go on a similar hunt for 8 pin microcontrollers that could serve that function and maybe also provide some extra functionality. It would be interesting if it could connect to a PC though a DDC connection.
So you want to replace a USB PHY with a serial to Ethernet converter and an Ethernet PHY.
The reality is that the simple protocols like SPI and I2C just are not good enough. They aren't fast, the single-ended signal scheme makes them very sensitive to noise, and there is no error correction. These protocols make sense and work extremely well for their intended purpose: connecting ICs on a PCB. If you expose an unterminated port to the outside world, all bets are off.
These protocols and variations thereof are still in heavy use in modern PCs. But they're internal busses, as the protocols intend.
I haven't looked closely at the USB spec, but I imagine the main problem with bit-banging is simply the speed required. You have to have dedicated hardware because no microcontroller is fast enough to toggle the pins while also running the software stack to decode the protocol and manage error correction.
You can run into this exact problem bit-banging I2C. With a 20MHz CPU, the maximum clock speed you can get is about 250KHz. Just a bit more than half the typical maximum rate of 400KHz. You can absolutely forget about the 1MHz version.
PHYs exist for one very good reason: it is vastly cheaper to offload comms protocols to hardware. Without that, you have to over-spec your CPU by quite a lot to get enough resources to manually manage communication. This is why every modern microcontroller contains hardware for I2C, SPI, serial, etc.
In summary, the simple serial protocols like SPI and I2C and UART are just absolutely terrible choices for external peripherals. They can't operate at reasonable speeds, they can't tolerate long cables, they can't tolerate noise. The nature and design of these protocols (excepting RS232 which is not UART) means that they cannot be used this way. There's no change to the spec you could make to support this without reinventing USB.
UART over LVDS is still quite simple and works well for long cables and it tolerates ground differences and noise well.
USB is also tough to bitbang also it has pretty strict timing requirements. Compared to something like i2c where the clock only advances when the pin is explicitly toggled.
You may have intended to say SPI. I²C does support "clock stretching" to delay until ready, but that's only in one particular case; otherwise the I²C clock advances all the time at whatever your baud rate is, not only when a pin is explicitly toggled.
i mean... someone did try this with i2c. a couple of dead computer companies shipped a bus that i forget the name of, based on this concept. its descendant is the vga hdmi control channel spec (which was implemented as a de facto separate standard but is very similar)
the name is escaping me
ACCESS.bus by Philips (who developed I²C) and DEC, and the DEC variant SERIAL.bus (with different voltage levels) used by their keyboards and mice for a little while.
And a variant of ACCESS.bus lives on as the extremely widely adopted DDC that is a part of HDMI, DVI, and VGA.
I mean technically you have all of these interfaces on a raspberry pi.
USB is something that is possible to understand, and apparently bit-bang at at least low speed 1.5Mbps. Probably full speed 12Mbps as well on a modern MCU. I don't understand it, but one can.
In that sense it's like SPI, or perhaps more like CAN or SD: when you don't understand it, you reach for someone else to have done it for you, but you can choose to understand it and once you understand it you can implement it.
If you're the slave you have tight timing requirements but you only have to respond with certain fixed bit patterns to certain other bit patterns. If you're the master, you can do more things concurrently because the slave won't notice a little jitter in how often you poll it, but you have the problem of dealing with a wider variety of slaves that can be connected.
It's almost 2 chips. One is just a USB-serial IC! But you didn't count the SD card, so you're up to 3 again.
Total pin count is so low on this, I'm very tempted to make a dead bug version.
The SD card itself contains a fairly powerful processor, likely a 32-bit ARM. It would be a fun hack to do a similar trick with that.
A very fast 8051 is also just as if not more likely to be in the SD card:
https://www.bunniestudios.com/blog/2013/on-hacking-microsd-c...
i have an eye-fi SD card that has wifi built in. So you don't even need the serial port!
Been there. Done that. Got the t-shirt: https://dmitry.gr/?r=05.Projects&proj=15.%20Transcend%20WiFi...
I didn’t make a dead bug version so you’d be first :). Microsd-to-sd adapters make good solderable microsd holders.
USB2Serial IC could go to the cable made by others and "doesn't count" as µSD doesn't count.
I've dabbled in microcontrollers and enjoy how the limitations force me to find creative solutions, but this is truly next level. I'm not great with a soldering iron but I'm seriously considering assembling one of these.
I have the perverse urge to forego even the board, and just make this a circuit sculpture.
silkscreen "555" onto at least one of the ICs, if you do this
Do it!
I am not an artist or a sculptor so I did not dare try
I think it would be cute to also use 8 pin SPI flash chip instead of SD card for storage.
Looked into it. But then the “getting files in and out” story gets hard.
You can use a chip clip, but presumably you rejected that idea because your objective is for this to be replicable by the kind of people who don't know what a chip clip is.
I'd be very surprised if there isn't a filesystem driver for SPI flash. Linux obviously can speak SPI and SPI flash is extremely common in a lot of applications.
I mean once assembled. In my design you can remove card, put files in, boot again, use the files.
Theoretically you can use one of these: https://www.tindie.com/products/bobricius/micro-sd-card-to-s...
I haven't tried it so I don't know how well it works
It looks like a passive mechanical adapter. I'd argue that a SOIC-8 programming clip thing would be better. This looks like you need to write a decent amount of code for a computer to talk to it as easily as a FAT-16 SD card.
This pleasantly reminds me of the little 6502 or 1802 Altoids-tin computers you can buy and assemble, but arguably more "useful" (though I get a lot of use out of a 6502 ;-).
What do you do with your 6502?
Under parts selection.. Even considering the PIC 16F. Why.
Every 8 pin MCU was given a shot
I knew it was gonna be dimitry from reading the title
Not sure if compliment or insult :)
Definitely compliment! At least, if it was my comment with exactly same text
Like somebody said in response to a paper which was anonymously published by Newton: "I recognize the Lion from his claw!"
lol I’d assume a compliment!
Was there no native ARM linux you could have used? As I recall, you have used this emulated MIPs technique in many of your published projects, so it's good to prove that the hardware is working?
Or why not just go full native....grab some MIPS-core IP and make your own with an FPGA?
Because no FPGAs come in 8-pin packages
And no Linux runs on cortex-m0 with ram attached over SPI.
And MIPS is the easiest Linux-compat architecture to emulate.
Surely emulating ARM on ARM would be faster / easier to JIT? Or at least it seems that way
Actually, no, mips is an easier JIT target than arm as well. Source: I've written both ARM-to-thumb1 and MIPS-to-thumb1 JITs
Fascinating!
The main hang-up is that ARM uses PC as a general register a lot and in ways that make translating ARM instrs rather messy.
is entirely valid, even if nonsensical, instruction. But you must translate all valid inputs, else you risk breaking things. That may be a contrived example, but here is a common one: if one has a jumptable of relative offsets somewhere, pointed to by R10, even this is valid: That gets messy to translateInteresting, I hadn't thought about this. Is the issue that the JIT output is likely to be a different number of bytes away? tbb/tbh seems like a more common version of that problem, TBH.
As I understand it, this kind of thing was a big problem for ARM in the mid-90s when they finally wrote the ARM ARM and outlawed things like ldmia r2!, {r0-r4}.
Different number of bytes out than in is not an issue. Efficiently translating such constructs in the general case is hard. Imagine what it would look like.
> There was a time when one could order a kit and assemble a computer at home
I think I get what OP means but you can definitely order a pc kit and just assemble it nowadays
Not in the same way. Not with a soldering iron and schematics.
I recognize there is something hard describe about how "it's not the same", but:
https://eater.net/shop
Yes, but sadly that cannot run modern Linux
Please tell me you didn't use ENIG for the USB connector. It would be sacrilege.
I am just a lowly software guy who pretends to know how to use EAGLE. To me “ENIG” just means “5% more expensive boards”. What did I miss?
ENIG is gold coated not solid gold so it'll wear off and the metals under it will likely corrode. I think the majority of my USB connectors I eventually see wear marks on them.
I see. These contacts are just lead-free-solder coated, and thus is easy to re-apply with a soldering iron if they start wearing.