USB to Serial adapter tells you what COM port you’re on

Since most of us are long past the days of hardware serial ports, the USB to serial adapter has become a mainstay on the hacker’s tool belt. While they’re cheap and convenient, USB to serial adapters aren’t always the easiest thing to use: there’s always the issue of what COM port Windows is calling your USB to serial adapter, or what TTY device it is in Linux/OS X.

The prototype runs on a PIC 18F2553 dev board. When plugged into a Windows box, the serial adapter sets up two USB devices. The first device is a Communications Device Class that handles the grunt work of the USB to Serial connection. The second USB device is a proprietary piece of software that grabs the current COM port number. This number is displayed on an LCD thanks to a host application on the Windows PC that reports the COM port of the Serial adapter.

It’s one of those ideas where you didn’t know you needed it until it was presented to you. An excellent tool from [Avishay], although maybe a pair of 7-segment LEDs would make it a more manufacturable device.

I like the idea a lot. But being a cheapskate, I’m guessing that most people have a maximum of 3 maybe 4 serials on a computer at one time? How about LEDs and a nice CNC’d case? Lots cheaper to make. Did I say skinflint?

If you have a source for cheap CNC work, please share it…I’m in need for a few projects.

You could spin your own board with one or two 7 segment displays, using a sampled micro and bring the cost down to next to nothing.

I was actually pretty excited about this, as having the com port display would be very useful…that is until I saw it requires host software. Maybe if you could store the executable on an EEPROM, and have the device populate as a USB mass store with an autorun script.

I agree. The host software is the idea killer. Why wouldn’t the host software simply detect the adapter and tell you what serial port it was attached to on the host? Why would you need this built into the USB-serial adapter?

Just because you only have x devices attached doesn’t necessarily mean they will be assigned com1-x or tty0-x-1. The best solution IMHO is to install actual serial ports but if that is impossible this is a very creative second option!

LUFA (http://www.fourwalledcubicle.com/LUFA.php) ships with a “dual virtual serial device” demonstration app. If you want actual multiple serial ports, you’ll also need to pick a device with multiple UARTs. The ATxmega64A1U might be a device to look at; it has 8 UARTs. However, I’m not sure how easy it is to keep 8 serial ports well fed from an AVR, as their UARTs don’t have FIFOs or DMA; you have to service an interrupt for each byte read or written, and 8 ports times even a modest data rate (115200 baud) means ~190k interrupts per second. The AT32UC3A0128 has a pair of DMA channels for each USART (if I read the datasheet correctly), so it should be able to keep everything fed with data until you run up against the limited USB data rate (12MB/s). Also, if I understand USB serial correctly, each serial port needs two endpoints, so you’d be limited to 3 ports on the AT30UC3A0128; larger parts might have more endpoints (I didn’t check).

If your device has a unique serial number (like FTDI FT232R), then it’s nice to rely on a serial-number-based path like /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A600aBCd-if00-port0; if it doesn’t (for instance, my Prolific chipset USB-serial adapter doesn’t), then it may be better to rely on an attachment-based path like /dev/serial/by-path/pci-0000:00:13.0-usb-0:1:1.0-port0.

There is nothing that will work like the hw parallel port. The one on the main board (or pci) is directly mapped to a memory address. Converters will work by exchanging packages over usb…
You can use some chips from ftdi, in bit bang, but its not the same thing. It will not be that fast.

what do you need it for? direct parallel port emulation will be too slow via USB. Microcontrollers can handle the speed if they are running local code.. I run my CNC mill that has a parallel interface this way. G-code interpreter on an arudino bitbangs the pins out into a parallel port connector.

Yep, both good counter-points on this device. The idea is nice, the implementation needs some work. The helper program is the lynch-pin in preventing this from working nicely. If you could do this without any additional software, it would be much, much nicer!

I just havent had an issue, but some things I do on final products; I made a 4 chanel voltage meter, and it streamed out the values, with a header of the product name, thus the software client end just opened each serial port and looked for the incoming header.

You only have one. At work we have about a dozen of usb-serial cables attached the server, so that developers can work remotely. And without udev rules that would be pain, since dongles occasionally are replugged/swapped when the hardware changes

What I usually do is use a pair of tweezers or a paperclip to connect pins 2 and 3 of the serial port together while there isn’t a cable plugged into it. Transmit something with your favorite terminal editor of choice at any baud rate you choose. If you get something back then you’ve guessed the correct COM port.

The computer transmits data OUT on pin 3 and gets data IN on pin 2. By connecting them together you’ve made a primitive loopback. These pin numbers are labeled on every DB-9 serial connector so they’re easy to find.

On most computers you have 2-3 COM ports and can get it right in 1-2 tries. Not as slick as this approach but easy to accomplish in a pinch. BONUS: you’ll impress your coworkers!