libftdi Archives

Subject: Better error code from ftdi_write_data()

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.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx


Current Thread