Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
Per Westermark
10/31/11 10:52
Read: 480 times
Sweden


 
#184489 - Software master trivial - slave is not
Responding to: Erik Malund's previous message
It is trivial to write a SPI software master. There, that 100kbit/s+ optimized assembler can be run with zero problems. It doesn't matter if there is an interrupt. The clocking is synchronous, so everything will just slow down slightly without affecting the functionality.

And the master don't need to worry about the time between slave-select and first clock/data bit.

An important issue is that many (probably even most) hw SPI masters don't allow configurable setup time for the slave-select signal. That signal activates maybe one half data bit before the first toggle of clock or data. So for a 100kbit/s transfer rate, it might activate 5us ahead. A software slave must then detect this, deactivate interrupts and enter the loop and get the first sample of data + clock within less than 5us. A supper-loop design is not fast enough. Even an external-interrupt ISR may will not be fast enough if there is any single part of the program that disables interrupts around a critical section. Just handling another ISR when the slave select line toggles has a good chance of failing the communication.

In the end, a software-only SPI slave will require a manually driven slave-select line with extra time added.
And it will not allow a software-only master to run any optimized assember unless the master has a slower processor. Obviously a hw master must not run at full speed - and may not allow multi-byte transfers using FIFO or similar just because of problems with driving the slave-select.

The interesting thing with a sw SPI slave is that it sounds trivial, since the SPI protocol is trivial.

The even more interesting thing is how hard it is to get to work at any reasonable speed, while maintaining any other functionality in the slave.

SPI is basically a trivial shift register with enable and clock. It sounds trivial. But what is trivial for real physical hardware is pure hell in software. 100kbit/s means that the master is toggling signals at a very high speed, without any feedback to know if the slave is keeping up or not. If slave select is toggled for each word, then one read error kills one word. If slave select is toggled for a full packet of multiple words, then one read error means that the rest of the data may be shifted one bit resulting in pure garbage being received and/or sent out.

List of 20 messages in thread
TopicAuthorDate
SPI Slave in 89S52      Alexandre Marques      10/30/11 13:35      
   Get real processor      Per Westermark      10/30/11 14:29      
      Topic Author Date      Alexandre Marques      10/30/11 14:46      
         Big problem      Per Westermark      10/30/11 16:01      
         Look for a different model      David Prentice      10/30/11 18:31      
         Try 8051 BASCOM      KONSTANTINOS L. ANGELIS      10/31/11 05:37      
            at what speed      Erik Malund      10/31/11 07:06      
               Interpreters have an easier life.      Per Westermark      10/31/11 08:54      
               Soft SPI speed      KONSTANTINOS L. ANGELIS      10/31/11 09:31      
                  But how to combine that loop with a real program?      Per Westermark      10/31/11 09:44      
                     and more      Erik Malund      10/31/11 09:51      
                        Software master trivial - slave is not      Per Westermark      10/31/11 10:52      
                           SPI analysis is made, results?      KONSTANTINOS L. ANGELIS      10/31/11 14:43      
                              There _may_ be a solution - but maybe not acceptable      Per Westermark      10/31/11 16:05      
                  sure, and so what?      Erik Malund      10/31/11 09:47      
                     SPI at 100Kbps      KONSTANTINOS L. ANGELIS      10/31/11 16:51      
                        Still gives puny transfer rate with significant limitations      Per Westermark      11/01/11 01:05      
                           the answer is      Erik Malund      11/01/11 06:37      
   Fully Interlocked Handshaking.      Michael Karas      11/01/11 08:01      
      Quite common      Per Westermark      11/01/11 08:52      

Back to Subject List