My Wired World‎ > ‎

Implementing UARTs in baseline and mid range PIC devices - An Experimentation

March 2011: Implementing UARTs in baseline and mid range PIC devices - An Experimentation

Although most of microcontrollers come with an inbuilt UART/USART peripheral, most of the baseline and mid range PIC devices don't have it (for example, PIC12F510 & PIC16F526). For hobbyist and amateurs, buying a new chip for performing a UART related function may not seem to be an 'economical' option. For such geeks, building an algorithm for performing this function may be an adventurous and interesting path.

The main point to consider while writing a code for UART implementation in such chips is the clock speed unless you are interfacing two PICs with a wired channel for a communication channel. But, if you are using a RF or IR channel in between, you need to check out the typical and maximum data transfer rates of those devices (RF & IR transmitters/receivers). I mean, the baud rates. For a typical 433Mhz Rx/Tx modules available locally, the typical baud rate specified is 1K bps. 

For a PIC16F526 device, you can select 4MHz clock built within. With this Fosc, the instruction execution frequency would become 1MHz (refer datasheet); which would result into an instruction cycle of 1microsecond. For this device, turning ON & OFF a bit requires one instruction cycle and hence, on a 4MHz clock source, it can communicate at a speed of 1000000 bps ( 1 / 0.000001). To make this device compatible with 33Mhz Rx/Tx device, you need to compress the instruction cycle by 1000 microseconds (1000000 / 1000 bps) = 1ms. 

Thus, with each transmission of bit, a delay subroutine of 1ms would be executed. If a data byte is packed in a packet of 4 bytes, with each byte consisting of 8 bit data, 1 start bit, 1 stop bit and 1 parity bit, the total transmission time would be 11x4 bits x 1ms = 44ms.

Another major concern area would be of frequency drifting. Although for small packet transmission/reception activities, it wouldn't matter, for large amount of data transfer, the issue must be addressed by inclusion of some 'synchronization link' periodically in the timeline. This synchronization link can either be continuous 0x00 or 0xFF for elimination of frequency drift.

Obviously, a rigorous filter algorithm can filter out the garbage from such transmission. A typical transmission/reception algorithm would be somewhat like this:

Transmission Algorithm:

1. Transmit a start bit. Transmit 0x99. Transmit a stop bit. (~10).
2. Transmit a start bit. Transmit 0x88. Transmit a stop bit. (~10).
3. Transmit a start bit. Transmit data. Transmit a stop bit. (~10).
4. Transmit a start bit. Transmit inverted data. Transmit a stop bit. (~10).

Reception Algorithm:

1. Poll for start bit.
2. Get 0x99. Goto step 1 if not received. (~8).
3. Confirm stop bit. (~1).
4. Receive start bit. Goto step 1 if start bit is absent. (~1).
5. Get 0x88. Goto step 1 if 0x88 is absent. (~8).
6. Receive stop bit. Goto step 1 if stop bit is absent. (~1).
7. Receive start bit. Goto step 1 if start bit is absent. (~1).
8. Get data bit. Save it in register R1. (~8).
9. Receive stop bit. Goto step 1 if stop bit is absent.(~1).
10. Receive start bit. Goto step 1 if start bit is absent.  (~1).
11. Get inverted data bit. Save it in register R2. (~8).
12. Receive stop bit. Goto step 1 if stop bit is absent. (~1).
13. Confirm Data Authenticity by Logically ANDING R1 & R2. Result should be 0x00.

I hope, I must have excited somebody..!  :-)

Later,
Pratik.
Comments