FENG Yu Ning wrote:
Ok. That's a good approximate goal. Let's see how to write SST25VF080B in 2.5 min = 150 s. ... 8388608 / 2 * 24 = 100663296 + 32 = 100663328 total clocks
SST25VF080B has a size of 8M bits. Therefore I think the dividend (size in bytes) should be 1048576 instead of 8388608?
Yes certainly! Thanks for catching that! It means there is a lot more margin.
However, that affects little on the total time, compared to USB protocol overhead, or even Tbp.
For end-of-write detection I think it is easiest to simply wait Tbp (10us) after each pair of bytes. Using this method, the time spent waiting will be a minimum of:
8388608 / 2 * .00001 = 41.94304 seconds
Here the waiting time would be approximately 5 seconds.
Which is a huge improvement, because 500s would be more bearable than 4200s, just not very nice.
Assuming that there is no other activity on the USB, and that only one transfer is made per frame, every wait state will be a minimum of 1 ms, instead of 10 us, causing a 100x slowdown. About 4200s = 70 min would be spent waiting for scheduling. :)
We really should prevent that from happening then.
Yes, the problem is that I do not think any kernel API allows actual control of how multiple transfers are packed together into frames.
There is room for more than one transfer in each frame however, so if care is taken, dummy transfers can be inserted (should be commands that communicate with the FTDI only, maybe reading some status register) between the three bytes going out to SPI.
We may not need a dummy transfer to wait. Let's wait on a lower layer. The FT2232D datasheet suggest that we need to control output to the CE# pin (of the SPI flash chip) manually. If the flash chip does not react to the clock signal when CE# is high, we can simply insert some control bytes doing dummy read.
Yes, the CE# pin has to be controlled separately from the FTDI SPI stuff. One idea is to use a GPIO pin on the FTDI for that, which will require at least one USB transfer. Maybe it will be enough to create the delay, but I suspect it is best to add another transfer before selecting the chip again.
We can wait for an exact time period because we decides how many 8x clocks to wait for. Then all can be done in one transfer.
The challenge will be to fit those USB transfers into frames to get the minimum neccessary delays but still not have too long delays.
I am not sure if the FTDI chips or even the Linux USB stack allow this fine control over the USB communication,
If the above idea works, all we need is proper assembly of control bytes, which are data from the view of USB protocol.
The USB API is packetized, not a stream of bytes. This frame stuff I talked about is what happens on the wire, but it is all handled by the Host Controller hardware, and maybe the host controller driver in the kernel - and I know for sure that the kernel API doesn't allow any control over these lowlevel details.
I think the best test is to queue several URBs (USB Request Block) doing SPI output, GPIO control and SPI input with the FTDI at once, and see what happens on the output pins.
Now my time is being eaten by repetitive 1 mail/day periods contacting product distributors (ftdi, Dediprog, etc.)
Maybe you could even find the FTDI module at a local electronics store?
//Peter