??? 10/30/11 22:01 Read: times |
#184461 - Big problem Responding to: ???'s previous message |
You shouldn't look for code for the simple reason that it isn't really possible to post a generic solution in software.
One solution is to stop everything else the processor is doing (including anything that generates interrupts) while communicating. But that requires the master to hold the slave-select line for long enough before the data starts to arrive, that the slave have time to react and deactivate everything else. Even when the slave does nothing but busy-looping, checking for SPI state, you must keep down the communication speed, taking into account the slowest code path in your polling loop. Another solution is to run the master so slow, that you can have a timer interrupt poll data, clock and slave-select lines often enough to catch the communication. But whatever you do, it will hurt. |
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 |