CP2110 Update for 2019

The last time I wrote about the CP2110 adapter was nearly a year ago, and because I have had a lot to keep me busy since, I have not been making much progress. But today I had some spare cycles and decided to take a deeper look starting from scratch again.

What I should have done properly since then would have been procuring myself a new serial dongle, as I was not (and still am) not entirely convinced about the quality of the CH341 adapter I’m using. I think I used that serial adapter successfully before, but maybe I didn’t and I’ve been fighting with ghosts ever since. This counts double as, silly me, I didn’t re-read my own post when I resumed working on this, and been scratching my head at nearly exactly the same problems as last time.

I have some updates first. The first of which is that I have some rough-edged code out there on this GitHub branch. It does not really have all the features it should, but it at least let me test the basic implementation. It also does not actually let you select which device to open — it looks for the device with the same USB IDs as I have, and that might not work at all for you. I’ll be happy to accept pull requests to fix more of the details, if anyone happen to need something like this too — once it’s actually in a state where it can be merged, I’ll be doing a squash commit and send a pull request upstream with the final working code.

The second is that while fighting with this, and venting on Twitter, Saleae themselves put me on the right path: when I said that Logic failed to decode the CP2110→CH341 conversation at 5V but worked when they were set at 3.3V, they pointed me at the documentation of threshold voltage, which turned out to be a very good lead.

Indeed, when connecting the CP2110 at 5V alone, Logic reports a high of 5.121V, and a low of ~-0.12V. When I tried to connect it with the CH341 through the breadboard full of connections, Logic reports a low of nearly 3V! And as far as I can tell, the ground is correctly wired together between the two serial adapters — they are even connected to the same USB HUB. I also don’t think the problem is with the wiring of the breadboard, because the behaviour is identical when just wiring the two adapters together.

So my next step has been setting up the BeagleBone Black I bought a couple of years ago and shelved into a box. I should have done that last year, and I would probably have been very close to have this working in the first place. After setting this up (which is much easier than it sounds), and figuring out from the BeagleBoard Wiki the pinout (and a bit of guesswork on the voltage) of its debug serial port, I could confirm the data was being sent to the CP2110 right — but it got all mangled on print.

The answer was that the HID buffered reads are… complicated. So instead of deriving most of the structure from the POSIX serial implementation, I lifted it from the RFC2217 driver, that uses a background thread to loop the reads. This finally allowed me to use the pySerial miniterm tool to log in and even dmesg(!) the BBB over the CP2110 adapter, which I consider a win.

Tomorrow I’ll try polishing the implementation to the point where I can send a pull request. And then I can actually set up to look back into the glucometer using it. Because I had an actual target when I started working on this, and was not just trying to get this to work for the sake of it.

Consumer hardware considerations

I’ve already written about my buying hardware from Germany for what concerns most of my non-urgent hardware needs. And with the exclusion of harddrives since they tend to fail on me quite often (by the way, with the cold and everything I didn’t get around to order my new hard disks, I’ll see to do that next week since I’m really needing them). Not only that, but sometimes I get friends asking me if I can fetch them something at a lower price than they’d buy it here.

It obviously has disadvantages: it takes time for the stuff to arrive, it takes even more if something is faulty, but all in all most of my friends are glad they can save some money since they rarely have urgent needs for computers, as they tend to play most of the time with them, rarely they need it for job or school. At any rate, the whole thing is sometimes distressing for me, I got used to shipment delays and similar, which is physiological with this way of buying stuff. On the other hand, it keeps me up to date with consumer hardware which I don’t lately deal with myself, since I currently use Apple laptops and I got higher grade hardware for my workstation.

In 2008 I had to build two computers, for two friends of mine in the same household, and to cut down on the amount of work to do, I choose to use mostly-similar hardware between the two of them. Which consisted mainly in using the same wireless card and the same motherboard. Unfortunately one bought a 32-bit XP Pro license, and the other a 64-bit XP Pro license which caused quite some difference between the installation of the two of them, but it wasn’t that bad. (Yes I know XP is evil, I know it all too well, so I usually provide installation media for Linux as well, but since they need it to play or do 3D rendering, I don’t go syndicate about it; their loss not to use a Free operating system I guess).

When the time came to order the two boxes that I received last week, I decided to use the same botherboard again, a Gigabyte GA-MA770-DS3 which turned out pretty neat for both the other two boxes. Again one friend bought a 32-bit XP and the other 64-bit XP. Although I ordered the same exact product code, the motherboard I received are quite different, hardware revision 2.0 rather than 1.0, with different drivers even for AHCI to the point that it wouldn’t work with the install CDs I prepared for the other two. Okay, no big deal.

But the problems with XP (the huge amount of them) are not what I’m interested in talking about. Instead I’m interested in the way they evolved the hardware on a very surface level between the two revisions. This motherboard has an interestingly huge amount of USB ports which makes it pretty useless to use USB hubs, with the exception of having ports right over your desk rather than behind your computer; before, you had six leads for them internally, two connecting to the front in most computers and one behind on a bracket over a PCI slot or similar.

The new revision instead has four leads internally, and expose the rest of them on the backplate; to do that they removed the serial port, which is now a lead on the motherboard. It reminded me so much of old AT motherboard where the only connection on the backplate was the DIN keyboard connection and you had to use brackets (or the chassis’s cut) for the other connections. The interesting bit is that they don’t give you a bracket with the serial port, nor they give you one with the parallel port, which already on rev 1.0 was not present on the backplate. It’s interesting to note how the old DB-25/DE-9 is disappearing step by step from our computers. Luckily neither of my friends wanted serial or parallel ports, but even if they wanted I think I still have some connectors around.

When I was given my first ‘modern’ computer, a Pentium 133 MHz, in 1997, it was standard to have a gameport/MPU-401 port on board for MIDI and joysticks; since the introduction of joysticks with three axis, and gamepads with eight or more buttons, this started to be quite a problem though. Even more when Sony introduced the DualShock line which had twelve buttons, a D-pad (which means another four buttons) and two analog sticks (which again changed with the coming of the PlayStation 3), and PC gamepad manufacturers had to find ways to do something as good, which turned out to be USB gamepads. Since the MIDI hardware was already not that common at the time, this was one of the first thing to disappear, and software support for it started to bitrot, I remember having to patch my kernel for a while with my Athlon 1000 which had an integrated MPU-401 port, because it failed to initialize it properly. From AC’97 onward, I don’t think I have seen another gameport on computers I fixed, which said “good bye” to one format.

The second port to say bye has been the parallel port, which was used by the old line printers, with their more or less complex children and with its nightmares to work with on Linux. I was never able to control the parallel port decently from Linux because most of the sample code for that was designed to be used with DOS or Windows 95 and used the I/O ports directly, which is not really a good thing. Interestingly enough, the 8255 interface that was used for those was used at my school for the electronics laboratory, although it then had a full 24-bit interface, rather than registry-based interface that EPP ports have. Enterprise had a parallel port, Yamato does not have it.

The third port is the serial port ad I can really guess quite well why they are taking it away, on most modern desktop systems it’s useless, nobody would ever think of making use of it. Even analog modems nowadays use USB interfaces through CDC. Luckily for me, Yamato still has two, one of which is wired to the SBMC board for IPMI, but even this way I have not one but three USB RS-232 adapters connected to Yamato (one of which recently supported by Linux); admittedly, only two are connected USB-side, the other is connected serial-port side and I use for connecting to the serial console from the laptop which has no serial port at all.

The only remaining D-subminiature you still find on modern computers is the VGA port, but even that is getting away soon, it is already gone from most laptops, and it’s getting replaced by DVI and HDMI ports. On one of the two computers, the video card has a dual-DVI video card, which means it won’t have any D-sub port on the back of it. Sheesh!

I know this post is mostly useless, but it really made me feel old, I have to say.