[Felipe Navarro] wanted to add a few serial ports to his computer, but couldn’t find an adapter that suited his needs. So, he built his own.
His Quad Serial device is a nicely designed converter that offers four serial ports, two of which are isolated to avoid blowing up too much stuff if things go wrong. The other two are TTL ports, but with an interesting twist: feed them any voltage between 1.8 V and 5 V, and they will happily work with it, which is a lot easier than messing about with TTL to RS-232 converters.
It’s all built around an FTDI FT4232H chip, which has drivers available for most OSes, so it should work with pretty much anything. And, as [Felipe] notes, this chip has not been cloned, so you won’t have to worry about the FTDI drivers disabling your device without warning. Well, not at the moment, anyway. We did cover a similar quad serial port adapter last year, but this one is a bit more developed, with both DE-9 and screw terminal connectors available.
If it does blow up, is that technically a “Serial Killer”?
Easier to blow up a box of Wheaties.
Well done, Jerry! You definitely milked that serial joke well!
;-)
Did Salvador Dali eat breakfast surreal?
> this chip has not been cloned
Not yet.
Nothing sacred, we can clone people. ;-)
sacred?? people are the worst, just think about it…
If you don’t want to encourage FTDI’s “f*ck the end user for the supply chain’s sins” approach to handling counterfeit parts, there are other companies that make USB-UART bridges. Silicon Labs’ CP2108 would handle this job pretty well, for example. I think you have to download the driver from SiLabs on Windows, but the CP210x family Just Works everywhere else.
using FTDI chips is supporting that company and their policy. My opinion is that no one should use FTDI or prolific chips at their designs. There is great chips at silicom labs. Personally I like use them and buy only products with them because clone or not it just work. So when I buy those products I know that they work. I try buy always original chips but with prolific and FTDI I newer know when my product just stop working.
Except counterfeits have no guarantees. That’s part of saving a buck. If you do, great, but no complaints if you don’t.
Use what works for you. Trust goes a long way.
rs232 can be up to +- 15 volts
yep, most ‘proper’ rs232 sockets on commercial hardware work at +/- 10v or more (20v or more swing). TTL uart and rs232 are not the same thing. The higher voltage is to minimise noise and errors over long cables (about 50 feet max under the specification). The linked page says “2 Any level UARTs, “, but these aren’t ‘any level’ if it can’t take standard rs232 voltages.
“The other two are TTL ports, but with an interesting twist: feed them any voltage between 1.8 V and 5 V, and they will happily work with it, which is a lot easier than messing about with TTL to RS-232 converters.”
RS-232 can be -15V to +15V, so I fail to see how this would be addressed. It will be nice for other than TTL levels like 3.3V etc, but no RS-232.
I think the point is you don’t need a TTL to RS232 for to talk to your 1.8-5V TTL device. Besides RS232 polarity is inverted c.f. TTL – 0v represents +V, 1.8-6V represents -V.
Take a look into the page 4 of the schematic and you will understand how I developed it. It’s a simple bus transceiver SN74LVC1T45 from TI, in one side we apply 3v3 which is the voltage we got from the FTDI chip and in the other side we can driver it with anything from 1.8v to 5.5v :)
I’d love a four parallel port version.
It would come in really handy for robot and home automation projects to interface directly without additional level shifting and isolation. Effectively treating a laptop as an arduino or ras.pi with all that IO at your disposal.
Take a look into the FTDI API, there is some nice features like GPIO on it! It’s also one of the future upgrades on this project, I’m thinking about putting some of this GPIO into headers in the PCB.
But this way you still have to live with the godforsaken, unreliable USB stack and related OS foolishness. USB serial ports have no place in any system where you need reliable RS232 communication.
In other words, don’t build a product that uses USB serial ports. You’ll spend your engineering time be coding workarounds, doing additional testing and, later, burning support time and customer goodwill troubleshooting related issues in the field.
If you have a “real” computer (i.e., one with slots), real serial cards are readily available, inexpensive, and far more reliable than their USB imitations.
Industrial quality even.
@Paul, You are right – in special cases. USB Serial is a mess when it comes to timing integrity (determinism). For example, unless you go through draconian driver/system hacks, try to avoid using the likes of the RS-232/UART handshaking lines for the likes of passing even semi-accurate rise/fall edges to the NTPD time-keeping daemon for PPS input from e.g. a GPS receiver on almost any multi-tasking operating system.
But the work-around is pretty simple if your hardware has REAL plug-in UART card support. You can just add a multi-port serial adapter card for less than $20 instead, especially if you’re running xBSD or Linux.
For any other non-timing critical application, it’s hard to justify a build like this unless you REALLY need the isolation (and REAL isolation is not as simple as it sounds – taming grounds and ground loops is not simple). Cheap USB/RS-232/UART cables or breakout dongles are really cheap these days, so are USB hubs if you need multiple serial ports. But without isolation.
Oh, it’s far worse than just timing indeterminism. Even the com port ID is subject to change, depending on what the customer does. Even the very *existence* of the port is subject to change.
Real example, real product, real dollars cost: Product goes out the door, we *thought* thoroughly tested. Customer decides they want to plug in their USB stick, so pulls out one of our “serial” USB plugs to get to the closely-spaced ports. When done, they plug it back, but in the adjacent USB port. Now our device gets assigned to a new com port that happened to fall beyond the range of com port numbers our software polls. Result: Unusable, broken product, as far as the customer can tell.
Second real example, real dollars cost: A motor controller (say X axis) is plugged into com port. A second controller (Y axis) is plugged into a second com port. Poll them, and they respond, all is well, but they aren’t uniquely serialized: the only way the software knows which axis it’s talking to is by the com port number… Plug the USBs into a different computer, or a different USB port, then the com ports are assigned differently. You don’t even know, and can’t tell, which axis is which. Hardware damage happens…
Third real example: USB hub splits out to two separate “serial” ports. The OS decides to re-enumerate the bus in the middle of a serial transaction. It only takes a fraction of a second, but bytes are lost, causing the target device to safe itself, ending up causing a system halt and restart. Many dollars of consumables lost, many minutes of customer time and much frustration caused.
USB serial is fundamentally broken on several levels. It’s a joke on us all. The worst is that the above examples are *after* we learned all this on previous products, but it’s become almost impossible to avoid these “fake serial” devices in purchased components, even purported “industrial grade” stuff.
There’s a reason it gets called ‘Useless Serial Bus”.
I would think that each axis would have an ID switch on it of some kind…
That way you are not relying on which comm port is assigned to determine the X or Y axis.
“…an ID switch on it…”
Yeah, that would be sensible. But these were simple single-axis drives. They just did what they’re told. It’s up to the host (and the designer) to make sure it’s sending the right stuff down the wire. Their great fault is that they were not uniquely identifiable over the serial port.
Anything designed in this millennium is smarter than that, but this was back in the Transition Years. But it still serves as an example to tell my engineers.
It gets assigned a different COM port number because you skimped out and didn’t give it a unique serial number in the device descriptor. If you don’t, Windows uses the bus topology as identifier and assigns a different port number when you plug it into a different USB port. It’s also possible to map serial ports to USB devices, it just takes a bit of work.
Yes, but that’s only a partial and not very satisfactory solution to what shouldn’t be a problem in the first place. Unique serial numbers mean every bloody unit is a unique snowflake, requiring a unique configuration file (or unique source and compile!). And what happens if you want to swap a device in the field? You have to go through a stupid, time consuming configuration rigamarole. It doesn’t have to be this way.
If you implement the device lookup, you don’t even need a serial number (although inserting one during programming is not hard, and supported out of the box in any serious tool). Relying on some particular port number having some magic properties was always a terrible idea.
I’m really happy that my project started this really nice high-level discussion! Also, just wanna clarify that I’m using this project for some time and every time I plug this in the Serial number is the same, but yeah, It’s just a serial over USB, if you need something reliable you must do a CRC, resend, and all those stuff.
If only the USB standards group had taken inspiration from Ye Olde Texas Instruments 99-4/A. Every peripheral for that system contained its device software. It Just Worked long before Macintosh did that (for Apple hardware) by pre-installing *all* their device drivers. Everyone got the A/ROSE network card extension despite there ever being only one NuBus NIC with a 68000 CPU on it. Whenever a ‘point’ release to System, then MacOS was released it made doing custom installs pointless because the update would just cram everything in without checking the current install or available hardware.
On the TI, the core OS knows nothing about any device not built into the console. It has ‘slots’ where Device Service Routines appear when peripherals are connected. The DSR’s in the peripherals seamlessly integrate with the OS so when a program calls a DSR routine, it’s there to be used.
A system for USB would have all the device info, both generic (USB mass storage) and specific (capacity, max speed, unique identifier) built in.
Such would be REQUIRED or the OS would ignore it. (On the TI, a peripheral without a properly done DSR simply ‘doesn’t exist’.) On the OS side, the USB support system would have a unique ID for every port AND a way to dynamically reconfigure when a device would be first plugged into one port, then moved to another so that it would never see the same device as “new” and setup COM5 – breaking software that expects COM4. That’s pretty seriously stupid in an OS – you pull out the device assigned COM4 then plug it into another port and it gets assigned COM5 – despite the fact that COM4 is *gone*.
But that’s been a Windows thing for a long time. Like how those MRU entries in the Registry are useless. Installing new devices doesn’t search the MRU paths so the user often has to constantly manually redirect Windows to where various files are when it should be scanning the MRU paths to where it’s already copied some files from.