Will the Serial Console Ever Die?
simpz writes "Will the serial port as a console connection ever be displaced — especially for devices such as switches, routers, SAN boxes, etc.? In one sense it's a simple connection. But it is the only current port that, in order to use, you need to know about wiring / baud rates / parity, etc. It has non-standard pinouts. And it is becoming too slow to upload firmware to dead devices, as the firmware updates get larger. Also, the serial port is rapidly disappearing from new laptops — which is where you often really need it, in data centers. Centronics, PS/2, and current loop are mostly defunct. Is there any sign on the horizon of a USB console connection?"
I use one just fine with an old WACOM 12" tablet under linux, so while the port may be dead, we can still use serial software and hardware. There's no reason you can't use two $15 converters plus a null modem to run that old DOS-based serial telecom program (ah, telix ... thanks for the memories).
Most of the newer switches, routers, multiplexers and any other device with a serial port for a terminal interface I've had the pleasure of configuring had a web interface. I'd say that's the direction manufacturers are headed and is the next logical step.
~Mike (Titan_X)
He means on desktops, laptops, servers, and shit like that. Other than cisco routers and switches, you can't really fine hardware that has a serial port on it. But all routers and switches are still manufactured with serial...
As an embedded device engineer, I love good old UARTs. They are very small cores to add to an FPGA design, simple to write a driver for, and fast enough for most simple debug applications.
Trying that with a USB core is not an easy prospect. And they arent *that* slow. The free UARTlite IP core from Xilinx can run up to 921,600.. plenty fast for most things embedded...
"Other than cisco routers and switches, you can't really fine hardware that has a serial port on it."
Every piece of DC-worthy gear I've touched has had serial.
Of course, most stuff either comes with serial *and* ethernet, or allows one to hop in via serial and set up a web-based interface, but serial is always there.
I work for a small electronics manufacturing company, http://www.westmountainradio.com/
and we make a number of devices that use the serial port. In recent years, we had to start including USB-serial adapters with every device for the very reason mentioned: Many newer computers simply do not have RS232 ports anymore.
The RS232 port is a very convenient way to connect with a number of peripheral devices that don't need much bandwidth. In most cases, 9600 BPS is plenty. You also have the "handshake" lines which can be used to toggle an external device on or off. We use it to drive an LED and an opto-isolator to key a ham radio transmitter, among other things.
As long as there are low-bandwidth, human-interface devices, there will still be SOME use and purpose for the RS232 port.
Willie...
When it comes to managing important network switches, no, they aren't gone.
When an important switch fails for some reason, how do you contact it to see if it's recoverable remotely? (i.e. when your network admin has to manage switches that are located at remote satellite offices)
Out-of-band management addresses this limitation by employing a management channel that is physically isolated from the data channel.
I still design lots of equipment with serial interfaces inside. It is much easier to connect to a low-end microcontroller which may barely have even a single UART. And even for a higher-end processor, it's so much easier to build the interface. Developing a USB interface requires a pretty detailed understanding of USB - selecting endpoints, which transfer protocol to use, etc - so there's a big software investment and often a significant additional hardware investment to implement a USB interface. Serial is often damn close to free, so easy that it's a no-brainer to put in. And for ethernet devices like switches I can't imagine why anyone would want to bother with a USB interface when you already have 8/16/48 copies of an ethernet interface available, just plop down yet another copy of the ethernet PHY design and make that your console interface.
Point is - serial's EASY to give you, so you're gonna keep getting it for a while.
Just my $0.55 (US inflation, 1774-2008, for $0.02)
Serial is cheap, simple, works really well, and you can hook up 15+ year old equipment to it with no problem.
Is it slow? Not really, but firmware updates should be through TFTP or HTTP by now anyways for larger files.
Complicated wiring? RX-TX TX-RX, common ground.
Also RS-232 has many brothers and sisters like:
RS-422 (a high-speed system similar to RS-232 but with differential signaling)
RS-423 (a high-speed system similar to RS-422 but with unbalanced signaling)
RS-449 (a functional and mechanical interface that used RS-422 and RS-423 signals - it never caught on like RS-232 and was withdrawn by the EIA)
RS-485 (a descendant of RS-422 that can be used as a bus in multidrop configurations)
On the USB console: yeah, you can have a USB console. Most like there will be a FTDI chip, which will make your USB into a serial connection. Want an example? Arduino.....
By the way, the post is kinda mis-worded.... USB is a serial bus, so a USB console is technically a SERIAL console :)
The cisco usb is actually just a usb to serial converter into the serial port of their chip. So, it really only solves the configuration and cabling part of the problem. You're still limited to serial baud rates.
Simplicity really is the key.
Just a few days ago I hacked together a 9600 baud serial output in like an hour to help me debug an embedded microcontroller design using only a single IO pin and a crude spin-delay based bit-bang function. It worked great, and I found the trouble.
There's no way you could add something like USB nearly as easily. FTDI makes some great chips / cables, but at the microcontroller it's still TTL-level serial IO.
Plenty of microcontrollers have lots of extra serial IO ports. Many are adding USB ports as well, but it takes an absolutely stupid amount of firmware to make USB work.
There are several microcontrollers I can do USB for, since I've done it before. However, it takes weeks of work to implement USB the first time on any new microcontroller. It's usually really prone to bugs, too. USB is just too complex for the simple dumb pipes that most embedded developers need. On top of that... most of the time the micro vendor's USB firmware examples just barely work, and aren't designed very well so they're very hard to modularize and include in another design.
Is there any sign on the horizon of a USB console connection?
There is no standard USB device class for serial adapters. There is communications device class, but it is huge and doesn't really help. So FTDI and Cygnal and others have to write their own drivers for tens of OSes and architectures. If you walk up to a device with a laptop and a USB cable, chances are that your laptop doesn't have a proper driver. To make things worse, many USB-Serial adapters have to use their own VID/PID/REV identifiers, and that makes it even harder to recognize the device. Class-compliant devices would "just work" like a USB drive does, or a mouse.
There is also no standard API in OSes to talk to *modern* serial devices. USB serial devices are emulated into a virtual COM port.
I can't speak to switch access, but the serial port is paramount in the medical instrumentation field. Virtually all interfaces are serial. Need to hook up a CBC machine? Cobas? Vitek? Serial!
Most machine shops -- their equipment is serial. Sending cut information to the lathe? Serial.
Then you are looking at old catalogs my friend.... no, serial is not included on every piece of hardware.
No, that little RJ45-looking jack labeled 'Console' on most newer Cisco and HP gear is actually for a serial to RJ45 cable...
There's no place like
You mean DE9. DB9 would be a shell the size of a 25-pin serial connector (that's the "B" size) but with only 9 pins fitted.
Mostly True FTDI will give you 8 PID number of there VID for free.
You then edit the install and it says you. So for Linux
Then for 400 dollars for a Verisign Number and 100 to Microsoft It will ID your equipment and Download from Microsoft update ( FTDI has an app note).
Or you slap in a MAX232A and your done.
Funny, I just walked around my ICU and everything is connected via ethernet. Monitors (philips), ventilators (dragers) and of course the computers (windows). Even the dialysis (prismaflex) machines hook via ethernet.
The ultrasound has an ethernet cable attached as do the image intensifiers. The biochem lab also works over TCP.
Certainly nothing major in the hospital that I work in uses serial connections.
Maybe the older equipment used to use serial but given the amount of data shuttled around I don't think it would be feasible so use serial. Of course I can only draw experience from where I work, other hospitals may be different.
Charles
I've been developing for the Atmel ATSAM3U chip, which uses the ARM Cortex-M3 core. Its development board has serial ports, but I can reprogram the chip entirely, from full eraase, with just the built-in USB port.
When erased, the chip boots off an internal ROM. That ROM, if yo have a 12 MHz crystal hooked up, will activate the USB 2.0 Device port and make it look like a serial dongle. You talk to the thing via /dev/ttyUSB0 and download the program top flash through it. As a final step, you run a couple commands on it to switch the booting over to Flash. And you're done. If you want to erase the chip, there's an ERASE pin you pull down for 200 ms or so, and it's erased.
The dev board adds another twist to it. It has an onboard NAND Flash chip, which uses the built-in ECC unit on the SAM3U. If the development board is running the demo code, then that NAND Flash will show up as a USB thumb drive when you plug the board into your computer. So you can read and write the NAND Flash from your computer as if the ARM wasn't there. The board ships with its source code, binaries, and data sheets on that NAND Flash, just to prove its point.
This is where the future is going. RS-232/422/485 will become more and more niche oriented. Industrial apps that need more than 15 foot cables will still use serial ports.
But I doubt it'll always be a requirement for embedded work, I've found that using an FT232 USB-to-serial chip is the way to go in my embedded designs. It pretty much replaces the RS-232 transceiver chip, and doesn't need charge pump capacitors or funny voltages. You never need a null-modem adapter or gender changer. You never have to wonder what baud rate/parity/whatever is needed; just set that in the FT232's EEPROM. The chip hooks directly to TTL serial port pins that all microprocessors use. You can even choose if you want handshaking or not, and the FT232 can even drive activity LEDs for you. A USB Mini-B or Micro-B connector is far easier to find a home for than a DB-9. What's not to like?
I've been using serial ports for 25 years. I will NOT miss them.
Thats not 100% true. You can get a 16 PIDs from FTDI for free and use their programmer tool to replace their PID with yours. I did this for a biomedical device manufacturer we purchase equipment from. You still have to use their VID, and it takes a tiny bit of work to make the FTDI serial driver work with the new PID but its entirely doable.
"Software is getting slower more rapidly than hardware becomes faster." -Wirth
Lets see - I'm building a UAV using RS-422 for fly-by-wire operation using a RTOS and embedded hardware. Do I want TCP/IP or USB buffers involved on servos that control its ability to stay in the air? I can only imagine getting a lecture from an engineer at Raytheon about keeping things simple.
I wonder if someone will make a joke about selling Toyota Motor Corp a USB accelerator control...
It is most often sufficient to delete the Serial Port in the Device Manager and then run a scan for new hardware.
Look carefully. Sure, most don't use DE9 as it is a huge connector, but they will have the pins required for RS-232 signalling. A popular choice is RJ-45 (with frustratingly varying pinouts, requiring multiple RJ45 to DB9 conversion cables for a heterogeneous environment). Some use a mechanically mini-usb port that is actually RS-232 (Nortel comes to mind). I've even seen some equipment that did RS-232 signalling over 3.5 MM jack. I've also seen a number of wacky one-off form factors, whatever they can do to save real-estate and at least get transmit, receive, and ground lines out (5 pins if hardware flow control is desired).
XML is like violence. If it doesn't solve the problem, use more.