Serial Uart
Lirim Collard
In UART communication, two UARTs communicate directly with each other. The transmitting UART converts parallel data from a controlling device like a CPU into serial form, transmits it in serial to the receiving UART, which then converts the serial data back into parallel data for the receiving device. Only two wires are needed to transmit data between two UARTs. Data flows from the Tx pin of the transmitting UART to the Rx pin of the receiving UART:
UARTs transmit data asynchronously, which means there is no clock signal to synchronize the output of bits from the transmitting UART to the sampling of bits by the receiving UART. Instead of a clock signal, the transmitting UART adds start and stop bits to the data packet being transferred. These bits define the beginning and end of the data packet so the receiving UART knows when to start reading the bits.
When the receiving UART detects a start bit, it starts to read the incoming bits at a specific frequency known as the baud rate. Baud rate is a measure of the speed of data transfer, expressed in bits per second (bps). Both UARTs must operate at about the same baud rate. The baud rate between the transmitting and receiving UARTs can only differ by about 10% before the timing of bits gets too far off.
The UART that is going to transmit data receives the data from a data bus. The data bus is used to send data to the UART by another device like a CPU, memory, or microcontroller. Data is transferred from the data bus to the transmitting UART in parallel form. After the transmitting UART gets the parallel data from the data bus, it adds a start bit, a parity bit, and a stop bit, creating the data packet. Next, the data packet is output serially, bit by bit at the Tx pin. The receiving UART reads the data packet bit by bit at its Rx pin. The receiving UART then converts the data back into parallel form and removes the start bit, parity bit, and stop bits. Finally, the receiving UART transfers the data packet in parallel to the data bus on the receiving end:
The data frame contains the actual data being transferred. It can be 5 bits up to 8 bits long if a parity bit is used. If no parity bit is used, the data frame can be 9 bits long. In most cases, the data is sent with the least significant bit first.
Parity describes the evenness or oddness of a number. The parity bit is a way for the receiving UART to tell if any data has changed during transmission. Bits can be changed by electromagnetic radiation, mismatched baud rates, or long distance data transfers. After the receiving UART reads the data frame, it counts the number of bits with a value of 1 and checks if the total is an even or odd number. If the parity bit is a 0 (even parity), the 1 bits in the data frame should total to an even number. If the parity bit is a 1 (odd parity), the 1 bits in the data frame should total to an odd number. When the parity bit matches the data, the UART knows that the transmission was free of errors. But if the parity bit is a 0, and the total is odd; or the parity bit is a 1, and the total is even, the UART knows that bits in the data frame have changed.
And as always, let us know in the comments if you have questions or anything else to add! If you liked this article and want to see more like it, be sure to subscribe- we send out an email when ever we publish new posts.
Its Beautifully Explained. Frankly Speaking, After a hell lot of search over Internet and books, THis is the only Place where I literally Understood what Exactly UART is and its working.
Thanks a Lot guys.
A request: can you write another article to Explain How Exactly an IC (made of transistors) Adds these bits (Start,parity,stop) and Removes them. I mean how exactly they do this intelligent stuff at Electronics level ? Please explain its Circuit basics. :)
Your analysis is correct. That is why parity checking is rudimentary and may not prevent all errors. But the odds of two bits being changed is much higher than just one so this method works in most cases of low level hardware communication.
very good expaination. I have one question that we also use Usb micro port for connectiing uart hardware and the other USB port type A to our laptop. How does it work? does uart support USB ports also?
Thank you soo much.. Thanks a ton. Really U ppl had done a great job. Now seriously I understood the working principle, data transmission of bits and everything without any doubt. Thanks again and again. Hope you upload more and more sessions and concepts like this.
If the transmitter or receiver differ significantly enough in this measurement because they have such different baud rates configured, then the rate at which the transmitter alternates its TX pin and the rate that the receiver samples its RX pin means you either miss entire bits, or read the same bit more than once.
In the United States,cooking gas cylinder two grades of liquefied petroleum gas are mainly sold: commercial propane and HD-5. Propane/butane mixtures are also listed in these specifications.
Propylene, butene and various other hydrocarbons are also commonly present in small concentrations. HD-5 will limit the propylene content that can be placed in LPG to 5% and be used as an automatic gas specification.
As you explained above
In parity check when ever the UART Rx will get to know that the data frame had changed, will it send a request for original data frame or what it is going to do after knowing the data frame had changed ??
I have No knowledge of electronic communication.
Your UART explanation has opened a new window.
Can you help setting these Data Packets for the Coordinated Action.
Alternatively direct me to someone that can help me with this project.
Thank you
Cassim
E:guru...@gmail.com
I am stumped, I don't know what I changed. I had things working fine and then one day I woke up and for some reason UART RX interrupts started crashing the CPU (PC off in the weeds). The crash happens when I call this function:
uart_receive(UART2, uart_rx_buff, READ_CHAR_COUNT, UART_OP_INTR);
More specifically when I step into that function it crashes here when interrupts are enabled for UART2:
I must have done something dumb somewhere but I can't see it. Can someone take a quick look at my project? I've been following the UART example project closely, I don't understand what I did. Thanks in advance!
Hi Erik,
Thank you for posting your question online.
I tried to use the ble_app_ota.zip you attached.
The project was not compiling since you had comment out the USER_DEVICE_NAME and USER_DEVICE_NAME_LEN inside the user_config.h file.
After that I could compile your project with no errors. I ran your project, but it was not advertising. It seems that it crashes inside arch_main.c file while waiting for the scheduler. Have you made any changes inside the SDK folders?
When you run the example attached does it advertise on your end? Have you tried using the uart_receive function inside a clean project and it does not work?
Kind Regards,
OV_Renesas
why would enabling interrupts on UART2 cause a crash? I thought maybe the interrupt was firing off too fast and possibly re-entering or something, but I don't see that an interrupt is happening at all. It seems to just crash
Hi Erik,
We strongly recommend to NOT change any files inside the SDK folders.
You should work on the user folders in order to build your application.
In your project does it advertise? Can you share again your project inside a zip so I can try to debug it.
Kind Regards,
OV_Renesas
Okay, well, if I wanted to pull the device name from an EEPROM then I would need to edit the SDK file app.c right? This seems like a very basic need - we want to be able to change the device name. Using a #define for the name won't work for our needs.
Anyways, yes, here is the latest .zip. Thank you very much for your help. It's such a weird issue
If you want to inspect my whole SDK folder you can message me and I'll invite you to the git project. The whole SDK is too big to share here. But I will also try a fresh download from the website of the latest SDK, just in case the one in my Downloads folder a while back was modified (I pretty sure it wasn't, but I will check). I checked and that is not the issue...
Okay, so I found something interesting. I've been using the Segger J-link Base debugger for my development. But now I switched over to the dialog eval kit (modified to be a j-link programmer) as a programmer and programmed a different PCB and the project works fine. So, either there is something about my particular hardware PCB, or the Segger j-link Base debugger is not setup properly. Here is the relevant schematic, we are running off 1.8V
Hi Erik,
I was able to compile and run the second project you send me. I could use uart without any crashes.
Since you found that the problem is either in the PCB or with the Segger j-link Base debugger this is not a problem of the Uart Driver.
I will check the schematic you attached.
Note: We highly recommend to NOT change the SDK folders. We support the SDK in the form given by Renesas.
You can use the user folders to call the APIs you want to use from the SDK.
Kind Regards,
OV_Renesas
Can you try it at 1.8V? That's the other difference besides my debugger. The J-link base debugger works fine now if I use 3.3V supply, but once I bring the supply down to 1.8V things start crashing again and advertisements are not working. Is there some configuration that I missed for 1.8V operation? The strange thing is that if I program at 3.3V and then bring the voltage down to 1.8V it works fine. But if I program at 1.8V then nothing works. It's like programming is failing at 1.8V using this j-link base debugger. And with the dialog evk programmer its fixed at 3.3V so I can't test it at 1.8V.
There is the forum post Can't connect serial port - Error: ch341-uart disconnected from ttyUSB0. It seems for an Arch Linux/Manjaro system (I am not sure if it is suitable for other distribution), you need to remove some udev rules.
c80f0f1006