Apparently my OSTC was just as tired as I was (I sent that last email at 3:30am). Replacing the (new) AA Alkaline with an (old) Saft battery was enough to give it the boost to start up again. So for now I'm back in business with a "working" FTDI dive computer (the DC has been broken for a long time, but it at least responds on FTDI and therefore I can test any FTDI connection issues)
> On Sep 30, 2019, at 3:30 AM, Dirk Hohndel <d...@hohndel.org> wrote: > > I started this response email, wanting to send you a dump of what we already > log about the new device that's connected after we get the intent, but > unfortunately > I can't seem to revive my my last FTDI dive computer. It had been super flaky > the > last couple of times I played with it, but I now can't turn it on anymore. > > If you connect your FTDI dive computer, we are logging a string representation > of the UsbDevice structure > > https://github.com/Subsurface-divelog/subsurface/blob/eecca6aab0a1970c7474df7ac8408d810a5d0bbd/core/android.cpp#L179 > > <https://github.com/Subsurface-divelog/subsurface/blob/eecca6aab0a1970c7474df7ac8408d810a5d0bbd/core/android.cpp#L179> > > Do you have code that can convert that into a libusb_device structure? > Because if you have that code, I think I can piece the rest together. Well, > maybe. If I had a working FTDI dive computer to test with... So this is a textual representation of what we get: UsbDevice[mName=/dev/bus/usb/001/002,mVendorId=1027,mProductId=24577,mClass=0,mSubclass=0,mProtocol=0,mManufacturerName=HW,mProductName=HeinrichsWeikamp OSTC3,mVersion=6.00,mSerialNumber=A4SHCQSJ,mConfigurations=[\nUsbConfiguration[mId=1,mName=null,mAttributes=128,mMaxPower=50,mInterfaces=[\nUsbInterface[mId=0,mAlternateSetting=0,mName=HeinrichsWeikamp OSTC3,mClass=255,mSubclass=255,mProtocol=255,mEndpoints=[\nUsbEndpoint[mAddress=129,mAttributes=2,mMaxPacketSize=64,mInterval=0]\nUsbEndpoint[mAddress=2,mAttributes=2,mMaxPacketSize=64,mInterval=0]]]]" What we need is struct libusb_device { /* lock protects refcnt, everything else is finalized at initialization * time */ usbi_mutex_t lock; int refcnt; struct libusb_context *ctx; uint8_t bus_number; uint8_t port_number; struct libusb_device* parent_dev; uint8_t device_address; uint8_t num_configurations; enum libusb_speed speed; struct list_head list; unsigned long session_data; struct libusb_device_descriptor device_descriptor; int attached; PTR_ALIGNED unsigned char os_priv[ZERO_SIZED_ARRAY]; }; bus/port should be 1/2 what do I use as parent_dev? what's the device_address and num_configurations I assume that the list is something that libusb maintains internally? And then of course I still need a device_descriptor - which has plenty of other fields to fill... struct libusb_device_descriptor { /** Size of this descriptor (in bytes) */ uint8_t bLength; /** Descriptor type. Will have value * \ref libusb_descriptor_type::LIBUSB_DT_DEVICE LIBUSB_DT_DEVICE in this * context. */ uint8_t bDescriptorType; /** USB specification release number in binary-coded decimal. A value of * 0x0200 indicates USB 2.0, 0x0110 indicates USB 1.1, etc. */ uint16_t bcdUSB; /** USB-IF class code for the device. See \ref libusb_class_code. */ uint8_t bDeviceClass; /** USB-IF subclass code for the device, qualified by the bDeviceClass * value */ uint8_t bDeviceSubClass; /** USB-IF protocol code for the device, qualified by the bDeviceClass and * bDeviceSubClass values */ uint8_t bDeviceProtocol; /** Maximum packet size for endpoint 0 */ uint8_t bMaxPacketSize0; /** USB-IF vendor ID */ uint16_t idVendor; /** USB-IF product ID */ uint16_t idProduct; /** Device release number in binary-coded decimal */ uint16_t bcdDevice; /** Index of string descriptor describing manufacturer */ uint8_t iManufacturer; /** Index of string descriptor describing product */ uint8_t iProduct; /** Index of string descriptor containing device serial number */ uint8_t iSerialNumber; /** Number of possible configurations */ uint8_t bNumConfigurations; }; Some of those are obvious, others... not so much. I'll keep hacking on this and see how far I get. Any insights and pointers in the meantime would be welcome /D
_______________________________________________ subsurface mailing list subsurface@subsurface-divelog.org http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface