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).
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.
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
--
View this message in context:
http://libftdi.141977.n3.nabble.com/SPI-communication-with-libftdi-tp3157855p3157855.html
Sent from the libFTDI mailing list archive at Nabble.com.
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
