Hi All,
I've appended a more proper patch to fix this behaviour. It extends
the argument list of get_strings_and_reopen() and get_strings(). I
introduced default arguments to make this API-break backwards
compatible. These could, maybe at a later stage, be removed. Whats
not clear to me is how to deal with open(struct libusb_device *dev).
Should in here get_strings_and_reopen() not completely removed?
While this patch tries to minimize the api breakage. I'd suggest to
join get_strings_and_reopen() and get_strings() and to make them
private. as they are only useful for vendor(), product() and serial()
while we should save the used stings in the member variables after
successfully opening a device based on their usage.
Related to this is there a way in libusb to detect if the string
descriptor, which is optional, is empty or not available?
Cheers,
Matthias
Am Thu, 25 May 2017 00:53:12 +0200
schrieb Matthias Janke <matthias.janke@xxxxxxxxxxxxxxxxxxxxxxx>:
> Hi Thomas,
>
> Am Tue, 23 May 2017 21:26:23 +0200
> schrieb Thomas Jarosch <thomas.jarosch@xxxxxxxxxxxxx>:
>
> > Hi Matthias,
> >
> > Am 12.05.2017 um 13:32 schrieb Matthias Janke:
> > > I'm using the c++ wrapper of libftdi (git co of yesterday) to
> > > communicate with a FT2232HL on a Lattice XO2 Eval board
> > > (LCMXO2-7000HE-B-EVN) this board has no programmed in iSerial.
> > >
> > > A simple c++ program which just opens and closes the device
> > > fails with "libusb_get_string_descriptor_ascii() failed" this is
> > > also true for the find_all_pp example (find_all, works). This
> > > failure originates in the use of the get_strings() function
> > > inside all c++ open() functions. This function wants all three
> > > iManufractuer, iProduct and iSerial to be present. The C-API
> > > allows one to pass NULL to ignore these descriptors. This is
> > > currently not possible with the c++ api. To properly fix this I
> > > suspect an api break is needed. As temporary ugly workaround I
> > > use the appended patch. Are there other ideas to fix this?
> >
> > what about this open() function from ftdi.cpp:
> >
> > int Context::open(int vendor, int product, const std::string&
> > description, const std::string& serial, unsigned int index)
> > {
> > // translate empty strings to NULL
> > // -> do not use them to find the device (vs. require an empty
> > string to be set in the EEPROM)
> > const char* c_description=NULL;
> > const char* c_serial=NULL;
> > if (!description.empty())
> > c_description=description.c_str();
> > if (!serial.empty())
> > c_serial=serial.c_str();
> >
> > int ret = ftdi_usb_open_desc_index(d->ftdi, vendor, product,
> > c_description, c_serial, index);
> >
> > if (ret < 0)
> > return ret;
> >
> up to this point everything looks ok. but
> this:
> > return get_strings_and_reopen();
>
> innternaly calls get_strings() which unconditioaly tries to get all!
> strings:
>
> int Context::get_strings()
> 323 {
> 324 // Prepare buffers
> 325 char vendor[512], desc[512], serial[512];
> 326
> 327 int ret = ftdi_usb_get_strings(d->ftdi, d->dev, vendor, 512,
> desc, 512, serial, 512); 328
> 329 if (ret < 0)
> 330 return -1;
> 331
> 332 d->vendor = vendor;
> 333 d->description = desc;
> 334 d->serial = serial;
> 335
> 336 return 1;
> 337 }
>
> cheers,
> Matthias
>
> > }
> >
> >
> >
> > -> if you pass an empty string for "std::string serial",
> > it should pass down NULL for the serial parameter of the C API.
> >
> > What happens if you use this specific open() function?
> >
> > Cheers,
> > Thomas
> >
> > --
> > libftdi - see http://www.intra2net.com/en/developer/libftdi for
> > details. To unsubscribe send a mail to
> > libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
>
>
> --
> libftdi - see http://www.intra2net.com/en/developer/libftdi for
> details. To unsubscribe send a mail to
> libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx
0001-The-C-API-and-C-API-differ-in-how-they-open-a-device.patch
Description: Text Data
|
