6 ms·

SPI: The serial peripheral interface [video]

52 points by U1F984 5y ago

cdcarter 5y ago
Ben's videos are some of the most interesting content on Youtube. The build an 8-bit computer from scratch tutorial has been around this site a few times, as has the 6502 series. But what really gets interesting are these peripheral videos where he digs into a specific system or concept. His videos about how error correction works were a real eye-opener for me. It's the right level of zoomed in.
- ASalazarMX 5y ago
  The parts when he troubleshoots are the most educational by far. He explains the theory, he puts it in practice, and debugs the result. Also, his editing is perfect IMO, he really knows how to teach.
bullen 5y ago
I wish more devices simply used RxTx (or COM/RS-232) so that the protocol was defined inside the character payload instead. Simplicity is worth sacrificing bandwidth for.
- emptycan 5y ago
  Simplicity of what exactly? From the perspective of the device/hardware, SPI is much simpler. A UART based solution tends to be relatively much more complex on the hardware/device side. You can implement a basic compliant SPI slave in a tiny bit of silicon - like a handful of flip flops simple. Moreover, you realize many of the simplest SPI devices don't have an oscillator, so you're still going to need a clock line - and if its truly a UART/asynchronous it may not be convenient to get a high enough speed external clock.
- lloydatkinson 5y ago
  Given that I2C and SPI are addressable replacing them with a bare TTL serial interface would be horrendous because now everyone needs to invent their own addressing scheme which they already had with the other two. 0/10 suggestion
  - BenjiWiebe 5y ago
    SPI isn't addressable.
    - emptycan 5y ago
      Yes it is - that's what /SS is for.
      - jstanley 5y ago
        If that counts then you can do exactly the same thing with a UART-based protocol, no?
        monocasa 5y ago
        Do you know of any uart hardware that'll only latch on /SS active?
        jstanley 5y ago
        No, I don't, but at the point where you're integrating a UART, adding a couple of logic gates on the data input doesn't seem too much of a stretch. I'm not saying using UARTs instead of SPI is a good idea! I'm just saying the reason that it's not a good idea is not because UART's don't have /SS inputs.
        monocasa 5y ago
        But then how is the device supposed to know when it can respond? Most uart devices don't respect flow control. They assume they can transmit at any point.
        jstanley 5y ago
        Fair point.
      - 5y ago
- deleted 5y ago
  [deleted]
- zwieback 5y ago
  Do you mean implicit clock to save the third line? Other than that SPI is about as simple as it gets. Plus there's a protocol for practically every requirement: i2c for simple slowish shared bus with clock, 1-wire shared bus without clock, SPI fast and simple, serial single ended (RS232) or differential (RS485) for stuff outside of your PCB...
- jhallenworld 5y ago
  A nice advantage of SPI is that it can not lock up the master. This is not true of I2C, where the slave could stretch the clock forever. This is also not true of UART, where the slave just might not respond. But in fact both SPI and I2C can be simpler than UART since they are strictly master/slave. With a UART, the slave could send you unrequested data, which means your software has to handle asynchronous events. Even if it doesn't you probably have to implement timeouts and input flushing. SPI is simpler than I2C in that it is a single-master bus, so accesses are atomic (at least at the bus level, within your RTOS is another story...). You can use simple logic gates as SPI peripherals: for example, 74HC595 works as a SPI accessible 8-bit output port. This is important because such chips are the cheapest available (vs. I2C output port or UART to parallel..) Despite all this simplicity, SPI is very fast. Where UART has the advantage is software: picocom on Linux or Teraterm on Windows. Basically you don't have to develop any host-side software if you use a UART. I like to use the old ymodem protocol for embedded system firmware updates.. since again no host-side software has to be developed.
  - aaroninsf 5y ago
    UART has another advantage, fungible cheap very-long runs when paired to balanced RS485 transceivers–at least, for relatively slow baud rates, and with decent shielded cable, you can get 56 kbps well over a kilometer. Better with some effort. In a past life I got a patent on a hardware product that used UARTs and cheap optical parts to do face-to-face wireless at 230K+... we did our firmware upgrades and configuration in the field (where installation environments might have dozens of our product). I always liked I2C, though; and if I'd stayed in that industry, we were looking at CAN for fault tolerance...
    - jhallenworld 5y ago
      I've done similar things with UARTs over long distance- I was about to write about it, but I actually have it on github: https://github.com/jhallen/joes-sandbox/tree/master/hw/linedriver https://github.com/jhallen/joes-sandbox/tree/master/hw/lined... CAN is interesting in that the protocol is pretty complex, but from software point of view it's just send_packet() and register a handler for receive packets. The annoying thing is that MCUs don't have built-in CAN line drivers. A new thing is 1000BASE-T1- Gigabit Ethernet over a single twisted pair. This is supposed to be the future in the auto world..
- magicalhippo 5y ago
  The point of SPI is that it can be implemented with a simple shift register at either end. It's not about bandwidth so much as implementation simplicity. For SAR[1] ADC's for example, the output can be generated while the ADC conversion is happening. This reduces complexity and latency, and allows you to easily control the sampling time by how fast you clock the SPI bus[2]. If the ADC had to output as text via UART it would need to complete the conversion and then convert the output to characters before stuffing it over an UART with start and stop bits and whatnot. And you'd need some other way to control sampling and conversion time. An internal clock? External, but separate clock? Either way, added complexity. [1]: https://www.maximintegrated.com/en/design/technical-documents/tutorials/1/1080.html https://www.maximintegrated.com/en/design/technical-document... [2]: https://www.microchip.com/en-us/product/MCP3202 https://www.microchip.com/en-us/product/MCP3202 (semi-random example, datasheet chapter 5 and figure 5-2)

52 points by U1F984 5y ago

Ben's videos are some of the most interesting content on Youtube. The build an 8-bit computer from scratch tutorial has been around this site a few times, as has the 6502 series. But what really gets interesting are these peripheral videos where he digs into a specific system or concept. His videos about how error correction works were a real eye-opener for me. It's the right level of zoomed in.

ASalazarMX 5y ago
The parts when he troubleshoots are the most educational by far. He explains the theory, he puts it in practice, and debugs the result. Also, his editing is perfect IMO, he really knows how to teach.

bullen 5y ago

I wish more devices simply used RxTx (or COM/RS-232) so that the protocol was defined inside the character payload instead. Simplicity is worth sacrificing bandwidth for.

emptycan 5y ago
Simplicity of what exactly? From the perspective of the device/hardware, SPI is much simpler. A UART based solution tends to be relatively much more complex on the hardware/device side. You can implement a basic compliant SPI slave in a tiny bit of silicon - like a handful of flip flops simple. Moreover, you realize many of the simplest SPI devices don't have an oscillator, so you're still going to need a clock line - and if its truly a UART/asynchronous it may not be convenient to get a high enough speed external clock.
lloydatkinson 5y ago
Given that I2C and SPI are addressable replacing them with a bare TTL serial interface would be horrendous because now everyone needs to invent their own addressing scheme which they already had with the other two. 0/10 suggestion
- BenjiWiebe 5y ago
  SPI isn't addressable.
  - emptycan 5y ago
    Yes it is - that's what /SS is for.
    - jstanley 5y ago
      If that counts then you can do exactly the same thing with a UART-based protocol, no?
      - monocasa 5y ago
        Do you know of any uart hardware that'll only latch on /SS active?
        jstanley 5y ago
        No, I don't, but at the point where you're integrating a UART, adding a couple of logic gates on the data input doesn't seem too much of a stretch. I'm not saying using UARTs instead of SPI is a good idea! I'm just saying the reason that it's not a good idea is not because UART's don't have /SS inputs.
        monocasa 5y ago
        But then how is the device supposed to know when it can respond? Most uart devices don't respect flow control. They assume they can transmit at any point.
        jstanley 5y ago
        Fair point.
    - 5y ago
deleted 5y ago
[deleted]
zwieback 5y ago
Do you mean implicit clock to save the third line? Other than that SPI is about as simple as it gets. Plus there's a protocol for practically every requirement: i2c for simple slowish shared bus with clock, 1-wire shared bus without clock, SPI fast and simple, serial single ended (RS232) or differential (RS485) for stuff outside of your PCB...
jhallenworld 5y ago
A nice advantage of SPI is that it can not lock up the master. This is not true of I2C, where the slave could stretch the clock forever. This is also not true of UART, where the slave just might not respond. But in fact both SPI and I2C can be simpler than UART since they are strictly master/slave. With a UART, the slave could send you unrequested data, which means your software has to handle asynchronous events. Even if it doesn't you probably have to implement timeouts and input flushing. SPI is simpler than I2C in that it is a single-master bus, so accesses are atomic (at least at the bus level, within your RTOS is another story...). You can use simple logic gates as SPI peripherals: for example, 74HC595 works as a SPI accessible 8-bit output port. This is important because such chips are the cheapest available (vs. I2C output port or UART to parallel..) Despite all this simplicity, SPI is very fast. Where UART has the advantage is software: picocom on Linux or Teraterm on Windows. Basically you don't have to develop any host-side software if you use a UART. I like to use the old ymodem protocol for embedded system firmware updates.. since again no host-side software has to be developed.
- aaroninsf 5y ago
  UART has another advantage, fungible cheap very-long runs when paired to balanced RS485 transceivers–at least, for relatively slow baud rates, and with decent shielded cable, you can get 56 kbps well over a kilometer. Better with some effort. In a past life I got a patent on a hardware product that used UARTs and cheap optical parts to do face-to-face wireless at 230K+... we did our firmware upgrades and configuration in the field (where installation environments might have dozens of our product). I always liked I2C, though; and if I'd stayed in that industry, we were looking at CAN for fault tolerance...
  - jhallenworld 5y ago
    I've done similar things with UARTs over long distance- I was about to write about it, but I actually have it on github: https://github.com/jhallen/joes-sandbox/tree/master/hw/linedriver https://github.com/jhallen/joes-sandbox/tree/master/hw/lined... CAN is interesting in that the protocol is pretty complex, but from software point of view it's just send_packet() and register a handler for receive packets. The annoying thing is that MCUs don't have built-in CAN line drivers. A new thing is 1000BASE-T1- Gigabit Ethernet over a single twisted pair. This is supposed to be the future in the auto world..
magicalhippo 5y ago
The point of SPI is that it can be implemented with a simple shift register at either end. It's not about bandwidth so much as implementation simplicity. For SAR[1] ADC's for example, the output can be generated while the ADC conversion is happening. This reduces complexity and latency, and allows you to easily control the sampling time by how fast you clock the SPI bus[2]. If the ADC had to output as text via UART it would need to complete the conversion and then convert the output to characters before stuffing it over an UART with start and stop bits and whatnot. And you'd need some other way to control sampling and conversion time. An internal clock? External, but separate clock? Either way, added complexity. [1]: https://www.maximintegrated.com/en/design/technical-documents/tutorials/1/1080.html https://www.maximintegrated.com/en/design/technical-document... [2]: https://www.microchip.com/en-us/product/MCP3202 https://www.microchip.com/en-us/product/MCP3202 (semi-random example, datasheet chapter 5 and figure 5-2)