8BIT wrote:
After diving into the 65SPI-ATMega8 communications this weekend, I encountered the major drawback to SPI. There is no efficient way to know that the slave is ready to respond to the Master's requests with the SPI hardware. An external line is required.
This is why I said (in a different thread) that peripherals
must have an independently running SPI controller, running completely asynchronously from the intended peripheral. This lets the SPI interface continue to run while the peripheral itself is busy doing other things, allowing it, at a
minimum, to feed back a peripheral's ready-status to the master.
Code:
Pros:
* No external line necessary.
* Simpler host construction.
* If a peripheral goes south, only that peripheral remains in the seized state.
* Permits the possibility of using interrupts for asynchony between the host and peripheral, as the readiness reading then merely reflects the interrupt state.
Cons:
* Each peripheral potentially requires two microcontrollers instead of one: one to service the SPI interface, and one to perform the intended task.
* Without the use of interrupts, the host would have to poll each peripheral for its readiness using SPI bus transactions, one per peripheral. This has a software complexity cost.
With the external line approach, it would pretty much have to be an open-drain line, allowing any number of peripherals to assert it. The problem with this approach is that it is impossible to tell
which peripheral is pulling it into busy state, so the entire bus is seized until all peripherals are ready.
Code:
Pros:
* Simpler peripheral hardware, at the cost of minimal host hardware expense.
Cons:
* If any one peripheral says it's busy, the entire bus is locked from operation. This can waste bus bandwidth.
* Impossible to tell [i]which[/i] peripheral is the busy one.
* If a peripheral goes south, your host goes with it. :-)
* Interrupts can only tell you when the bus is free for use.
Login
Register
FAQ
Search
