Maker Pro
Maker Pro

Is USART interrupts, error correction, & address detection necessary for my project?

max_torch

Feb 9, 2014
111
Joined
Feb 9, 2014
Messages
111
I have been learning how to work with the USART peripheral internal to mid-range PIC microcontrollers. Ive been working on a project. In the project there are 56 switches, 56 LEDS, two PIC16s, and two half duplex wireless transceivers designed for asynchronous UART. The states of the first 8 toggle switches are first scanned (involving CD4094 shift registers) by a PIC, and then this data is sent to a second PIC via the half duplex wireless asynchronous USART transceiver at 9600 baud, then this byte of data is shifted out to a shift register whose outputs are then connected to LEDs (works just like a FIFO), then the process repeats wherein the state of the next 8 toggle switches are scanned, sent, etc.. then when all 56 switches have been read, sent, and shifted out, the strobe pin of all the shift registers are given a pulse in order to update the LED display, and the whole process repeats.
A simulation in Proteus 7.7 is attached, the source files of both PICs, as well as a pdf of the circuit, in order to make things clearer. I assure you that the source code is heavily commented, you will not take ages to understand it, it is properly indented and makes sense even if it is written in assembly, best result if opened in MPLAB IDE.
TLDR: Im scanning 56 switches and sending their states via USART wirelessly to a second PIC then outputting the result to 56 LEDs. Handling of the 56 I/Os accomplished via shift register cascading.

The simulation and program already works, but I was wondering if I could/should improve upon it by adding more stabilizing/optimizing features.

By the way when the data is transmitted by the USART the sequence is:
start bit - 8bit data - optional 9th bit of data or parity - stop bit
Also this is supposed to run 24/7 in a cafeteria where the switches are contact sensors rather than pads.

First the issue of USART interrupts:
Basically there is an option to go to an ISR(Interrupt Service Routine) whenever a 9-bit/8-bit byte of data has been received. I read this is good for receiving data. I dont know how I would be able to make use of this feature, since each byte of data has to be shifted out anyway before I can start entertaining the next byte of data.

USART address detection:
There is an option to use a ninth bit (comes after data) for address detection. How important is this? Essentially this will prevent the PIC from accidentally accepting data that was transmitted wirelessly at the same frequency of the transceivers, no? I think the carrier freq is somewhere around 300 - 450 MHz

Framing error detection and correction:
If the stop bit was not detected at the time the PIC was expecting it a framing error occurs and some bit/s have to be set or cleared in order for the USART to start working again. But for the whole thing to start working right there would need to be some feedback to the first PIC to tell it to send the byte again, but my problem is that my transceivers are half duplex, so I would have to time the feedback to be sent at a time the first PIC isn't transmitting, and this feedback would have to be interpreted as an interrupt by the first PIC to prompt it to resend the byte that had an error?

Overrun error detection and correction:
The USART has a two stage buffer so if a third byte is received it while cause an overrun (just like stack overflow). Similar to above certain bits have to be cleared/set to get the USART working again and I guess some feedback would be requored to the first PIC in order to coordinate.

Even/odd parity checksum:
I am aware that I can have an even/odd parity to check if the number based if the number of 1s received was even or odd but why/should/how would I use this here?

If you read this thanks for taking the time,
 

Attachments

  • project.zip
    87.7 KB · Views: 53
Last edited:

dorke

Jun 20, 2015
2,342
Joined
Jun 20, 2015
Messages
2,342
I didn't read your code,but will answer generally:

==>"interrupts"
First thing to ask is:
other than what you described( PIC1=reading switches states and sending.PIC2=receiving states and driving LEDs ),
are the PICs doing anything else?
If they don't do anything else,
the "polling" of PIC2 is good enough and you don't need to use interrupts.
of-course,you need to take care that the switch scanning of PIC1 and sending the state isn't done too fast so the PIC2 has enough time to receive and process the info.
What is the scanning and sending rate of bytes?


"Framing error detection and correction"
In order to implement that you need to run a "protocol" over the serial usart transmission.
This would be a good and necessary thing to do, since if from any cause the "synchronization" of the 2 PICs is lost once ,
from that point on everything is "garbage" at the receiving side.
The simplest thing to do would be to send 2 bytes of data for each byte of status you are sending with PIC1.
First byte would be the # of byte status (1-7) and the second the status itself.
The receiving side would wait to get #1 and only than start to update the bytes received 1 -7 while checking that he gets consecutive numbers.
If any error occurs(including parity-see later) PIC2 will not update the LEDs and start again waiting for #1 byte.
You should take care to send from PIC1 with sufficient time between the 2 bytes for the PIC2 to read and act. .


==>"Overrun error detection and correction"
You should check for overrun error as part of a receive error.
correction is not needed if you implement the above "protocol".
You remain working in "one way transmit" from PIC1 to PIC2.

==>"Even/odd parity checksum"
You should check the parity checksum bit as part of a receive error.
The communication link may have errors from many causes,
in your case the simplest is from a Radio frequency interference effecting the wireless channel.
The parity bit is normally generated and inserted automatically in the transmitting uart.and checked automatically in the receiving one.
If the receiver detects an error it will set the parity error bit for PIC2 to know that the received byte is corrupted.
You should take care to work with the same parity type on both sides : odd or even.

hope this helps.
 

max_torch

Feb 9, 2014
111
Joined
Feb 9, 2014
Messages
111
@dorke
Nice tip about that "protocol". I will simulate it and breadboard both cases, the original and with the protocol and see how it goes. Thank you
 

max_torch

Feb 9, 2014
111
Joined
Feb 9, 2014
Messages
111
In order to implement that you need to run a "protocol" over the serial usart transmission.
This would be a good and necessary thing to do, since if from any cause the "synchronization" of the 2 PICs is lost once ,
from that point on everything is "garbage" at the receiving side.
The simplest thing to do would be to send 2 bytes of data for each byte of status you are sending with PIC1.
First byte would be the # of byte status (1-7) and the second the status itself.
The receiving side would wait to get #1 and only than start to update the bytes received 1 -7 while checking that he gets consecutive numbers.
If any error occurs(including parity-see later) PIC2 will not update the LEDs and start again waiting for #1 byte.
You should take care to send from PIC1 with sufficient time between the 2 bytes for the PIC2 to read and act. .
Just tried out your "protocol" Works like a charm. Thanks. Very helpful.
 
Top