I've borrowed my code from flashrom (which I'm very grateful for... without it
I doubt I'd ever gotten anything to work).
The flashrom guys have the following function, which they use to read back SPI
data:
static int get_buf(struct ftdi_context *ftdic, const unsigned
char *buf, int size) {
int r;
r = ftdi_read_data(ftdic, (unsigned char *) buf, size);
if (r < 0) {
printf("ftdi_read_data: %d, %s\n", r,
ftdi_get_error_string(ftdic));
return 1;
} else if (r == 0) {
printf("\nLooks like our read failed.\n");
return 2;
}
return 0;
}
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. 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). I don't think it's stuck in the Semtech chip, because that would
mean it's internal pointer is changing for the read attempt when the clock
toggles, but that it's not putting data on MISO. If so, I think it's at the
very least buggy but maybe even defective... and they have too many customers
for me to not be able to find any such complaints via Google.
Can anyone offer any advice? Is it possible to overcome this without straying
into libusb territory?
Thanks,
John O.
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
