atommic22 wrote:Is there any way to get an 8 bit output with these PICs? Or would I have to go to the 18F series that use more pins?
The 16f687/689 have an 8 bit wide port (PORT C) if that is what you mean. It is a 20 pin chip. I am using it for a serial port box project now.
( I am now going to repeat what I said in an earlier post)
I have done a similar project to the one you are doing. Instead of just sending the PORTA values, consider sending the following:
Code: Select all
USART_Write(49); // 1 - preamble/sync byte
USART_Write(49); // 1 - preamble/sync byte
USART_Write(49); // 1 - preamble/sync byte
USART_Write(65); // A - Look for this byte as the start of your data
USART_Write(PORTA); // Your Data
USART_Write(66); // B - Look for this byte as the end of your data
USART_Write(35); // # - push one more byte through
Delay_ms(45); // my project worked better with this delay here?
Save the data in an array (ie. char rxdata[2]) and if rxdata[0] = "A" and rxdata[1] = "B" then you can be pretty sure that rxdata[1] is what you want.
You are very, very likely to get a lot of noise on your receiver and get a lot of garabage data coming into your USART rx pin and you have to find your data in that mess. The above example helps you find it.
The receive end might look something like this:
Code: Select all
while (1) {
if (USART_Data_Ready()) { // if data is received
i = USART_Read(); // read the received data
if (i == 65) { // is it and "A" ?
rxchar = 0;
while (rxchar < 3) {
if (USART_Data_Ready()) {
rxdata[rxchar] = USART_Read();
rxchar ++;
}
} // end while(rxchar)
if ((rxdata[0] == 65) && (rxdata[2] == 66)) {
PORTA = rxdata[1];
rxdata[0] = rxdata[1] =rxdata[2] = rxchar = 0;
}
} // end while
It is not the exact code I used but I tried to strip it down so it is legible. There may be parts that don't work but it should give you guidance.
It will work better in an interrupt routine but you may not be ready for that yet. Also a reset timer would be good to kick me out of the routine if I geet an "A" as noise and no other "noise" comes in before the real signal but then that is another reason to have the preamble of "1"s at the beginning.