6 ms·

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

> 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.
- topspin 2y ago
  Perhaps there is a place for a simpler alternative. My comment was pretty tangential to this discussion about the merits of SPI vs USB vs whatever. My point is that I believe some benefit can be had by software developers in understanding how components can be integrated together using a primitive as simple minded as SPI. I used the qualification "some" again, as well. I don't offer any revolutionary insights, but if you survey how SPI is used in practice, you'll learn some things of value, even if you never use SPI yourself.
- timschmidt 2y ago
  > something close to I²C should be feasible. That'd be https://en.wikipedia.org/wiki/System_Management_Bus https://en.wikipedia.org/wiki/System_Management_Bus
  - kragen 2y ago
    That's just I²C with some features disabled. It doesn't add any of the things I²C is lacking. Well, okay, I guess SMBus ARP kind of does. Thanks!
    - timschmidt 2y ago
      I never thought about making hot pluggable SMBus peripherals. It's an interesting idea. Many motherboards even have headers broken out, and of course operating systems already have drivers for many SMBus peripheral types. LoFi USB.
      - NavinF 2y ago
        We have hot pluggable I2C at home. Every HDMI port (and pretty much every DP port with a passive adapter) has I2C on the DDC pins. The port also provides 5V 50mA so your MCU doesn't need external power. Example: https://www.reddit.com/r/raspberry_pi/comments/ws1ale/i2c_on_the_hdmi_port_raspberry_pi_4/ https://www.reddit.com/r/raspberry_pi/comments/ws1ale/i2c_on...
amelius 2y ago
Since when does USB have error correction/detection?
- tverbeure 2y ago
  USB bulk packets have a 16 bit CRC.
  - amelius 2y ago
    Interesting. I recently tested a 6ft USB3 cable and an attached drive. The transfer of a 1TB file failed a few times (not sure of the details). This is strange, since the cable couldn't have been that bad (?) and the 16-bit CRC should have caught those errors (assuming an error will trigger a resend of data). Any ideas what the issue could have been? Does Linux provide a way to view the error rate?
    - em3rgent0rdr 2y ago
      https://wiki.wireshark.org/CaptureSetup/USB https://wiki.wireshark.org/CaptureSetup/USB says "Software USB capture captures URBs (USB Request Blocks) rather than raw USB packets." So Wireshark couldn't give you the CRC, which would be stripped away. You could hypothetically use a really-really high bandwidth oscilloscope (like 2 GHz to view 480 MHz USB HS signals), but those are expensive. So you would have to resort to using external USB sniffer...out of curiosity I found someone made a sniffer that is basically a USB-capable microcontroller plus an FPGA and a USB PHY: https://hackaday.com/2023/06/13/cheap-usb-sniffer-has-wireshark-interface/ https://hackaday.com/2023/06/13/cheap-usb-sniffer-has-wiresh...
    - topspin 2y ago
      > the 16-bit CRC should have caught those errors I believe your confidence in the 16-bit CRC is excessive. There is a 1 in 65536 chance of a 16 bit CRC failing for certain types of corruption in 512 byte bulk USB packets, and there are about 2 billion packets in a 1TB transfer. If the BER is high, corruption of the transfer is not surprising. A 6ft cable should be fine, assuming it is well designed, manufactured correctly, in good condition, and not in close proximity to high noise sources, such as SMPS. If any of those factors are compromised the BER will increase, and you will then be testing the rather limited capabilities of 16 bit CRC. USB4 has 32 bit CRC for data payloads for a reason. In the mean time, the #1 thing you can do is use short, high quality cables.

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.

topspin 2y ago
Perhaps there is a place for a simpler alternative. My comment was pretty tangential to this discussion about the merits of SPI vs USB vs whatever. My point is that I believe some benefit can be had by software developers in understanding how components can be integrated together using a primitive as simple minded as SPI. I used the qualification "some" again, as well. I don't offer any revolutionary insights, but if you survey how SPI is used in practice, you'll learn some things of value, even if you never use SPI yourself.
timschmidt 2y ago
> something close to I²C should be feasible. That'd be https://en.wikipedia.org/wiki/System_Management_Bus https://en.wikipedia.org/wiki/System_Management_Bus
- kragen 2y ago
  That's just I²C with some features disabled. It doesn't add any of the things I²C is lacking. Well, okay, I guess SMBus ARP kind of does. Thanks!
  - timschmidt 2y ago
    I never thought about making hot pluggable SMBus peripherals. It's an interesting idea. Many motherboards even have headers broken out, and of course operating systems already have drivers for many SMBus peripheral types. LoFi USB.
    - NavinF 2y ago
      We have hot pluggable I2C at home. Every HDMI port (and pretty much every DP port with a passive adapter) has I2C on the DDC pins. The port also provides 5V 50mA so your MCU doesn't need external power. Example: https://www.reddit.com/r/raspberry_pi/comments/ws1ale/i2c_on_the_hdmi_port_raspberry_pi_4/ https://www.reddit.com/r/raspberry_pi/comments/ws1ale/i2c_on...

amelius 2y ago

Since when does USB have error correction/detection?

tverbeure 2y ago
USB bulk packets have a 16 bit CRC.
- amelius 2y ago
  Interesting. I recently tested a 6ft USB3 cable and an attached drive. The transfer of a 1TB file failed a few times (not sure of the details). This is strange, since the cable couldn't have been that bad (?) and the 16-bit CRC should have caught those errors (assuming an error will trigger a resend of data). Any ideas what the issue could have been? Does Linux provide a way to view the error rate?
  - em3rgent0rdr 2y ago
    https://wiki.wireshark.org/CaptureSetup/USB https://wiki.wireshark.org/CaptureSetup/USB says "Software USB capture captures URBs (USB Request Blocks) rather than raw USB packets." So Wireshark couldn't give you the CRC, which would be stripped away. You could hypothetically use a really-really high bandwidth oscilloscope (like 2 GHz to view 480 MHz USB HS signals), but those are expensive. So you would have to resort to using external USB sniffer...out of curiosity I found someone made a sniffer that is basically a USB-capable microcontroller plus an FPGA and a USB PHY: https://hackaday.com/2023/06/13/cheap-usb-sniffer-has-wireshark-interface/ https://hackaday.com/2023/06/13/cheap-usb-sniffer-has-wiresh...
  - topspin 2y ago
    > the 16-bit CRC should have caught those errors I believe your confidence in the 16-bit CRC is excessive. There is a 1 in 65536 chance of a 16 bit CRC failing for certain types of corruption in 512 byte bulk USB packets, and there are about 2 billion packets in a 1TB transfer. If the BER is high, corruption of the transfer is not surprising. A 6ft cable should be fine, assuming it is well designed, manufactured correctly, in good condition, and not in close proximity to high noise sources, such as SMPS. If any of those factors are compromised the BER will increase, and you will then be testing the rather limited capabilities of 16 bit CRC. USB4 has 32 bit CRC for data payloads for a reason. In the mean time, the #1 thing you can do is use short, high quality cables.