PIC talks UART

Overview

This article is about connecting two PICs via their UART. If you need to know about UARTs just Google that up, if you want to see them up close … read on!

Serial communication is something that has been around for quite some time and it is still very present today in many shapes and forms. When working with embedded systems knowing how to use the UART is of the utmost importance. The UART can be used for micros to talk to each other, for a micro to I/O to a terminal running on a PC, to interface to devices like a GPS module or a Zigbee or an infrared module.

For this article we will be using two PIC16F887 40 pin PDIP and compile the code with MikroC and Microchip XC8. We will be using two Mikroelektronika’s EasyPICs boards for the preparation of the material but we will also provide instructions on how to achieve the same results on a breadboard.

---

 The communication

At the wires level the two PICs will interface using PINs 25 and 26. These are the PINs reserved as TX and RX.

They are respectively RC6 and RC7 of port C in the block diagram below.

The signal generated should look like the one below. Bear in mind that our PICs will use simplex asynchronous communication. Wikipedia’s Universal asynchronous receiver/transmitter has additional information.

The line is kept high until the transmission starts bringing the line to low and logic 0, then 8 or 9 bits are transmitted. The packet is terminated with a stop bit which is always 1. In this way the signal is brought back to high. Further details on the inner workings of the UART module can be found in the Serial Communication Modules of Mikroelektronika e-book and in Microchip PIC Mid-Range USART.

---

 The circuit

Our circuit will be as follows, we are connecting the PICs so that the TX on PIC1 is connected on the RX on PIC2 and vice versa the TX on PIC2 to the RX on PIC1. This configuration is also known as NULL-Modem.

Just to make things easier in order to replicate the circuit on a breadboard, we have provided a BOM and a description of the breadboard set-up in another article … “40-pin (6F887) DIY Protoboard“

Once the breadboards are ready and connected, they should look like this

---

The Code

The aim of the program on PIC1 is to send a “Hello, world!” message to PIC2 so that the program running on it can display the message on its LCD.

The TX side will first of all set the baud rate, in this case to 9600 bps, then enter an endless loop in which it will write “Hello, world!” and “From 0xEE.net” to its UART at 1 seconds intervals. Between each message a character 10, representing a linefeed, is also sent as a terminator.

UART1_Init(9600);               // Initialize UART module at 9600 bps
  Delay_ms(100);                  // Wait for UART module to stabilize

  while (1) {                     // Endless loop
        UART1_Write_Text("Hello, world!");   // 0x48 0x65 0x6C 0x6C 0x6F 0x2C 0x20 0x77 0x6F 0x72 0x6C 0x64 0x21
        UART1_Write(10);                     // 0x0A
        delay_ms(1000);                      // Wait a bit
        UART1_Write_Text("From 0xEE.net");   // 0x46 0x72 0x6F 0x6D 0x20 0x30 0x78 0x45 0x45 0x2E 0x6E 0x65 0x74
        UART1_Write(10);                     // 0x0A
        delay_ms(1000);                      // Wait a bit
  }

The RX side will setup the baud rate to match the one from the TX PIC and then simply stay in an endless loop waiting for data to be ready. If some data is received. Each byte representing a character gets stored in an array of characters until a n or linefeeld is received at which point the array is considered complete and ready to be displayed on the LCD via the next line.

UART1_Init(9600);               // Initialize UART module at 9600 bps
  Delay_ms(100);                  // Wait for UART module to stabilize

  while (1) {                                     // Endless loop
    if (UART1_Data_Ready()) {                     // If data is received,
       UART1_Read_Text(received,"n",255);        // Store in received everything before a linefeed
      Lcd_Out(1,1,received);                      // Display received on the LCD
    }
  }

In the XC8 version of the program as shown in the snippet below the bulk of the work for receiving is done in the interrupt service.

void interrupt ISR() {

    if (PIR1bits.RCIF)          // see if interrupt caused by incoming data
    {
        char temp;
        temp = RCREG;     // read the incoming data
        PIR1bits.RCIF = 0;      // clear interrupt flag

        if(temp=='n')      //if EOL
        {
            index = 0;
            new_rx = 1;             //"ding"
        }
        else if(temp!=1)           //in middle of string
        {
            rxtxt[index] = temp;         //load it up
            index++;                    //increment index
            if(index > 19)              //that's more than enough data
                {
                index = 0;              //reset index
                new_rx = 1;             //"ding"
                }
        }

        //
    }

}

 The Results

We thought it would be a good idea to give a bottom up approach to analysing what happens during the communication. Much like the ISO/OSI model will look at the different layers from the wires and the voltages up through to the message that gets displayed on the LCD.

Oscilloscope

The oscilloscope is a useful tool to look at voltage levels in the time domain. The scope displays the level from the input from the left to the right. Shown in the screen-shot is the ASCII letters “Hello”. We used a single sequence trigger to capture this sequence of the message. If you use a free-running rising-edge trigger it is difficult to determine what part of the message you are looking at. Note that there are very low levels of noise on the line. If there is noise on your UART communication lines you would find it with an oscilloscope as the oscilloscope is displaying actual voltage levels. In this case each major division horizontal  grid marking represents 2.0V with the middle horizontal marking set up as the 0V reference;  The vertical grid lines indicate time.

Logic analyser

One step above the voltage levels measured by the oscilloscope we can position the logic analyser which will interpret the changes of the voltage as logic levels. Depending on the type of signals and the electronics involved, the values will be interpreted as high and low or logic 1 and 0.

Protocol decoding

In order to better understand the results from the protocol decoders of both the logic analyser and the bus pirate, we can refer to the following ASCII table. The values displayed by both tools are both in hexadecimal.

Logic analyser decoding

A part from looking a bit more squeezed, the picture below is the same as the one obtained using the logic analyser,

it is only by inspecting it with a packet decoder that the next level of abstraction will be unveiled.

By using the hex column of ASCII table above we can already make sense of the packets by matching the numbers with the characters. It is with no surprise that the sequence above reads “Hello, world!” plus a line feed character at the end.

If you are so bold/mad as to look at the logic levels from the wave above, you will notice that the sequence for the “H” character has to be read from left to right to make sense. The “H” character is 0x48 in hexadecimal which in binary translates to 0b01001000. This should be made more evident by looking at the following picture which breaks down the packet sent into its 10 bits.

Note the duration of each byte sent. At 9.600 kb/s we are sending 9600 b/s. The adjustment made by the baud rate generator produced an effective baud rate of 9.615 kb/s.

9.615 kb/s = 9615 b/s = 9.615 b/ms = 0.009615 b/us
The packet is composed of 10 bits and it takes 1.039 ms to send according to the logic analyser. This means that 1 bit takes 0.1039 ms or 103.9 us. The rate calculated from this yields 0.009624 b/us or 9.624 kb/s which is, rather obviously, very close to the baud rate set by the micro. Hurray!

Bus Pirate

Much like with the previous tool, when using the bus pirate in UART mode we can decode the message sent by either reading each byte sent

 

Note that the sequence captured on the left is inverted as “From 0xEE.net” comes before “Hello, world!”

while (1) {                     // Endless loop
        UART1_Write_Text("Hello, world!");   // 0x48 0x65 0x6C 0x6C 0x6F 0x2C 0x20 0x77 0x6F 0x72 0x6C 0x64 0x21
        UART1_Write(10);                     // 0x0A
        delay_ms(1000);                      // Wait a bit
        UART1_Write_Text("From 0xEE.net");   // 0x46 0x72 0x6F 0x6D 0x20 0x30 0x78 0x45 0x45 0x2E 0x6E 0x65 0x74
        UART1_Write(10);                     // 0x0A
        delay_ms(1000);                      // Wait a bit
  }

 

 

 

 

 

 

 

 

 

or by reading the raw UART input

Note the linefeed that we have inserted at the end of each message.

Follow the link should you want to know more about sniffing UART packets with the Bus Pirate.

LCD output

Finally our message gets displayed on the LCD connected to PIC2 gets displayed!

---

Final thoughts

At the end of this article you should be able to have two PICs talking to each other via their UART whether you are using MikroC or Microchip XC8. With some basic understanding of the protocol we can now move onto connecting to other devices or using different media to achieve the same communication. We will add a number of spin-off of this article as soon as we manage to put them together. Stay tuned!

We hope you add fun and in doing so also learned something new. Please get in touch through the forums, we’ll do our best to answer your questions, cherish your advices and, why not, learn something more.