Been a long time since I last touched this. I did quite a bit of work before packing up and heading out to a shiny new client out of state. Sadly I only brought the latest piece of code with me which has nothing to do with Qt. The Qt based stuff migrated to QML since I needed to get more familiar with that for my upcoming project. I also crawled towards being able to communicate via USB. I do say crawled.
When you come from a serial, parallel port or network communications background your first impulse/wish is to do something like this.
Not gonna happen. If you try one of those special RCA Android tablet transfer cables
You get to watch all of the lights go out on your powered hub. What’s special about this cable? According to RCA the power line is cut because the RCA Viking Pro cannot have power coming in on the port. This cable is what is required if you wish to cross compile and deploy code to the Android tablet.
Yeah, I’m not a hardware guy. I’ve done serial communications much of my life and understand it pretty well. I’ve even done parallel port communications with the DOS outp() command. This is a new frontier fraught with peril. USB communications requires some form of intelligence in anything which gets connected. The OS is also going to try and identify the device, then load a driver. Actually if you have the stand alone C program I started working on to strip this problem down to the barest of components and you plug both ends of the same cable into the hub you can see periodic error messages popping up as Linux tries to identify the two new devices. It can be entertaining.
All of the snippets and scraps of code which “claim” to work on-line rely on a single USB chip which has both bulk input and output end points. Many/most of those “complete” programs which the poster claim works won’t even compile. Their problem isn’t some change in the C standard. I found variables which weren’t even declared. Really don’t know what C compiler they were using to get away with that.
My next knee-jerk reaction was to use my PL 2303 USB to serial cable and connect it to my DB-9 serial port on the back of the desktop.
The part in the middle would have the pretty pretty lights
That of course requires a gender bender with one set of nuts removed.
With everything plugged in and the pretty lights lit, I used the following command to find my device.
sudo lsusb -v
Here is the portion of the output for this device:
Bus 001 Device 020: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x067b Prolific Technology, Inc. idProduct 0x2303 PL2303 Serial Port bcdDevice 3.00 iManufacturer 1 Prolific Technology Inc. iProduct 2 USB-Serial Controller iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x000a 1x 10 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered)
I bolded the endpoints of interest. Gee! Seems like this ought to work just like all of those example programs, right?
Not a chance!
After an awful lot of head scratching combined with failures I stumbled onto this post. Man does that suck. My favorite one of these cables, only because it had lights on it so you could tell if you were communicating is the modern day equivalent of a WinModem. That’s right, it’s a fake converter just like WinModems were fake modems. They would only work on Windows with the Windows driver because they had none of the modem chipset. The same is true for the PL 2303. The manufacturer has even dropped support for it from their latest Windows driver so you have to work around per the previous link.
One of the first steps in working with libusb is making a call to remove the kernel driver. Once the driver was gone, what was left in the hardware couldn’t possibly work. So, after frantic packing for my trip (and potentially overwriting the really nice QML code with the suckier old version in all of my moving stuff around) I hopped onto ebay and ordered some USB to serial bridge devices which came with nice little TTL wires.
The leads were the selling point for me. I don’t want to string a boatload of cable for this. I just want to connect transmit to receive with one wire so I can have a full loopback. If I get really energetic over the next few weeks I will dig through the data sheet for the PL 2303 and find the Linux driver source to see if I can get code which works with that hardware and no driver, just to do it.
When I plug the new device in and re-run the lsusb -v command I see the following for our new device.
Bus 001 Device 021: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x10c4 Cygnal Integrated Products, Inc. idProduct 0xea60 CP210x UART Bridge / myAVR mySmartUSB light bcdDevice 1.00 iManufacturer 1 Silicon Labs iProduct 2 CP2102 USB to UART Bridge Controller iSerial 3 0001 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 2 CP2102 USB to UART Bridge Controller Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Status: 0x0000 (Bus Powered)
The fact it says it is a controller is encouraging, but, that disappointment shall have to wait until tomorrow. It’s late and I’m tired.
