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,
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
Last edited: