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.
[deleted]
SPI: The serial peripheral interface [video]
11–20 of 32 posts
Re: SPI: The serial peripheral interface [video]
#12I 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.
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.
Re: SPI: The serial peripheral interface [video]
#13I 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.
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
I guess with RxTx or UART as some seem to call it, you only have one device per RxTx pair so you need more IO pins... true didn't think of that, but my only real uses are 1) make some modem like thing for my C64 and 2) talk to a LoRa radio from my Raspberry Zero in both those cases I'm actually ok with having only one pheriperal and there is nothing else I want except the connection, all other things use other protocols.
Re: SPI: The serial peripheral interface [video]
#14Earlier quoted context omitted.
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
SPI isn't addressable.
There are some Microchip chips that implement weird SPI/I2C hybrid which does I2C-like slave addressing over SPI. But thats it for the addressing.
Re: SPI: The serial peripheral interface [video]
#15I 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.
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-document...
[2]: https://www.microchip.com/en-us/product/MCP3202 (semi-random example, datasheet chapter 5 and figure 5-2)
Re: SPI: The serial peripheral interface [video]
#16Re: SPI: The serial peripheral interface [video]
#17Earlier quoted context omitted.
Yes it is - that's what /SS is for.
Chip selects are optional. You can daily chain multiple spi devices and push the data out in a contiguous block. All the chip selects are tied together and only one cs line is used from the cpu.
> You can daily chain multiple spi devices
For some simple SPI devices, sometimes. Many SPI devices, especially more complex ones, won't let you shift data through the device without attempting to interpret it.
Re: SPI: The serial peripheral interface [video]
#18Earlier quoted context omitted.
Yes it is - that's what /SS is for.
Chip selects are optional. You can daily chain multiple spi devices and push the data out in a contiguous block. All the chip selects are tied together and only one cs line is used from the cpu.
Flash memory devices use the CS line as an integral part of the protocol. It is definitely not optional.
Re: SPI: The serial peripheral interface [video]
#19Earlier quoted context omitted.
Chip selects are optional. You can daily chain multiple spi devices and push the data out in a contiguous block. All the chip selects are tied together and only one cs line is used from the cpu.
> You can daily chain multiple spi devices For some simple SPI devices, sometimes. Many SPI devices, especially more complex ones, won't let you shift data through the device without attempting to interpret it.
Or will shift out something completely different, like the response to the last command they received, just FFs so you can three wire in the general case, or even just garbage.
Re: SPI: The serial peripheral interface [video]
#20Earlier quoted context omitted.
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
SPI isn't addressable.
In my experience has been that there exist essentially 2 types of SPI, one addressable by CS, the other (more i2c-like) by the first byte (CS still required to frame the transactions.
I'm working with one of the latter type at the moment that's even worse, it daisy chains chips with each editing the address as it passes through until it hits one where it's 0, they share a CS and a wired-or interrupt, but avoid the need to have 32 CS pins