libftdi Archives

Subject: RE: I've discovered the nature of my problem, but I don't know how to fix it... can anyone suggest something?

From: "Michael Plante" <michael.plante@xxxxxxxxx>
To: <libftdi@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 10 Sep 2010 11:09:18 -0500
John Oyler wrote:
>> They were initially only checking r for negative values, which
>> indicate actual errors. It will also occassionaly for me (say
>> 30% of the time) return 0, indicating zero bytes read.

Like I mentioned I was doing, you ought to accumulate any bytes you read
into a circular buffer and wait until you have as many as you wanted.  I
believe it's possible to get a partial read.  I usually tell libftdi to read
however many it takes to fill my buffer, and my buffer is always bigger than
the largest SPI input block I might want to read.

>> When it's called again a second time with all the SPI-read-goodness,
>> I'll then get the value I've expected... but the SPI chip I'm talking
>> to has viewed that as two reads, thinking its internal FIFO has one
>> less byte to read. Meaning that it cuts me off too early.
>> I'm of course reading through libftdi's source code and the
>> ftdi_read_data() function, but I'm at a loss for how to fix
>> this. If I do a full SPI read, the Semtech chip will have still counted
>> the failed read prior and the current one as well. Is my byte just stuck
>> in some USB buffer purgatory? Is it stuck in the FTDI chip (the data
>> sheets mention *nothing* about any such thing, this I highly doubt).

Like I said, there is a FIFO inside the FT2232D (incidentally, you could
have inferred this from the existence of a latency timer).  FTDI's docs are
kinda spread around, but TN107 says 128 bytes Tx, 384 bytes Rx for your
chip.  You don't necessarily need to know the size, though; I certainly
don't take the size into account.  It just matters that it's present.

>> Doing more reads to attempt to skew things back in the right
>> direction doesn't seem to have any effect, either.

Ok, so you need to clarify when you say "read", with regard to doing extra
reads.  The radio chip doesn't know if you call ftdi_read_data() or not, but
if you send a SPI/MPSSE command (via ftdi_write_data()), depending on the
command type, the radio chip can find out about it.  In other words, your
extra reads should consist of ftdi_read_data(), but no calls to
ftdi_write_data(), unless you've timed out and want to retry, but retrying
is icing for you at this point.  So:  are you actually sending new MPSSE
commands when you try to catch up, or are you ONLY calling ftdi_read_data()
extra times?  I think "send immediate" is ok, but don't write anything else
just yet.


libftdi - see for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx   

Current Thread