# Low level details for serial communication between UART of a microcontroller and PC [closed]

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, laptop2dMar 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.

• Most MCU datasheets give a detailed breakdown of how their USART works. – Ignacio Vazquez-Abrams Mar 6 '18 at 2:59
• 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 – jsotola Mar 6 '18 at 3:05
• 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. – jonk Mar 6 '18 at 3:30
• This is topic for a textbook or wiki site; not a Stack Exchange QA site. – Chris Stratton Mar 6 '18 at 4:17
• @gpuguy So I've written a little something for you. Hopefully, that helps you understand the basics. – 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.

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.