On Wed, Dec 24, 2008 at 2:24 AM, Peter Stuge peter@stuge.se wrote:
FENG Yu Ning wrote:
my spec would be: 3 mins - 8Mbit.
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?
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.
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.
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. 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.
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.
so I am curious to hear more about any testing that is done.
Yes. At last testing gives the result.
Most of the time budget will be eaten up by wait states.
Now my time is being eaten by repetitive 1 mail/day periods contacting product distributors (ftdi, Dediprog, etc.)
What to do then? One solution is to keep the FTDI module and add a microcontroller to do the actual SPI communication. ... Now the project isn't very simple anymore.. :)
If I go one step further adding support for other types of flash chips, I am actually starting another willem project :-)
yu ning