| ??? 11/01/11 14:52 Read: times |
#184507 - Quite common Responding to: ???'s previous message |
This type of handshaked transfer is quite common.
It is probably also one of the reasons why there are so little discussions on the net about software-implmented SPI slaves. It can be done with a similar number of signals (data in, data out, master-clock, slave-ack) instead of (data in, data out, master-clock, slave-select). But without the very problematic timing requirements on the slave side. Extra functionality can be added by driving the signals in open-collector/open-drain mode, where it is possible to merge master-clock + slave-ack into same wire, or to keep two handshake lines but to add extra synchronization states - transmitter "driving high", but receiver shorting, informing transmitter of extra state. |
| Topic | Author | Date |
| SPI Slave in 89S52 | 01/01/70 00:00 | |
| Get real processor | 01/01/70 00:00 | |
| Topic Author Date | 01/01/70 00:00 | |
| Big problem | 01/01/70 00:00 | |
| Look for a different model | 01/01/70 00:00 | |
| Try 8051 BASCOM | 01/01/70 00:00 | |
| at what speed | 01/01/70 00:00 | |
| Interpreters have an easier life. | 01/01/70 00:00 | |
| Soft SPI speed | 01/01/70 00:00 | |
| But how to combine that loop with a real program? | 01/01/70 00:00 | |
| and more | 01/01/70 00:00 | |
| Software master trivial - slave is not | 01/01/70 00:00 | |
| SPI analysis is made, results? | 01/01/70 00:00 | |
| There _may_ be a solution - but maybe not acceptable | 01/01/70 00:00 | |
| sure, and so what? | 01/01/70 00:00 | |
| SPI at 100Kbps | 01/01/70 00:00 | |
| Still gives puny transfer rate with significant limitations | 01/01/70 00:00 | |
| the answer is | 01/01/70 00:00 | |
| Fully Interlocked Handshaking. | 01/01/70 00:00 | |
Quite common | 01/01/70 00:00 |