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
11/01/11 01:05
Read: 423 times
Sweden


 
#184497 - Still gives puny transfer rate with significant limitations
Responding to: Konstantinos L. Angelis's previous message
Konstantinos L. Angelis said:
it is only attainable if EVERYTHING ELSE (ISRs, main, ...) is stopped. for a while !

Let's say that using burst mode for 1ms every 50ms. Then the slave system is stopped for 1ms and free for operations the other 49ms, that yields to 98% free for normal (not SPI) activities. The master system gives the rate of the slave should be used to accept/respond to commands.


But that is not really much different from instead dropping the baudrate with a factor 50 - your 100kbit/s loop will still melt down to <= 2kbit/s of actual data. But with lots of limitations and assumptions and lots of bruising involved.

And that burst mode still requires the master to hold the slave select enough time before the data transfer starts, that the slave have time to react.

If the slave does that burst inside a pin-change interrupt, then it will lock up all other interrupts (timers, UART, ...) for that millisecond. And the full ms may not transfer data - some of the time must be reserved for reacting to the slave select.

If that optimized assembler code is instead called from the main loop, then that main loop must guarantee better than 500us loop time always, to be able to get 500us of slave communication during that ms.

Whatever happens, the master must activate slave-select in good time. And the slave must do an best effort to detect it and then start the busy loop while waiting for real data. If the slave has a 100us jitter time to detect the slave select, then the master must be prepared to always hold slave select at least 150us before start of data. And the slave must busy-loop for 50..150us before any data will start to arrive.

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