An interactive-speed Linux computer made of only 3 8-pin chips

And worth a shirt "After much thinking, the solution is obvious."

> 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.

There are plenty of MCUs that will work as a USB device, they were just ruled out by the package restriction.

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.

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.

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

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.

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.

USB2Serial IC could go to the cable made by others and "doesn't count" as µSD doesn't count.

I didn’t make a dead bug version so you’d be first :). Microsd-to-sd adapters make good solderable microsd holders.

Looked into it. But then the “getting files in and out” story gets hard.

Do it!

I am not an artist or a sculptor so I did not dare try

What do you do with your 6502?

Every 8 pin MCU was given a shot

Not sure if compliment or insult :)

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.

Not in the same way. Not with a soldering iron and schematics.

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?