[HN Gopher] SPI: The serial peripheral interface [video]
___________________________________________________________________
SPI: The serial peripheral interface [video]
Author : U1F984
Score : 41 points
Date : 2021-11-20 14:28 UTC (2 days ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| cdcarter wrote:
| 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 wrote:
| 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 wrote:
| 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.
| magicalhippo wrote:
| 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)
| zwieback wrote:
| 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...
| emptycan wrote:
| 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 wrote:
| 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
| bullen wrote:
| 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.
| BenjiWiebe wrote:
| SPI isn't addressable.
| Taniwha wrote:
| 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
| emptycan wrote:
| Yes it is - that's what /SS is for.
| MisterTea wrote:
| 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.
| flyingcircus3 wrote:
| Flash memory devices use the CS line as an integral part
| of the protocol. It is definitely not optional.
| duskwuff wrote:
| > 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.
| monocasa wrote:
| 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.
| jstanley wrote:
| If that counts then you can do exactly the same thing
| with a UART-based protocol, no?
| monocasa wrote:
| Do you know of any uart hardware that'll only latch on
| /SS active?
| jstanley wrote:
| 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 wrote:
| 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.
| dfox wrote:
| 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.
| jhallenworld wrote:
| 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 wrote:
| 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...
| [deleted]
___________________________________________________________________
(page generated 2021-11-22 23:01 UTC)