Re: [Xc3sprog-users] SPI programming - delayed reads

[Álvaro L. <alv...@al...>]

Uwe Bonnes wrote:
> Looking at the protocoll in S71296_05.pdf, I think you won't gain
> much. Polling in the 10 us timeframe required for the Byte programming time
> (TBP) is always slow if USB round trips are involved.
> 
> Combining AAI/ trigger Read software status/ read software status to one
> single USB transfer will probably always return "not ready" as the 10 us TBP
> wait time has not yet elapsed and so you have to go another USB round trip
> for the next poll cycle. 
> 
> What about adding the hardware poll mechanism to the BSCAN-SPI core?

That would add much complexity to the core, I'd prefer to avoid that (of course a specific bscan part can be provided).

> Or perhaps you add dummy SCK cycles with CE high to fullfill the "wait TBP"
> requirement? No need to poll then.

This is indeed interesting. The only problem I see right now is that there seems not to be a way to figure out TCK frequency.
>
> Remember that every POLL needs at least 125 us USB round trip (to my
> experience).  Transferring big blocks of data ist the only valid approach to
> speed up things. Doing ping pong between FTDI and PC is slow.

You are absolutely right.

> Or did you already implement your approch with the FTDI and achieve decent
> average byte programming times?

I did implement with non-busy check, meaning no wait for tBP (works well for low speeds), and I can erase+program+verify in about 6 seconds (increasing the FTDI
JTAG frequency to its maximum). Other approaches (except for TCK one, which adds about 2 seconds) are painfully slow.

While doing so, I have found some bugs on read and verify which I'll address later on this mailing list.

The current implementation is an exception to the rule, like AT45 parts. I wonder if it would be best to have a separate class, with override-able methods, and
implement the generic case on base class, and have AT45 and SST derive from it and implement the specifics on their classes.

Best,
Álvaro