ESP8266 Community Forum

- Sat Apr 25, 2015 9:05 am #15607 First of all, thanks for answering!

Yeah... I screwed up with the CS pin... the pin header had a bad joint so "there was nothing" on the pinheader... I checked at the module "pin/contact" and there it was! Damn!

And the CS is showing just "right" - it goes down (active) when transfer starts (no delays) and returns to high when the SPICLK stops.

Anyway, I'm using a esp-03 or 04 (the one without antenna) and all "tied" (for boot, flash...) pins are "pulled up or down" with resistors, no direct VCC/GND connections.

I understand the issue of the time needed to fill the fifo and that its locked while in use, but if you look at the code, the fifo is filled just once. The only thing done once the transfer is done (when the SPI_USR bit goes low) is a transfer restart (SPI_USR is set again) - nothing else is touched and it still needs a LOT of time to start sending data out.
There must be something blocking/slowings this down...

I know in normal SPI this should not be an issue but its not used as "normal spi" and the gaps in data/clk streams makes a lot of difference:


Another strange thing I noticed is some strange "code slowdown" when filling the spi fifo.
To be as fast as possible I went the asm route... and use a sequence of 16 l32i / s32i pairs to move data in fifo.
The strange thing is that 8 pairs need 8 cpu clk cycles, 12 pairs need 20 cycles and 16 pairs need 64 cycles!!! This is measured with the CCOUNT (cycle count) register.

Seems like some "cache miss" or something... but all references states there is no cacse in the cpu. I could understand that a write to a periph register could be slower (as the gpios are) but that should be constant and not changing in such "growing" way.

Any idea why is this happening or, better, how to avoid that slowdown?

Best regards

- Sun Apr 26, 2015 5:49 am #15668

Code: Select all      SET_PERI_REG_MASK(SPI_USER(ESP_SPI_HSPI), SPI_CS_SETUP|SPI_CS_HOLD);

You have CS Setup & Hold enabled. This will pull the CS line low for a few uS before writing out data, and hold it low for a few uS after data is finished. This is probably why you have a few uS of delay before you see the next lot of data appear!

http://d.av.id.au

- Sun Apr 26, 2015 8:43 am #15682 Yeah... not really.
I did a gazillion tests with different setups.... including clearing all bits in SPI_USER and setting only SPI_MOSI (to have just the data part sent out) - the result is the same - a rather long gap in the "stream".

Any hint on the other problem mentioned (the slowing down of the writes to spi fifo)?

regards

- Sun Apr 26, 2015 9:00 am #15683 You could try writing 256bits at a time instead using the SPI_USR_MOSI_HIGHPART bit in SPI_USER.

Pseduo code:

Write 256bits into SPI_W0 through SPI_W7;
Send SPI data;

Write next 256bits into SPI_W8 through SPI_W15;

Wait for SPI ready;

Set SPI_USR_MOSI_HIGHPART in SPI_USER;
Send SPI data; // from SPI_W8 to SPI_W15

Write next 256bits into SPI_W0 through SPI_W7;

Wait for SPI ready;

Clear SPI_USR_MOSI_HIGHPART in SPI_USER;
Send SPI data; //from SPI_W0 through SPI_W7

then repeat again with next 256bits and so on.

This way, the only idle time between one SPI transfer finishing, and the next starting, is changing the SPI_USER register and sending the spi start command. Each time you just swap from sending data from the LowPart or the HighPart of SPI_Wx which is preloaded with data.

You might even be able to change the SPI_Wx data or the SPI_USER register while it's running without affecting the current transfer. I'm not sure if it clocks in that data to a copy register before starting the transfer. Needs more investigation. Should be an easy test - I'll try it tomorrow.

At the moment I'm getting my head around all the Wifi/TCP commands espressif provides in their SDK for the next part of my project.

http://d.av.id.au