SPI Timing

Use this forum to chat about hardware specific topics for the ESP8266 (peripherals, memory, clocks, JTAG, programming)
 Reply

User avatar

SPI Timing

By gschulz
- Tue Mar 14, 2017 6:10 am #63670 Why is there a gap between the bytes sent on the spy port? This is not asynchronous, so there doesn't need to be a gap to indicate the beginning of each byte. The port itself is capable of up to 32 bits per word. My application needs a constant, uninterrupted stream of bits. This seams to be coming from the SPI hardware interface, since the gap is proportional to the frequency:

SPI_1KHz.png
shows 8 bits of data in 9 bits of time at 1KHz

SPI_100KHz.png
shows 8 bits of data in 9 bits of time at 100KHz

For my application, I need to send a minimum of 32 bits as a continuous stream. I can deal with the delays after that. It would be nice to feed the SPI port from a string, as it currently works. Perhaps it could fill the 32 bit word with 4 byte chunks from the string. Any ideas?
You do not have the required permissions to view the files attached to this post.
User avatar

Re: SPI Timing

By RichardS
- Tue Mar 14, 2017 1:26 pm #63686 It takes time to load the next value... simple. It either needs to wait till it sent to send the next or send one and come back and make sure its sent before the next send.....

The only way is DMA and dual buffers, and even then you might have a gap between buffers....

RichardS
User avatar

Re: SPI Timing

By gschulz
- Wed Mar 15, 2017 12:59 am #63710 Thank you for the feed back. I have been doing some additional experimenting and have come up with more details. Firstly, I'm a bit confused about this forum; I initially was refereeing to the SPI service in ESP8266 BASIC, but after searching for a LUA forum, I ended up at the same place. I have been very impressed with the performance of the ESP8266 BASIC, but the documentation is next to non-existent or poorly written (reminds me of Z-Wave). The SPI service on ESP8266 BASIC only does 8 bit single byte transfers. LUA will do 512 bit transfers, which works perfect for my app, except it seems to hog all the bandwidth while running. I set up a 512 bit transaction that takes about 33mS to send. I also set up a 34mS timer to resend the transaction. It works great, until I attempt to access the device through WiFi, it immediately crashes. I can access the WiFi separately with no problem (even multiple simultaneous accesses) and I can run the SPI loop separately, but not together. I thought this is supposed to be a hardware SPI solution. How can I get the SPI loop to run in the background and not interfere with the WiFi tasks?
 Reply
Return to Hardware Specific