Hi Rick,
You wrote on Tue, Mar 08, 2022 at 06:57:49PM +0000:
> 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.
Sorry for the long delay, I maintain libftdi in my spare time.
The problem is changing the return values for ftdi_write_data()
would break existing libftdi applications. One thing we could do
is to store the error code in an extra variable and have a get() function for
this.
So may be something like ftdi_get_last_libusb_error()?
I'm also open for other API designs if something better comes up.
Cheers,
Thomas
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
|
