On Mon, Jul 11, 2011 at 10:33 AM, brunosmmm <[email protected]> wrote: > Well, i've seen enough examples and implementations of SPI communications > using FT2232H / libftdi. > The problem is that the most common approach i've seen in all these example > / implementations is as follows: one has a read / write function to which is > passed the data to write, then it asserts CS / writes the command to the > device. After this, it performs a bulk read with libftdi, obtaining the data > and only after this CS is de-asserted. That makes no sense for me, as this > approach wastes a LOT of time waiting for the data to arrive (latency timer > and bulk transfers).
That is okay, right? The key is to pack as many commands as possible together to minimize the latency. > If we have an internal buffer on the chip, why use this approach? So, I > started modifying this a little so that only a sequence of commands which > include write/read is passed to the 2232h, and after a while I would go and > collect the contents of the chip's buffer. > > I have to do this, as the task i'm trying to do is collect a few (3) bytes > at somewhat regular intervals from a SPI slave, and as the collection speeds > rise, it becomes impractical to use the "standard" approach i mentioned. > > Well, the problem is that i seem to be getting a lot of trash along with the > data when i do a full buffer read. I have no idea why, as i never execute > any other read commands that could make the chip put data into its buffer. Probably those are the two bytes response from the chip. > I know this is not the best way to collect this data, but i'm avoiding as > much as possible a microcontroller / fpga data buffering alternative. > > That said, any comments and/or suggestions that could help me? Thanks in > advance You can probably check out some examples. http://flashrom.org/trac/flashrom/browser/trunk/ft2232_spi.c http://code.google.com/p/libftdispi/ -- Xiaofan -- libftdi - see http://www.intra2net.com/en/developer/libftdi for details. To unsubscribe send a mail to [email protected]
