Yet another idea of an SPI flash chip programmer

[FENG Yu Ning]

There are lots of flash programmer out there, but none of them (those
I know about) fits my requirement well.

I would like a programmer to be:

* able to program SPI flash chips,
 * not slow (program 512k bytes in 3 mins),
 * with a driver whose source code is available (or not difficult to write one),
 * simple, and
 * cheap.

There is one that almost does the job,

http://www.malinov.com/Home/sergeys-projects/spi-flash-programmer

but
[0] would it be very slow?

Recently I find a chip FT2232x

http://www.ftdichip.com/Products/FT2232C.htm

It seems that the chip's IO could be configured to work in bit-bang
mode and thus able to implement as an SPI I/F.

[1] I think it is easy to build a prototype programmer using this chip. Is it?
[2] Is the programmer going to meet my requirement?

yu ning

[Joseph Smith]

On Mon, 22 Dec 2008 19:45:00 +0800, "FENG Yu Ning"
 wrote:
> There are lots of flash programmer out there, but none of them (those
> I know about) fits my requirement well.
>
> I would like a programmer to be:
> able to program SPI flash chips,
> not slow (program 512k bytes in 3 mins),
> with a driver whose source code is available (or not difficult to

write
> one),
> simple, and
> cheap.
>
> There is one that almost does the job,
>
> http://www.malinov.com/Home/sergeys-projects/spi-flash-programmer
>
> but
> [0] would it be very slow?
>
> Recently I find a chip FT2232x
>
> http://www.ftdichip.com/Products/FT2232C.htm
>
> It seems that the chip's IO could be configured to work in bit-bang
> mode and thus able to implement as an SPI I/F.
>
> [1] I think it is easy to build a prototype programmer using this chip.

Is
> it?
> [2] Is the programmer going to meet my requirement?

Wow, If that can be used for SPI than the Paraflasher can definitely be
used for SPI. It would just require software to support it :-)

[Carl-Daniel Hailfinger]

On 22.12.2008 15:13, Joseph Smith wrote:
> On Mon, 22 Dec 2008 19:45:00 +0800, "FENG Yu Ning"
>  wrote:
> > There are lots of flash programmer out there, but none of them (those
> > I know about) fits my requirement well.
> >
> > I would like a programmer to be:
> > able to program SPI flash chips,
> > not slow (program 512k bytes in 3 mins),
> > with a driver whose source code is available (or not difficult to
>
> write
> > one),
> > simple, and
> > cheap.
> >
> > There is one that almost does the job,
> >
> > http://www.malinov.com/Home/sergeys-projects/spi-flash-programmer
> >
> > but
> > [0] would it be very slow?
> >
> > Recently I find a chip FT2232x
> >
> > http://www.ftdichip.com/Products/FT2232C.htm
> >
> > It seems that the chip's IO could be configured to work in bit-bang
> > mode and thus able to implement as an SPI I/F.
> >
> > [1] I think it is easy to build a prototype programmer using this chip.
>
> Is
> > it?
> > [2] Is the programmer going to meet my requirement?
>
> Wow, If that can be used for SPI than the Paraflasher can definitely be
> used for SPI. It would just require software to support it :-)

The FT2232D can speak SPI directly, no need for bitbanging.

Regards,
Carl-Daniel

[Tom Sylla]

This will definitely work, a couple of years ago, we researched this
exact setup. Our plan was to put headers on the motherboards were we
deisnging, to have an easy de-bricking mechanism. A co-worker wrote a
windows SPI flasher in a day or so. I have seen that exact device used
to program SPI ROMs, as well as master JTAG, and program Altera FPGAs
(they have a generic bit-bang mode too). It works quite well.

I think I have sent these to the list before, but DLP Design makes
pretty cheap little adapter boards ($20-40), including one for the
2232 series:

http://www.dlpdesign.com/usb/2232m.shtml

That with a protoboard and an appropriate socket is all you need for a
SPI programmer. If you have a SPI programming socket on your
motherboard, it is even easier. It should be pretty fast too.

I am actually making an LPC ROM reader/writer from a FT245 (similar to
paraflasher, but using USB instead of parallel) Both windows and linux
support for the devices is very good.

On Mon, Dec 22, 2008 at 6:45 AM, FENG Yu Ning  wrote:
> There are lots of flash programmer out there, but none of them (those
> I know about) fits my requirement well.
>
> I would like a programmer to be:
> able to program SPI flash chips,
> not slow (program 512k bytes in 3 mins),
> with a driver whose source code is available (or not difficult to write one),
> simple, and
> cheap.
>
> There is one that almost does the job,
>
> http://www.malinov.com/Home/sergeys-projects/spi-flash-programmer
>
> but
> [0] would it be very slow?
>
> Recently I find a chip FT2232x
>
> http://www.ftdichip.com/Products/FT2232C.htm
>
> It seems that the chip's IO could be configured to work in bit-bang
> mode and thus able to implement as an SPI I/F.
>
> [1] I think it is easy to build a prototype programmer using this chip. Is it?
> [2] Is the programmer going to meet my requirement?
>
> yu ning

[Joseph Smith]

> I am actually making an LPC ROM reader/writer from a FT245 (similar to
> paraflasher, but using USB instead of parallel) Both windows and linux
> support for the devices is very good.

Very Cool, I would be quite interested in seeing how you do this.

[FENG Yu Ning]

On Mon, Dec 22, 2008 at 10:23 PM, Tom Sylla  wrote:
> This will definitely work, a couple of years ago, we researched this
> exact setup. Our plan was to put headers on the motherboards were we
> deisnging, to have an easy de-bricking mechanism. A co-worker wrote a
> windows SPI flasher in a day or so. I have seen that exact device used
> to program SPI ROMs, as well as master JTAG, and program Altera FPGAs
> (they have a generic bit-bang mode too). It works quite well.

Thanks for confirming.
> I think I have sent these to the list before, but DLP Design makes
> pretty cheap little adapter boards ($20-40), including one for the
> 2232 series:
>
> http://www.dlpdesign.com/usb/2232m.shtml

I must have over looked it. After reading your mail, I browsed ftdi's
site again and found it there too. The module seems convenient to use.
I am contacting a local ftdi distributor at the moment.
> That with a protoboard and an appropriate socket is all you need for a
> SPI programmer. If you have a SPI programming socket on your
> motherboard, it is even easier. It should be pretty fast too.

Any one know about this?

http://www.wieson.com/product_show_lst.php?PID=858&TypeName=Connectors&a...

I think it is very useful for soldered SPI flashes.

yu ning

[Peter Stuge]

FENG Yu Ning wrote:
> I would like a programmer to be:
> able to program SPI flash chips,
> not slow (program 512k bytes in 3 mins),

Can you specify your speed requirement? What would be acceptable?
It's easier to calculate backwards then.
> with a driver whose source code is available (or not difficult
> to write one),
> simple, and
> cheap.
>
> There is one that almost does the job,
>
> http://www.malinov.com/Home/sergeys-projects/spi-flash-programmer
>
> but
> [0] would it be very slow?

Yes. It bitbangs SPI on the parallell port, which doesn't have very
fast output drivers and is connected to the CPU through a slow bus.

I thought a little bit more about the numbers I provided for doing
this and depending on which opcodes are supported by the flash chip,
bitbanging SPI could actually be faster than LPC, so 256kbyte would
take maybe 3-4 minutes instead of the 5 minutes needed by LPC.
> Recently I find a chip FT2232x
>
> http://www.ftdichip.com/Products/FT2232C.htm
>
> It seems that the chip's IO could be configured to work in bit-bang
> mode and thus able to implement as an SPI I/F.
>
> [1] I think it is easy to build a prototype programmer using this
> chip. Is it?

The chip is surface mount with somewhat fine pitch (pins close
together) but you can find ready-made modules with the chip that will
make it very easy to build a programmer. FTDI make some modules, and
there are also third-party modules. Modules using FT232 seem to be
more common, but I'm not sure if they have the bitbanging capability.
> [2] Is the programmer going to meet my requirement?

It is an interesting question. USB has significantly more overhead
per bit to be banged, but the bus is also much faster. It may
actually be much faster.

To get the highest performance the SPI protocol has to be implemented
in hardware. I would recommend using a microcontroller with a fast
SPI master peripheral. I think 16MHz SPI clock is safe for all flash
chips, or is it 33MHz, but some chips can even run up to 75MHz.

To drive the flash chip at those high speed will require the design
to be more complicated, especially if you first need to download data
from a PC somehow. Then you need 128 Mbits of RAM too, and a RAM
controller..

//Peter

[FENG Yu Ning]

On Mon, Dec 22, 2008 at 10:42 PM, Peter Stuge  wrote:
> FENG Yu Ning wrote:
> > I would like a programmer to be:
> > able to program SPI flash chips,
> > not slow (program 512k bytes in 3 mins),
>
> Can you specify your speed requirement? What would be acceptable?
> It's easier to calculate backwards then.

I do not have an accurate speed specification in my mind. I read in
the list recently that some programmer can take 7 mins to program a
chip. I just don't want to wait that long.
> > with a driver whose source code is available (or not difficult
> > to write one),
> > simple, and
> > cheap.
> >
> > There is one that almost does the job,
> >
> > http://www.malinov.com/Home/sergeys-projects/spi-flash-programmer
> >
> > but
> > [0] would it be very slow?
>
> Yes. It bitbangs SPI on the parallell port, which doesn't have very
> fast output drivers and is connected to the CPU through a slow bus.
>
> I thought a little bit more about the numbers I provided for doing
> this and depending on which opcodes are supported by the flash chip,
> bitbanging SPI could actually be faster than LPC, so 256kbyte would
> take maybe 3-4 minutes instead of the 5 minutes needed by LPC.

Hmm.. So programming a 512k byte chip still need quite some patience.
> The chip is surface mount with somewhat fine pitch (pins close
> together) but you can find ready-made modules with the chip that will
> make it very easy to build a programmer. FTDI make some modules, and
> there are also third-party modules. Modules using FT232 seem to be
> more common, but I'm not sure if they have the bitbanging capability.

Yes. Using modules will save me some effort.
> > [2] Is the programmer going to meet my requirement?
>
> It is an interesting question. USB has significantly more overhead
> per bit to be banged, but the bus is also much faster. It may
> actually be much faster.

Let me try. If I succeed with this idea, I will post its performance
to the list.
> To get the highest performance the SPI protocol has to be implemented
> in hardware.

Yes, I kept thinking about different ways of chip programming, and got
this conclusion also.
> I would recommend using a microcontroller with a fast
> SPI master peripheral. I think 16MHz SPI clock is safe for all flash
> chips, or is it 33MHz, but some chips can even run up to 75MHz.
>
> To drive the flash chip at those high speed will require the design
> to be more complicated, especially if you first need to download data
> from a PC somehow. Then you need 128 Mbits of RAM too, and a RAM
> controller..

I also came to something similar. I knew I needed storage for
buffering, easy to operate, and fast. However, going further is not so
easy. That's why I looked for an IC.

Thanks for your information. It helps.

yu ning

[Peter Stuge]

FENG Yu Ning wrote:
> Any one know about this?
>
> http://www.wieson.com/product_show_lst.php?PID=858&TypeName=Connectors&a...
>
> I think it is very useful for soldered SPI flashes.

Sure thing. Good work finding that! :) I wonder how easy these are to
order..

FENG Yu Ning wrote:
> > Can you specify your speed requirement? What would be acceptable?
> > It's easier to calculate backwards then.
>
> I do not have an accurate speed specification in my mind. I read in
> the list recently that some programmer can take 7 mins to program a
> chip. I just don't want to wait that long.

I know that 1 second would be ideal, but what would be good enough?

30s? 1min? 2min? 3min?

And for which flash chip size? That is also important, because double
the size will double the time. :) 4Mbit vs. 16Mbit = 4x the time.
> > > [2] Is the programmer going to meet my requirement?
> >
> > It is an interesting question. USB has significantly more
> > overhead per bit to be banged, but the bus is also much faster.
> > It may actually be much faster.
>
> Let me try. If I succeed with this idea, I will post its
> performance to the list.

Please do. The 2232 MPSSE mode's maximum SPI clock is 6MHz, but the
problem is with turnaround time between each sequence of bytes that
are read or written. SST25VF040 can e.g. only write two bytes at a
time in AAI mode and will require status to be input before the next
two bytes can be written so will really exercise the USB
communication. Depending on their USB descriptors, which I don't
think fit this use very well, this need for status reads can slow the
process down quite a lot.

Stream reading should be nice and fast however.
> > especially if you first need to download data from a PC somehow.
> > Then you need 128 Mbits of RAM too, and a RAM controller..
>
> I also came to something similar. I knew I needed storage for
> buffering, easy to operate, and fast. However, going further is not
> so easy. That's why I looked for an IC.

Another option is to download the data to be flashed "just in time"
so that no buffering is needed. But then the PC communication link
needs more care. I think that is easier than adding RAM however.
> Thanks for your information. It helps.

I'm looking forward to hearing more about this. When your programmer
is finished we should look closer at how to make plugins for
flashrom.

//Peter

[FENG Yu Ning]

On Tue, Dec 23, 2008 at 10:40 PM, Peter Stuge  wrote:
> I wonder how easy these are to order..

I did not post this because I felt it was like advertising, but here it is:

http://www.dediprog.com/SPI-flash-accessories/SPI-Flash-Socket-8pin

I have contacted with the company and I am told the MOQ is 10.
Shipping fee is high except for Taiwan.
> I know that 1 second would be ideal, but what would be good enough?
>
> 30s? 1min? 2min? 3min?
>
> And for which flash chip size? That is also important, because double
> the size will double the time. :) 4Mbit vs. 16Mbit = 4x the time.

Could the words, between parentheses after "not slow" in my original
post, serve as a specification of that kind?
I think what I meant in the original post is I do not want to wait for
more than 3 mins for any chip. Of course that is not a proper spec.
Since 8Mbit chips are widely used these days (is it?), my spec would
be: 3 mins - 8Mbit.
> Please do. The 2232 MPSSE mode's maximum SPI clock is 6MHz, but the
> problem is with turnaround time between each sequence of bytes that
> are read or written. ..., this need for status reads can slow the
> process down quite a lot.

I did not realize that. Let's see.
> Another option is to download the data to be flashed "just in time"
> so that no buffering is needed. But then the PC communication link
> needs more care. I think that is easier than adding RAM however.

After all, a (not so) fast GPIO peripheral interface, with a simple
(stupid) protocol, solves the problem. The philosophy of PC decides we
do not have things of that kind.

Serial and parallel ports are simple, but they are a bit slow.
  USB is fast, but the protocol is complicated (for SPI programming
application).
> I'm looking forward to hearing more about this. When your programmer
> is finished we should look closer at how to make plugins for
> flashrom.

Sure. I am looking forward to coding again.

yu ning

[Joseph Smith]

> > I'm looking forward to hearing more about this. When your programmer
> > is finished we should look closer at how to make plugins for
> > flashrom.
>
> Sure. I am looking forward to coding again.

With that said I think we may want to collaborate on a parallel port
standard driver that can be used for multiple devices. This would also
probibly help out with duplicated code bloating flashrom.

[Peter Stuge]

Joseph Smith wrote:
> > > I'm looking forward to hearing more about this. When your
> > > programmer is finished we should look closer at how to make
> > > plugins for flashrom.
> >
> > Sure. I am looking forward to coding again.
>
> With that said I think we may want to collaborate on a parallel
> port standard driver that can be used for multiple devices.

Sounds like a good idea.
> This would also probibly help out with duplicated code bloating
> flashrom.

My idea for flashrom is to have plugins be separate programs. That
way there is a very clear driver abstraction, and everyone can do
what they like. Of course, if you make a small libparport then it can
be used by lots of drivers.

//Peter

[Peter Stuge]

FENG Yu Ning wrote:
> > I wonder how easy these are to order..
>
> I did not post this because I felt it was like advertising,

I encourage vendor information on the list as long as the products
haven't been mentioned before and are relevant to coreboot. Even
advertising (your own products and services) should be OK now and
then, again as long as they are relevant for coreboot. I've done it
when I've had some significant news.
> but here it is:
>
> http://www.dediprog.com/SPI-flash-accessories/SPI-Flash-Socket-8pin
>
> I have contacted with the company and I am told the MOQ is 10.
> Shipping fee is high except for Taiwan.

Nice! I sent an inquiry to the manufacturer about a sales rep in
Europe, we'll see what reply I get.
> > And for which flash chip size? That is also important, because
> > double the size will double the time. :) 4Mbit vs. 16Mbit = 4x
> > the time.
>
> Could the words, between parentheses after "not slow" in my
> original post, serve as a specification of that kind?

Unfortunately "not slow" is difficult to use in calculations. :)
> I think what I meant in the original post is I do not want to wait
> for more than 3 mins for any chip. Of course that is not a proper
> spec. Since 8Mbit chips are widely used these days (is it?), 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.

(Conservatively assuming read/verify needs the other 30s.)

The first two bytes require six bytes * 8 clocks = 48 clocks.
All other two bytes require three bytes * 8 clocks = 24 clocks.

So the first two bytes need 24 extra clocks, and 8 more are needed at
the end for the WRDI command.

8388608 / 2 * 24 = 100663296 + 32 = 100663328 total clocks

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

Because of the high number of waits needed and because of the
"distance" in hardware between the PC CPU doing the waiting and the
SPI output pins on the USB module, this time can increase a lot.

Data will be streamed to the FTDI and not transferred all at once and
stored in RAM closer to the flash chip, so USB performance must also
be considered.

FT2232D is a full speed device, the minimum unit in full speed USB
scheduling is a frame, and a frame is scheduled every 1 ms.

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. :)

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.

I am not sure if the FTDI chips or even the Linux USB stack allow
this fine control over the USB communication, so I am curious to hear
more about any testing that is done.

Most of the time budget will be eaten up by wait states. If the USB
communication can be optimized so that overhead costs only 3x
(which I think is way too optimistic still) that means ~125 seconds
of waiting, leaving 25 seconds for clocking out write commands:

100663328 / 25 = 4026533 clocks per second.

The FTDI can do 6MHz, so there is a little bit of margin. But again,
I think that 30 us timing precision will be difficult to reach
reliably.
> > Please do. The 2232 MPSSE mode's maximum SPI clock is 6MHz, but the
> > problem is with turnaround time between each sequence of bytes that
> > are read or written. ..., this need for status reads can slow the
> > process down quite a lot.
>
> I did not realize that. Let's see.

It will be very interesting.
> > Another option is to download the data to be flashed "just in time"
> > so that no buffering is needed. But then the PC communication link
> > needs more care. I think that is easier than adding RAM however.
>
> After all, a (not so) fast GPIO peripheral interface, with a simple
> (stupid) protocol, solves the problem. The philosophy of PC decides
> we do not have things of that kind.
>
> Serial and parallel ports are simple, but they are a bit slow.
> USB is fast, but the protocol is complicated (for SPI programming
> application).

USB can be quite fast in many applications, but it is not at all
suitable for intensive bi-directional communication with fast timing.

Also, products like the FTDI chips simplify away many details of USB
that can be critical to get adequate performance.

What to do then? One solution is to keep the FTDI module and add a
microcontroller to do the actual SPI communication. The FTDI is used
only to download data 16, 32 or 64 bytes at a time, enough to keep
the microcontroller busy with writing to the flash and polling for
flash ready, and that way the micro doesn't need external RAM.

That will certainly allow 8Mbit to be written in less than a few
minutes and any microcontroller with SPI can be used.

But, then the software needs much more work, because the
microcontroller must know how to communicate with every flash chip.

It would be very neat to look at most available flash chip data
sheets and create a configuration format that allows the PC software
to instruct the microcontroller which sequences to use.

The primitives write byte, wait usec and read byte would be enough
for starters.

Now the project isn't very simple anymore.. :)

//Peter

[FENG Yu Ning]

On Wed, Dec 24, 2008 at 2:24 AM, Peter Stuge  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

[Peter Stuge]

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

[FENG Yu Ning]

On Wed, Dec 24, 2008 at 2:24 AM, Peter Stuge  wrote:
> FENG Yu Ning wrote:
> > but here it is:
> >
> > http://www.dediprog.com/SPI-flash-accessories/SPI-Flash-Socket-8pin
> >
> > I have contacted with the company and I am told the MOQ is 10.
> > Shipping fee is high except for Taiwan.
>
> Nice! I sent an inquiry to the manufacturer about a sales rep in
> Europe, we'll see what reply I get.

Unfortunately some people have reported that the socket is not quite
durable, and one comes up with a solution to avoid desoldering:

http://www.samedisk.com/cht/forum/viewtopic.php?t=28

The web pages are in tranditional Chinese, but pictures also give much
information.

yu ning