2020-06-10 07:26 PM - edited 2023-11-20 09:30 AM
Hi guys,
i am using the QuadSPI periphery to interface with a FPGA. I am in need of raw throughput with alternating write and read cycles of some number of bytes. I am just concept-prooving right now.
Since QUADSPI->CCR is not allowed to be modified when BUSY==1 the busy flag effectively limits the command rate - which is useful since i obviously need to wait to finish a a command before sending the next one.
My configuration is:
Now, unfortunately the BUSY flag is rather lame and it takes exactly 6-7 clocks after CS rises that the BUSY flag clears. That is really **** ** the achievable command rate!
With 6-7 clocks, i mean periphery-clocks after the prescaler. (@1MHz SPI clock, the BUSY-signal is 1 for 6µs after CS rises. If 10MHz is used, then its 0.6us)
What i dont understand is, that this behavior makes the minimum CS-high setting kind of useless. (i never achieve a scenario where CS is less than 6 cycles high in-between commands)
This holds true for consecutive reads, consecutive writes, and alternating read-write.
What could go wrong ??
This is my example code. Not using the library, but my code hopefully reads kind of intuitively...
Measured though my Debug-GPIO: 16.7µs from Command start to BUSY=0
Chip select Low for 11µs
Give me a faster BUSY, please :(
BTW: i also get the same behavior if i configure the QSPI differently:
== Same timing(-problems)
thanks
2020-07-16 07:21 AM
One of the other potential pitfalls of using the QSPI/FMC external interfaces for things like FIFO's or state-machines is that the core/peripheral can do funny things with unaligned access, bursts access, speculative reads, and reads which are abandoned and retried.
2020-07-16 07:35 AM
Those "funny things" is what made go and look at the CS and clock.
I would never imagine that clock could start before CS goes down....