I want to understand how exactly full duplex serial communication between UART of a microcontroler and PC com port actually happen ? I have used applications where a single UART( single Rx, Tx pins) is used for sending data from a GUI and at the same time receive continuous stream of data from PC and display on GUI ( refreshing it every 500 ms). Is this really full duplex ?

I will really appreciate if someone can enlighten my how internally data flows from micro to PC and vice verse using single Rx and Tx pins. I really want to understand how it actually work at hardware level. (I am not looking for a sample code though)


closed as unclear what you're asking by Chris Stratton, Finbarr, Andy aka, RoyC, Voltage Spike Mar 6 '18 at 19:07

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    \$\begingroup\$ Most MCU datasheets give a detailed breakdown of how their USART works. \$\endgroup\$ – Ignacio Vazquez-Abrams Mar 6 '18 at 2:59
  • 1
    \$\begingroup\$ the data flows over two separate circuits ... there is a transmitter at one end, and a receiver at the other end. ... the transmitter and the receiver can be on the same device if you loop the output (connect Rx and Tx) then any output from the device will be received by that device ..... imagine two people on a hill, and two others on another hill where the two groups can see each other ... one person operates a flashlight and sends morse code ... the other person watches for light flashes from the other hill .... that kind of setup allows duplex communication between the two groups of people \$\endgroup\$ – jsotola Mar 6 '18 at 3:05
  • \$\begingroup\$ Is this a usb connected device? Because there aren't many pcs anymore that have a genuine serial port using rs232. Just want to be sure what you are taking about. \$\endgroup\$ – jonk Mar 6 '18 at 3:30
  • \$\begingroup\$ This is topic for a textbook or wiki site; not a Stack Exchange QA site. \$\endgroup\$ – Chris Stratton Mar 6 '18 at 4:17
  • 1
    \$\begingroup\$ @gpuguy So I've written a little something for you. Hopefully, that helps you understand the basics. \$\endgroup\$ – jonk Mar 6 '18 at 7:45

A lot of this is about software, not hardware. I'll provide a simple overview, that doesn't get too far afield. (My background is having read almost 1000 pages of the USB 2.0 specification and having used many such USB connected devices. I also have some background with Windows drivers.)

I will really appreciate if someone can enlighten my how internally data flows from micro to PC and vice verse using single Rx and Tx pins. I really want to understand how it actually work at hardware level. (I am not looking for a sample code though)

There is a process for a USB device to enumerate itself via USB. For the Windows operating system, the process can be found here: How does USB stack enumerate a device?. That web page will give you a good overview of the enumeration process followed by Windows and some of the reasons why that process is followed. So I won't try and duplicate what has already been done far better than I could have written, here. Read that page and get an overview of that process.

Without getting into a lot of details, a USB device can have multiple endpoints and they can be of several types. The host operating system doesn't really care. It just goes through a process of enumerating them so that they can act according to their descriptions. So you may have a composite USB device that enumerates as both HID and MSD, for example.

For many demo boards, there is a separate IC (or several) related to providing the interface into the USB host operating system. For example, if you buy a TI MSP430 demo board, with a socket for a variety of MSP430 DIP devices, there will also be a separate USB section on the board, too. This section includes a special MCU (you can see it, so just look) that handles all of the USB enumeration details that you are NOT told about when you hook it up to the USB host computer.

One endpoint that this preloaded MCU enumerates will be used for debugging the MSP430 DIP chip you can add to the board. You won't get much information about this USB endpoint or the commands and queries that it handles. That's because TI doesn't document the debugging interface (publicly.) So this USB endpoint communications will be handled by a driver arranged on the USB host side, plus software preloaded onto that special MCU on the demo board side. This debugging endpoint allows special software and debugging protocols, almost always undocumented, to use the debugging portions of the JTAG interface (or similar) that resides on your DIP MCU in the demo board. So debugging software gets its job done by using this particular "back channel" USB endpoint. You will NEVER get much info on this particular endpoint without first proving you have a need to know and then also signing your life away. (Sometimes, you can get information about how to download code into a device. So you get information on part of this interface, at times. Also, ARM CPU JTAG debugging, by contrast, is documented. However, custom peripherals added by manufacturers to the ARM CPU may not be documented well.)

However, this special MCU also handles another endpoint for you. This will be a virtual COM port (HID) endpoint. So the host OS sets up a virtual COM port driver designed to present a "standard" COM port interface that can be used by software running on the USB host computer (PC) side. Any software you write on that PC computer will "talk" to this driver as if it were a "real" COM port. It's not. It's just software. There is NO hardware associated with this virtualized COM port on the host PC. It's a "virtual" COM port, after all. All that happens is that stuff you do with this virtual COM port get's turned into USB endpoint communications (in and out.) Similarly, what your PC software does in configuring that port also gets passed along to the demo board's USB-handling special MCU via this virtual COM port endpoint link in little packets that tell it what the PC software is asking to have done. Some of this just gets swallowed up by the special MCU and is stored internally so that it knows what's expected, later. For data, to be exchanged over the TX and RX pins, the special MCU then acts as if it were an external serial device hooked up to your DIP MCU's TX and RX pins. (The special MCU works its own pins to drive and receive from your DIP MCU pins.) This information is turned into USB packets, though, for exchanges between the host PC and this special MCU handling the USB interface to the PC.

So, as far as your newly programmed DIP MCU can tell, it is in fact talking to a serial device via TX and RX. It does so without all the usual RS-232 voltage requirements, using instead the local \$V_\text{CC}\$ power supplies present on the board. But your software doesn't care. So long as the TX and RX pins "appear" to be talking to something which handles things correctly, all is well and your software "just works" like it is supposed to work.


The use of bit rates (often incorrectly called "baud" here) configured on the PC side software using the usual configuration software calls have NO AFFECT AT ALL on the USB endpoint communications. USB works by a completely different set of communication mechanisms. So the host PC and your demo board's special MCU communicate via USB and the bit-rate configurations are passed along regardless. It is then the job of the special MCU on the demo board to "configure" itself so that it uses the right timing details to act as if that bit rate was selected. But subsequent data transmitted from the host PC software towards the demo board ALWAYS arrives perfectly well and intact, regardless of the set bit rate for the serial communications. By this, I mean it always arrives to the special MCU just fine. However, the special MCU now has to bit-bang the pins at a certain rate to your DIP MCU, which it does. If the rates aren't matched correctly, this has the same problems you'd normally expect. But these problems only occur between the special MCU and your MCU, but not between the host PC and the demo board's special MCU.

  • \$\begingroup\$ This explains a lot. I have few cross questions regarding Transmit Buffer and receive Buffer. Where do they come into picture ? Are these the buffers in special MCU ? \$\endgroup\$ – gpuguy Mar 7 '18 at 2:08
  • \$\begingroup\$ @gpuguy If you use library code you did NOT write in your own MCU then the buffers are allocated in your MCU by that library code. If you are writing your own TX/RX code in your MCU, then you already know about them since you made them. But there will ALSO be buffers in the special MCU, since it needs to package the communications using USB methods. There will also be buffers in the PC driver as well. Together, all this adds a great deal of "slop" in the timing between the moment you transmit and the moment PC code receives a char, and visa versa. But few care. So there it is. \$\endgroup\$ – jonk Mar 7 '18 at 5:11

Not the answer you're looking for? Browse other questions tagged or ask your own question.