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.
[Avishay] has a very, very cool solution to this problem: put a display on a USB to serial converter to tell the user what COM port the OS labeled it as.
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.
The idea is great, eveb extending it to support a small 8×2 lcd which can display all the info(baudrate, port name, data format)
Then again… Its not that hard to check and, at least win7, remembers what port was allocated to a device, so that device will always be on the same one. Even if you plug it in a different usb port.
This has not been my experience on any version of windows. Including 7.
It’s true for devices with serial numbers. You can set a serial number for FTDI devices using FT_PROG software.
and can use SPI too
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!
Btw, is it possible to make a multi serial port device with such a micro? (or a better one)
Then a display will totally be worth!
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).
FT232Rs already have a chip id function that gives them a predictable tty ID under *nixes. If you get them on tape then they’re even sequential.
On Linux, there’s /dev/serial/by-id/ and /dev/serial/by-path.
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.
You can also create udev rules based on path or serial to give meaningful names to these devices, as detailed here: http://gnosia.anu.edu.au/wiki/FT232R#Giving_devices_a_better_name
You can find these values either by trial and error or by snooping udev’s log, /var/log/udev
seconded, in linux. Configure udev to give it a nice human-friendly name, then use that. /dev/arduino1 etc.
^ this was my first thought. LCD seems like a bulky approach, and then you still need to type the com port into your software – this way you don’t. so, thirded.
Are you all kidding? Configuring udev or typing one of those serial numbers is great for a often used device hooked to an impossible to upgrade laptop. Otherwise just use a real serial port!
While we’re talking USB-to-serial, can anyone recommend a good solution for parallel ports (for bit-banging, etc)? Most of the USB-to-parallel adapters I can find are just for printers.
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.
http://eds.dyndns.org/~ircjunk/tutorials/elex/ata2isp/main.html
So let me understand this;
1: anyone with the technical skill to do this, doesnt have the know-how to determine what com/ttys they are on?
2: I have to install a helper program on the host? why not have the helper program tell me what port on my screen and save me the addtional hardware?
Is this neat, yea, it is, I just cant see where I would use it, due to having to install the helper, it would take me longer to install it that to know what com port it is.
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!
yeh it was a neat idea…. until I saw that it needed a helper program
kinda of defeats the purpose now.
Or you can just attach an LED to the TX port, send some data, and see which led blinks.. As simple as that
that is nearly what I meant
But not quite.
If you’re using an FTDI chip, you don’t have to mess with COM ports at all. You can use their DLL to locate your device by name or serial number and communicate with it directly.
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.
This is one of those ideas that is so dreaded simple once someone does it but I am confident every single person who has seen this has fumbled at least once with an overabundance of vcoms.
weird people those windows users are, they have no udev, and can’t write proper rules to make devices appear as /dev/mydevboard
I use linyx and windows, and in windows, my ftdi cable is always the same com port when I plug it back in
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!
…this is totally cool, ..thanks a lot! Just what I needed..and I didn’t even know :-) Im going to try it with this board: http://www.usconverters.com/index.php?main_page=page&id=62&chapter=0