UART to Serial Terminal (reprint)

The previous "UART explained" introduced the basic information of the UART, focusing on the signal of the UART. The article excerpt from this article focuses on the baud rate (Baud rates) related content, the higher the baud rate, the faster the transmission speed, but the actual use of the baud rate is higher the better, how much appropriate? The answer is given in the text below.

Although the PIC32 is an elegant and powerful microcontroller, it doesn ' t stand as tall when compared against a PC in term S of raw Computing power! Sometimes it makes sense to use the feasability of the microcontroller to work as a sensor or an embedded controller of so Me type but still is able to communicate with a more powerful computer. Sometimes might just want a quick visual display or a printf terminal for debugging. Whatever the reason, this tutorial would provide a basic guide to PIC32/PC communication.

Uart

The module used for such communication is the PIC ' s Universal asynchronous Receiver/transmitter (UART) pronounced "you-art ". For those familiar with computer music, the MIDI protocol uses a UART-to-do its serial communication. For those familiar with the Arduino, the Tx/rx pins on an Arduino is the the and the main UART pins. In its more basic form the UART hardware consists of a transmit (TX) line and a receive (RX) line. The software configures how fast data was sent (the baud rate) and the specifics of the protocol.

Baud Rate

　　Since The UART module is asynchronous, there are no external clock line like the synchronous protocols SPI or I²C. Instead, both communicating devices must has their own clock sources configured to the same frequency. As long as these clocks match one another, data should be transferred smoothly. On the PIC32, the UXBRG special function register configures this rate called the baud rate. Note that the x in UXBRG are a placeholder for the reference number of the The UART, which is being configured. Common baud rates include 4800, 9600, 19200, 57600, and 115200 bits/s. Different baud rates can be chosen by the PIC32 You must always make sure both devices is very stable at the selected. Sometimes it's best to select a lower baud rate to reduce the chance of errors. Since there is no shared with clock, the hardware is simpler and there is a increased chance for the clocks to being out of sync causing incorrect data to is interpreted on the receiving end. For this reason, lower baud rates likE 9600 is very popular.

The equation to configure the baud rate using the UXBRG register is below:

8N1

　　Like with most peripherals, the configuration options can overwhelming! We are configuring our UART to use the standard 8N1 format. 8N1 meaning that each data trasfer consists of 8 bits of data, no parity bits, and 1 stop bit.

　　The parity bit provides an added layer of error detection. The parity bit is generated by the transmitting unit through a calculation do with the data being sent. If the receiving unit then calculates the same parity bit from the received data, it's assumed that everything is a-o-k. If a different parity bit is calculated, an error is triggered. For example, if odd parity checking are used, the transmitting unit would add up all "1" bits from the data being sent and Set the parity bit to 1 if they is odd (like 01001100) or to 0 if even (like 01001101). The receiving unit would use the same calculation and compare the received parity bit to the calculated parity bit. Note that parity checking was done with hardware by the UART unit. However, once a parity error is flagged by the hardware, the programmer must deal with the error in software. Since parity checking would only take the you so far (the corrupted bits is treated as no error!), you may desire something mor E powerful like a Cyclic Redundancy Check (CRC) which is outside the scope of this tutorial.

The stop bit signifies the end of a data transfer. There'll almost always be either one or both stop bits. If the stop bits read by the receiving unit don ' t match those expected, the receiver would assume its clock drifted out of Phase and a The software must deal with this error. It is also implied, a start bit is being sent as well with each transmission. The start bit allows the clock on the receiving end to does a phase lock with the data being received. Otherwise, the receiving end might end up sampling on the data transition edges instead of right in the middle of each bit . The data received would then look like utter nonsense!

So, under an 8N1 configuration, each of the bytes of data sent is transmitted in the form of a 10-bit frame with the addition of one Start bit, one stop bit, and no parity bits.

The example below configures the PIC32 ' s UART1 module to an 8N1 format with a baud rate of 19200 bits/s and enables both T Ransmit and Receive functions (in full duplex mode).

int FPb = 40000000; //Peripheral bus clock frequency set at max sysclk int Desired_baud = 19200; U1mode = 0; //Disable Autobaud, TX and RX enabled only, 8N1, Idle=high U1sta = 0x1400; //Enable TX and RX U1BRG = (FPb / (1*Desired_baud)) - = 0x8000; //enable UART1

Note in the example above, we is using the standard baud mode set whenuxmode< 3> = 0. The UART clock is a able to take in specific frequencies and this bit helps determine how close the desired baud rate W Ill is to the actual baud rate. When Brgh = 1 (i.e. uxmode<3> = 1), high-speed mode was activated and the actual baud rate would probably be closer to The desired baud rate. However, each bit received on the UXRX pin would only be sampled once. When Brgh = 0 (i.e. uxmode<3> = 0), multiple samples be taken on the UXRX pin to determine whether a high or low is Present. Even though the high-speed mode may has a more accurate baud-clock, in Standard-mode there are less chance-make re ceiving errors. See the UART Reference manual sections 21.6 for more information.

The following table provides a set of desired baud rates, the value of the would set Brgh to for this baud rate and the error .

　　Can be seen, the actual baud rate and target baud rate will have some errors, if the communication both sides of the error is a bit large, it is easy to lead to communication errors, so many serial communication protocol will have check code, such as GPS protocol, through the data frame check code can filter out due to transmission errors, avoid anomalies.

The original text also has the reference code and the debugging serial port artifact, see in detail: http://umassamherstm5.org/tech-tutorials/pic32-tutorials/pic32mx220-tutorials/ Uart-to-serial-terminal

In addition, a detailed analysis of serial communication timing errors can be found in: http://www.robotroom.com/Asynchronous-Serial-Communication-2.html (as if the wall, pdf when this)

Baud Rate calculation tool: http://mspgcc.sourceforge.net/baudrate.html

UART to Serial Terminal (reprint)