libftdi Archives
|
From: | "rick.walker@xxxxxxxxxxx" <rick.walker@xxxxxxxxxxx> |
---|---|
To: | "libftdi@xxxxxxxxxxxxxxxxxxxxxxx" <libftdi@xxxxxxxxxxxxxxxxxxxxxxx> |
Cc: | "rick.walker@xxxxxxxxxxx" <rick.walker@xxxxxxxxxxx> |
Date: | Tue, 8 Mar 2022 18:57:49 +0000 |
Hi all,
I'm using libftdi to control a mass spectrometer and am getting hangups every few days. The symptom is that ftdi_write_data returns -1. Sometimes I can clear the fault and continue by calling ftdi_usb_purge_buffers(&ftdic), but I still have a residual
number of cases that simply lock the system.
I wonder if it would make sense to change the logic slightly in ftdi_write_data:
int ftdi_write_data(struct ftdi_context *ftdi, const unsigned char *buf, int size)
{
...
if(libusb_bulk_transfer(ftdi->usb_dev, ftdi->in_ep, (unsigned char *)buf+offset, write_size, &actual_length, ftdi->usb_write_timeout) < 0)
ftdi_error_return(-1, "usb bulk write failed");
...
}
It seems like saving the return value from libusb_bulk_transfer and returning that value rather than -1 would make the error culprit more visible. As it is, the -1 gives no information about what caused libusb_bulk_transfer() to fail.
Please let me know if you have any other suggestions for how to recover from a ftdi_write_data error. I suppose, I could close the context and start over, but maybe there are better approaches. The target application should run for up to a year reliably
without rebooting.
Kind regards,
--
Rick Walker
libftdi - see http://www.intra2net.com/en/developer/libftdi for details. |
Current Thread |
---|
|