7 ms·

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 see

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.

tylerflick 2y ago
I mean technically you have all of these interfaces on a raspberry pi.
- malfist 2y ago
  Tad more than 8 pins on a pi
- em3rgent0rdr 2y ago
  Yes, but the RPi is not yet quite a standard desktop/labtop workstation. And it would be nice if the RPi exposed its SPI, I2C, and UARTs over a standard mini connector like JST-SH connectors to ease plugging in peripherals (like is done with Stemma QT, Qwiic and Grove).
parl_match 2y ago
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
- kps 2y ago
  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.
  - kenny11 2y ago
    And a variant of ACCESS.bus lives on as the extremely widely adopted DDC that is a part of HDMI, DVI, and VGA.
pantalaimon 2y ago
There are plenty of MCUs that will work as a USB device, they were just ruled out by the package restriction.
- em3rgent0rdr 2y ago
  Well yeah, nowadays high-end micro-controllers may have an integrated USB HS PHY (notably STM32F7's and the MIMXRT1060 used in Teensy 4, and many others), but the basic cheap attiny-like or ice40-like hasn't and most usually require going through an external PHY. I've been wanting to get into using the CH32V305 cause it is in a hand-solder-friendly TSSOP-20 package and has integrated USB HS PHY but I hear it doesn't have a software support and I don't see it on microchip/digikey/etc. Though we may soon have easy access to 20-cent microcontrollers with USB HS, but still the protocol feels incredibly complex and way overkill for simply interfacing a peripheral to a computer.
  - pantalaimon 2y ago
    Any old SAM D21 will do USB. What software support are you looking for? Integration in TinyUSB?
mystified5016 2y ago
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.
- fxtentacle 2y ago
  UART over LVDS is still quite simple and works well for long cables and it tolerates ground differences and noise well.
  - em3rgent0rdr 2y ago
    Yeah, and LVDS is something that really cheap ice40 FPGAs support with not much of an area cost. (In my original comment I should have said to use differential signaling for going off-board.)
topspin 2y ago
> 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.
- Neywiny 2y ago
  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.
  - em3rgent0rdr 2y ago
    These (and hotswapping/handshaking) are small quibbles that could be addressed with a simple standard subset of SPI for human-plugable devices.
    - Neywiny 2y ago
      While true it does seem like the flexibility allows for good optimizations. For example, a lot of devices don't need addresses or have memory maps etc. So, sadly while it's a pain to deal with, it does make things very fast and efficient.
- kragen 2y ago
  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.
immibis 2y ago
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.
- Findecanor 2y ago
  Oh, USB 1.1 at the transport layer and lower is not that difficult. But there is more complexity on higher layers. USB HID (mice and keyboards) is often the first you'd want but it is special in that it allows a device to describe its own packet format in a tokenised data description language. The device only has to send an additional blob when asked, but the host has to parse the contents of that blob and use the result to parse the device's packets. And of course, every time there is complexity in a protocol and there are multiple implementations of it, there is more opportunity for them to be incompatible in very subtle ways. This phenomenon has caused for example that some gaming keyboards with N-key rollover that work perfectly on MS-Windows without any special drivers have been rejected outright by Apple or Linux hosts. (I hope these issues have been fixed now, but I'm not sure).
  - immibis 2y ago
    I thought there was also a mandatory fixed-layout "boot" profile for mice and keyboards? There was some controversy because vendors interpreted it as only being allowed to support the boot profile, resulting in most USB keyboards having 6-key rollover maximum.
    - Findecanor 2y ago
      In a nutshell, yes. There's a flag for it (actually "subclass") for indicating being able to switch to the boot protocol. Some hosts, especially BIOS:es, did check that flag but never sent the command to switch. Keyboard vendors catered to the lowest common denominator because it was essential that users be able to enter the PC BIOS at boot. BTW. Apple chiclet keyboards (before the "Magic") got an interested workaround to this problem for its proprietary Fn key. It uses a variation of the boot protocol but only a 5-byte array (5KRO). When the Fn key is pressed, the sixth byte will contain a code that is otherwise an error code if interpreted as the boot protocol.
brucehoult 2y ago
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.
- dmitrygr 2y ago
  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-ch572-risc-v-mcu-features-2-4ghz-wireless-bluetooth-le-5-0-usb-2-0/ 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 :)
  - brucehoult 2y ago
    > 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.
    - dmitrygr 2y ago
      You do NOT get BLE in the 8-pin part I just considered them and added them to my writeup :)
      - brucehoult 2y ago
        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.
Lerc 2y ago
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.
DecentShoes 2y ago
I still install brand new computers with serial ports! Dell sells us OptiPlex towers and we occasionally order them with a serial card to connect to legacy scientific instruments.
- tryauuum 2y ago
  I bought a Lenovo mini thinkstation with a serial port because I thought it would be cool. But I don't even know what cool stuff 8 can plug there, except for a serial console
Findecanor 2y ago
I work in the AV industry. RS-232 is still the king for control signals between devices, even on brand new hardware that costs >10K USD. TV screens for signage/conference rooms often have RS-232 for more versatile control than HDMI-CEC. Higher bitrate than 9600 BPS is often not needed. The most common connector consists of three-pin screw terminals (Tx, Rx, GND), although these days most installations have at least one RS232-to-USB adaptor somewhere. And for larger rooms, RS232 is bridged over Ethernet. This was a bit of a surprise when I started, but then I realised that many installations are decades old, with components having been replaced individually.

tylerflick 2y ago

I mean technically you have all of these interfaces on a raspberry pi.

malfist 2y ago
Tad more than 8 pins on a pi
em3rgent0rdr 2y ago
Yes, but the RPi is not yet quite a standard desktop/labtop workstation. And it would be nice if the RPi exposed its SPI, I2C, and UARTs over a standard mini connector like JST-SH connectors to ease plugging in peripherals (like is done with Stemma QT, Qwiic and Grove).

parl_match 2y ago

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

kps 2y ago
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.
- kenny11 2y ago
  And a variant of ACCESS.bus lives on as the extremely widely adopted DDC that is a part of HDMI, DVI, and VGA.

pantalaimon 2y ago

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

em3rgent0rdr 2y ago
Well yeah, nowadays high-end micro-controllers may have an integrated USB HS PHY (notably STM32F7's and the MIMXRT1060 used in Teensy 4, and many others), but the basic cheap attiny-like or ice40-like hasn't and most usually require going through an external PHY. I've been wanting to get into using the CH32V305 cause it is in a hand-solder-friendly TSSOP-20 package and has integrated USB HS PHY but I hear it doesn't have a software support and I don't see it on microchip/digikey/etc. Though we may soon have easy access to 20-cent microcontrollers with USB HS, but still the protocol feels incredibly complex and way overkill for simply interfacing a peripheral to a computer.
- pantalaimon 2y ago
  Any old SAM D21 will do USB. What software support are you looking for? Integration in TinyUSB?

mystified5016 2y ago

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.

fxtentacle 2y ago
UART over LVDS is still quite simple and works well for long cables and it tolerates ground differences and noise well.
- em3rgent0rdr 2y ago
  Yeah, and LVDS is something that really cheap ice40 FPGAs support with not much of an area cost. (In my original comment I should have said to use differential signaling for going off-board.)

topspin 2y ago

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

Neywiny 2y ago
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.
- em3rgent0rdr 2y ago
  These (and hotswapping/handshaking) are small quibbles that could be addressed with a simple standard subset of SPI for human-plugable devices.
  - Neywiny 2y ago
    While true it does seem like the flexibility allows for good optimizations. For example, a lot of devices don't need addresses or have memory maps etc. So, sadly while it's a pain to deal with, it does make things very fast and efficient.
kragen 2y ago
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.

immibis 2y ago

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.

Findecanor 2y ago
Oh, USB 1.1 at the transport layer and lower is not that difficult. But there is more complexity on higher layers. USB HID (mice and keyboards) is often the first you'd want but it is special in that it allows a device to describe its own packet format in a tokenised data description language. The device only has to send an additional blob when asked, but the host has to parse the contents of that blob and use the result to parse the device's packets. And of course, every time there is complexity in a protocol and there are multiple implementations of it, there is more opportunity for them to be incompatible in very subtle ways. This phenomenon has caused for example that some gaming keyboards with N-key rollover that work perfectly on MS-Windows without any special drivers have been rejected outright by Apple or Linux hosts. (I hope these issues have been fixed now, but I'm not sure).
- immibis 2y ago
  I thought there was also a mandatory fixed-layout "boot" profile for mice and keyboards? There was some controversy because vendors interpreted it as only being allowed to support the boot profile, resulting in most USB keyboards having 6-key rollover maximum.
  - Findecanor 2y ago
    In a nutshell, yes. There's a flag for it (actually "subclass") for indicating being able to switch to the boot protocol. Some hosts, especially BIOS:es, did check that flag but never sent the command to switch. Keyboard vendors catered to the lowest common denominator because it was essential that users be able to enter the PC BIOS at boot. BTW. Apple chiclet keyboards (before the "Magic") got an interested workaround to this problem for its proprietary Fn key. It uses a variation of the boot protocol but only a 5-byte array (5KRO). When the Fn key is pressed, the sixth byte will contain a code that is otherwise an error code if interpreted as the boot protocol.

brucehoult 2y ago

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.

dmitrygr 2y ago
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-ch572-risc-v-mcu-features-2-4ghz-wireless-bluetooth-le-5-0-usb-2-0/ 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 :)
- brucehoult 2y ago
  > 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.
  - dmitrygr 2y ago
    You do NOT get BLE in the 8-pin part I just considered them and added them to my writeup :)
    - brucehoult 2y ago
      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.

Lerc 2y ago

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.

DecentShoes 2y ago

I still install brand new computers with serial ports! Dell sells us OptiPlex towers and we occasionally order them with a serial card to connect to legacy scientific instruments.

tryauuum 2y ago
I bought a Lenovo mini thinkstation with a serial port because I thought it would be cool. But I don't even know what cool stuff 8 can plug there, except for a serial console

Findecanor 2y ago

I work in the AV industry. RS-232 is still the king for control signals between devices, even on brand new hardware that costs >10K USD. TV screens for signage/conference rooms often have RS-232 for more versatile control than HDMI-CEC. Higher bitrate than 9600 BPS is often not needed. The most common connector consists of three-pin screw terminals (Tx, Rx, GND), although these days most installations have at least one RS232-to-USB adaptor somewhere. And for larger rooms, RS232 is bridged over Ethernet. This was a bit of a surprise when I started, but then I realised that many installations are decades old, with components having been replaced individually.