As far as my understanding of computer ports goes,

  1. A serial port is a 9 pin plug such as the one showed here and it is also called a COM port.
  2. USB ports are a different standard from serial ports.

Why then do I often see USB ports called "serial ports" and, for instance in the Arduino IDE, USB ports are identified by the COM prefix? Also why is a virtual COM port sometimes needed if there aren't any serial ports involved? (Example: Prologix GPIB-USB adapter.)

This use of the same name for describing two different things I think can be a bit confusing.

Screenshot from the Arduino IDE, menu command Tools → Serial Port → COM14 shown

  • 2
    USB is serial comms.
    – Andy aka
    Commented May 6, 2017 at 14:17
  • 3
    Perhaps because you have a USB device that works as a serial port? Something that has one of those FTDI (FT232) or Prolific (PL2303) USB-to-serial chips, or perhaps an MCU with a software implementation of the same? Having them shown in the same namespace as the serial ports fixed on the motherboard (or in PCI(e) cards) makes the interface more straightforward to the software: it doesn't need to know how the port is physically implemented, just that it quacks like a serial port.
    – ilkkachu
    Commented May 6, 2017 at 18:51
  • 4
    It might help to realize that in the early days of the IBM PC and many of its predecessors, a "serial port" wasn't typically located on the motherboard, but was rather an interface on an expansion bus card. Today that concept remains relatively true in that there is still a distinct serial interface converter - only the "expansion bus" connecting it back to the computer is now USB, instead of the old ISA connectorized extension of the processor local bus. Commented May 6, 2017 at 18:56
  • 14
    Universal what Bus?
    – hobbs
    Commented May 6, 2017 at 18:57
  • 5
    @hobbs, that's right Universal Serial Bus. A bus. Very distinct from a serial port, isn't it? Even without the silly bold text.
    – TonyM
    Commented May 6, 2017 at 19:07

5 Answers 5


These aren't USB ports referred to as serial ports. In your example, the Arduino has a USB-to-serial device (either in the form of a second microcontroller, or an FTDI chip). This will use USB to communicate with the computer and form an actual serial port to the outside world - similar to USB Wi-Fi dongles, or USB LAN adapters, USB SATA adapters, etc.

The key is that in many cases, the serial port is not available directly to the user, as it is "hard wired" in the device (in this case, connected directly to the microcontroller you are programming).

In strict theory, any port using serial communications (almost any modern bus - including USB, which stands for "Universal Serial Bus", if my memory serves me) is a "serial port". However, in most cases, when people refer to "the serial port", they actually refer to a port that complies to RS-232.

  • 11
    Any time someone refers to a "serial port" they almost certainly mean RS-232 connected via a DE-9M connector. If people mean USB, they tend to say USB. Same for other serial protocols such as RS-485 or GPIB or the various flavors of Ethernet.
    – Felthry
    Commented May 6, 2017 at 14:18
  • 6
    @Felthry: "serial" very often means asynchronous serial signalling (the "A" in "UART") which RS-232 also uses, but at standard logic voltage levels, not RS-232. And may or may not include the handshaking pins which lead to the 9 pin (or 25-pin, which was the original for RS-232).
    – Ben Voigt
    Commented May 6, 2017 at 15:34
  • 2
    True. I suppose that's another layer of abuse of terminology, using 'RS-232' to mean a low-voltage variant of the protocol. I considered mentioning the DB-25M connector, too, but it's not really relevant here.
    – Felthry
    Commented May 6, 2017 at 15:38
  • 8
    @Felthry, sorry but "any time someone refers to a "serial port" they almost certainly mean RS-232 connected via a DE-9M connector" is an outdated PC-centric view. And PCs haven't been made with 9-pin connectors on the back for at least a decade. The mass populace of their users never touched them when they were. Products, equipment and PCBs all over the place use serial ports, through a variety of dedicated connectors and at LVTTL levels or RS-232C. And the engineers on this site'll experience serial ports far more ways than an old PC standard. Much diverser world than that, I'm afraid.
    – TonyM
    Commented May 6, 2017 at 16:28
  • 4
    @TonyM Perhaps I've just been around too much old-school equipment. I will note, however, that computers are still commonly made with DE9 connectors on them--just not for the consumer market. They're ubiquitous in industry and research, because you'll likely need to interface with systems that were made in the 90s or earlier, when they were common. People don't upgrade their industrial equipment like you'd upgrade your phone, after all! Like I said, it's an abuse of terminology. Perhaps "almost certainly" was too strong a wording, but it is a very common usage.
    – Felthry
    Commented May 6, 2017 at 16:36

It's confusing because Windows COM: ports come from a naming system defined back in MS-DOS (b. 1980). This was pretty-much copied from CP/M (b. 1974) with some ideas taken from Unix. They didn't anticipate the addition of an intermediate 'transport' bus like USB.

Quite a few things in Windows are survivors from the CP/M->MS-DOS evolution, such as letter-named disk drives, 3-letter filename extensions, .EXE and .COM files and the Command Prompt command interface.

Another is device names: generally three letters, always ending in a colon. COM: is a serial 'communications port', LPT: a 'line printer' (usually hanging off a Centronics port), NUL: dumps whatever's sent to it, CON: is the 'console' (keyboard and screen). Some that you could have several of get numbered to differentiate between them. COM: ports do, as do LPT: ports, becoming COM1: and LPT1: and so on.

A COM: port is an 'endpoint': the far end of the communications link from a Windows PC's point of view. Like many things in computing, the bridge there is ignored and it's the far end component you're thinking about, not USB. This is also true of a PC keyboard (linked as CPU-PCIe-USB-kbd) or a network drive (linked as CPU-PCIe-LAN-LAN-PCIe-CPU-PCIe-SATA or similar).

USB also uses the idea of endpoints. A USB controller can connect a host PC to all sorts of hardware and provide them to it as resources. So when you see the hardware attached by USB, you see these endpoints. A virtual COM: port in a USB device is simply a serial port coming out of that USB slave device as an endpoint. Windows will give it a number (COM1:, COM27: etc.) and that serial port can be recognised and used by any program using the standard Windows API for COM: ports.

Some USB-attached hardware might prefer to impersonate a serial port because it makes the development of the Windows software for it easier. No device driver needs to be written, which save a lot of work - the USB device tell Windows that it is a serial port. From the PC's point of view, this is fine if it behaves like a serial port (bytes are sent and received in an endless serial stream which is always open). So there are benefits for the developer.

  • 4
    I've never seen device names to end in a colon. In command line you also say e.g. type file.txt > lpt1 without any colon. And in the default Windows file manager, Explorer, you can't create a file named e.g. COM or LPT1 (at least in Windows XP, maybe later too). Where can one actually see the colon after device name?
    – Ruslan
    Commented May 6, 2017 at 18:05
  • 2
    @Ruslan, you're right that they're optional in Windows which has dropped them, it accepts both unlike MS-DOS. But having never seen them... (a) look up a text on MS-DOS devices; (b) in CP, type 'mode /?' and look at syntax of the command used to set COMn: and LPTn: port parameters, try them if you like; (c) in Command Prompt, type 'copy con: nul:' and watch it work (Ctrl-C to end).
    – TonyM
    Commented May 6, 2017 at 18:22
  • 1
    @Ruslan Colon is there because it's a device like any other. It's not the colon that's special - copy con:filename.txt nul works just fine, exactly the same as copy c:filename.txt nul. At least as far as MS-DOS 6.22, the colon can be omitted in most cases, since it doesn't introduce any ambiguity; unlike drive names, these devices have been reserved names, so you don't run into the problems of copy file.txt c (should I copy the file to the current directory on the c drive, or to a file named "c" in my current directory?).
    – Luaan
    Commented May 7, 2017 at 23:49

Your understanding of the difference between COM port and USB port is correct.

Short answer you your question, why some USB ports are mapped by OS as "COM" ports, is: there are USB devices that implement USB CDC (Communication Device Class). These devices provide a bridge from awfully complicated USB interface to a standard UART/RS-232 type interface. For transparency for users, operating system loads USB drivers that mimic the transport layer as COM port, a virtual COM port. Some historical details and justification for this approach follow.

The COM port uses DB-9/DB-15 (aka RS-232 serial, or UART) connectors, and controllers for these ports are physically mapped into PC hardware, to specific addresses in I/O space. This COM controller is getting obsolete in modern PCs, and goes extinct.

At the same time many MCU still use the RS-232 serial communication as main means to communicate with peripheral world. The reason is that the hardware (and software) for this kind of link is very simple and easy to implement. More, all modern Android development/debug communication is done in COM-port style. Also, many "communication" devices (as modems, including 4G LTE and above), still use the UART-style interface with ASCII-type control protocol over several "COM" ports.

Now developers have a dilemma, how to communicate with such micro-controllers if the host development PC has no COM ports? The solution was to use USB ports and special USB devices that bridge the USB protocol with COM-port RS-232 interface. There are dedicated USB device as FTDI chips, and many others (Cypress, Microchip, etc.) make devices that perform this bridge function.

Now, all native communication to these MCUs is still expressed in terms of RS-232 protocol, and most application examples assume the use of some Terminal application (TeraTerm, HyperTerminal, etc.) to use the link. For user convenience, the USB-to-UART bridges are provided with drivers that represent the port as a virtual COM port. All modern software uses virtualization of COM hardware, which provides smooth transition to "COM-less" PCs. It becomes a common practice to either add a dedicated FTDI bridge to UART ports on a MCU development platform (and use FTDI drivers on host PC to make the USB port look like COM port), or embed proper bridge code into the MCU itself (if it has native USB functionality).

The straight approach is to use an external USB-to-UART board and wire the UART to the MCU under development. Or, if a board already has the DB-9 connector, there are USB dongles that can be connected directly to it.

In all cases the native UART control of MCU will appear on host side as a virtual COM port, skipping all intermediate signal/protocol transformations. That's why people nowadays often skip the distinction between USB-to-UART bridges and COM ports.


To add to Joren Vaes's answer: be aware that some software apps (like Arduino IDE) install a Windows driver that creates "virtual COM" ports. When those ports are activated, the operating systems tells the programs that there is a COM port available, which looks like a standard serial port [*], to which programs (like Arduino IDE, but also any other) can send and receive bits like to any serial port. Under the hood, however, those bits are sent to a USB cable. Inside the Arduino board something analogous occurs.

[*] And, by "standard serial port" here we mean RS-232 protocol, the kind that was traditionally trasmitted via DB-9 or DB-25 connector. In our context it does not matter at all that USB is also "serial".


It is very confusing, but you don't need to worry about it. First off, think of a UART which itself is a generic term, but think of one that produces a protocol with a start bit, one or two stop bits, 7 or 8 usually data bits, and sometimes parity which is even or odd; it can vary from there which makes it that much worse.

The UART is at TTL levels, whatever that means. It used to be 5 V and now 3.3 V, 1.8 V or whatever; perhaps TTL is the wrong term. THEN you had/have RS-232, RS-422, etc. These are VOLTAGE AND PIN standards, not protocol standards. It is incorrect to mix the terms and say RS-232 when you mean some sort of UART.

Back in the day your UART was on your motherboards and you desired some sort of connector to the outside world with voltage levels that at the time made sense and some sort of standard pinout/cable. So a popular 25 and 9 pin standard was often found for various peripherals, and in the Wintel PC world this was called a COMmunication port or sometimes serial port.

Sure, a port that carries serial data can and is called a serial port, SPI, I²C, MDIO, UART, HDLC, SDLC, etc., and perhaps even USB and SCSI; you could go crazy with this. Usually a serial port means some pins you can get at a UART.

The Unix/Linux world says tty instead of com/serial/uart, but it is the same thing.

Now there is the IMPLEMENTATION. You can buy some UART chip with some interface on it (yep, you can have a SPI UART, which is serial on both ends, or I²C UART or some dedicated bus or USB, etc.). Even back in the day the UART had some bus on one side that ultimately the CPU was communicating through. Today we have FTDI and other vendors that make nice USB UART solutions, doesn't make it any different some layers of interface between the software and the UART and then the other side of the UART has some interface, be it TTL/chip level or RS-232C or RS-422, etc.

Early Arduinos you often used an FTDI USB-to-UART board that also provided power to the Arduino. Some have that USB power and serial/UART on the Arduino board itself and then that is hooked up across the board to the UART on the AVR chip (same deal some processor with some layers of buses to allow software to communicate with a UART which has some interface on the other side of it, in this case the pins on the edge of the AVR, at chip voltage levels, TTL).

Since the UART functionality has not changed in decades, why should the software terminology or even software applications change at the application level? Write a Linux/Unix TTY application 10-15 years ago against a UART chip on your motherboard, and there is a good chance it still works today with a USB to TTL level or USB to RS-232C level or RS-422 or whatever pin/level definition. The same goes for Windows, and I have code that old that still works on both. In the Windows world the term COM is used.

I have not used the Arduino sandbox in a while and if so would have been on Linux, but I wouldn't be surprised if that program which is Java, if I remember right, is generic and uses the system name so ttyS2 on Linux and COM2 on windows.

Re-reading your question this can go much further, taking advantage of the already existing amount of software that uses these API calls. Again for decades there is no reason why you can't create a virtual port in software that carries this bidirectional data down pretty much anything you can think of. UART to Ethernet is a very common one, and in server rooms where servers still very much use COM/TTY/RS-232 ports, you can have a terminal server which has a number of interfaces which you can connect to a number of servers, then Ethernet on the other side, then if you choose not to telnet in, you can install a virtual COM port driver.

Then your application on your computer thinks it is talking to a COM port, but in fact that stream of bytes is hopping onto Ethernet then hitting the terminal server, THEN, to a UART to RS-232C level (but not necessarily pinout) cables to the server and back the same way.

Sometimes there is no reason to actually make it to a real UART, for whatever reason virtualize a COM port so that software that was written for those API calls can still work. You could perhaps think about the ancient banking software we still use that has a dumb terminal to a UART interface that perhaps back in the day was hardwired or went into a modem to eventually a server. You can make it so that software still works, through various amounts of emulation including a virtual COM port that today likely just goes down Ethernet to the server as a serial stream (TCP/IP for example).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .