SPI clock stops at every 64 bytes

[maruel]

Hi!

Context: driving a strip of APA102 LEDs via SPI, so streaming over 600 byte at a time.

I just started using Sming and it's great. Using the develop branch, I've been able to drive APA-102 LEDs successfully albeit with small glitches. I've used the default SPI settings which is using a 4Mhz clock.

Looking at the SPI channel with an oscilloscope, I see that the SPI clock is off for 8µs after each 64 byte write, so it's effectively skipping a complete 32 bits sequence. I think the way to fix that is to alternate the use the two half of the buffer using SPI_USR_MOSI_HIGHPART to split the 16 uint32_t buffer into two parts of 8 uint32_t and alternate between the two sections as the hardware SPI signals it's done with the half.

Someone discussed that last year at: http://www.esp8266.com/viewtopic.php?p=15683&sid=40562f85d13afda9ef44ebce4529a8d0#p15683

I see there's PR #710 but it's not done doing it right so this will require another fix.

Yellow is SCLK, Cyan is MOSI, Magenta is SCLK at the end of the strip, Blue is MOSI at the end of the strip. Here's a overview:

A closer view:

[harry-boe]

Well the esp SPI bus is a tricky business.

You are right that there is a gap after each 64Bytes of data. The esp registers can hold 64 byte of data and once they are sent out by the SPI hardware the control goes back to the SPI "driver" that is going to prepare the registers with the next 64 bytes. Once tat is done the HW starts clocking out for the next 64 bytes (and in between you have the gap you mentioned). There is no way to deal around this as it needs some time to move the data into the registers by the driver software. So there should not be any data loss on the Master side. However i can imagine that some SPI cents do not like the fact that there is a communication GAP !!

I don't think that splitting the registers into half will change anything on that behaviour. The current api is designed to perform SPI transactions. So it does send and read at the same time and will not hand over to the SW driver before the job is done. To avoid or reduce the delay in between, you can change that behaviour to send out only. In that case you will get the control back to the SPI driver even before the data is fully sent out. In this case you can load the registers while the SPI HW is still sending. To avoid collisions you might split the registers in half so that on block is used by the HW while the other block is prepared by the software. In that case you can keep the "gap" in between on a absolute minimum for switching the banks for submission. The really sad story on that approach is that i'm not aware about a reliable way to figure out when the SPI hw has completed the submission. (I have not discovered any IRQ or other way to check for and transmission)

So if your SPI slave device can not deal with that type of submission you might consider sending byte by byte (pulling the Slave selector line for each byte) or go for software SPI. There are no limits for the SW SPI implementation as it's not using any registers. Depending on what method you use to drive the GPI port (GPIO API or direct writing the GPIO registers) you can reach SPI speed of up to 2Mhz with 40Mhz clock speed -> that might be the easies way in your case.

-> and just for completeness the pending PR has nothing to do with you observations here.

[maruel]

It's fairly probable this issue is just red herring, I'll close this issue for now and will revisit later.