problems with 115200 baud on a 16F877

[MDP]

Hi,

I have been experiementing with PIC for my first time lately. I need to implement a data demultiplexer that reads in a data stream on one port, strips off certain section of data and sends it out another port. However, I have been having severe problems getting this to work at 115200 baud.

I am using a 16F877 (20MHz) and the CCS development board that comes with the kit.

The RS232 streams are dfined like below:

#use rs232(baud=115200,xmit=PIN_C6,rcv=PIN_C7,stream=MAIN)
#use rs232(baud=115200,xmit=PIN_C4,rcv=PIN_C5,stream=OUTPUT)

The code I am using is very simple:
- check the main port with kbhit()
- gets a char on the MAIN stream
- outputs the char on the OUTPUT port stream

When I reset the PIC it will output a couple chars and stop. I lowered the baud rate to 38400 and it works better but often hangs again after a few seconds and needs to be reset to start again.

Is it possible to do 115200 baud with this PIC at 20MHz??? If so, can anyone shed any light on what may be happening?? :(

Is it a poerformance problems?? Should I move to another (maybe more efficient) compiler.

MDP
___________________________
This message was ported from CCS's old forum
Original Post ID: 11772

[Mark]

Sounds like you might be getting buffer overrun errors which would cause the pic to stop responding if you do not clear the errors. Do you need communication in both directions? If not, why not just use the hardware UART to receive and then retransmit.


:=Hi,
:=
:=I have been experiementing with PIC for my first time lately. I need to implement a data demultiplexer that reads in a data stream on one port, strips off certain section of data and sends it out another port. However, I have been having severe problems getting this to work at 115200 baud.
:=
:=I am using a 16F877 (20MHz) and the CCS development board that comes with the kit.
:=
:=The RS232 streams are dfined like below:
:=
:=#use rs232(baud=115200,xmit=PIN_C6,rcv=PIN_C7,stream=MAIN)
:=#use rs232(baud=115200,xmit=PIN_C4,rcv=PIN_C5,stream=OUTPUT)
:=
:=The code I am using is very simple:
:=- check the main port with kbhit()
:=- gets a char on the MAIN stream
:=- outputs the char on the OUTPUT port stream
:=
:=When I reset the PIC it will output a couple chars and stop. I lowered the baud rate to 38400 and it works better but often hangs again after a few seconds and needs to be reset to start again.
:=
:=Is it possible to do 115200 baud with this PIC at 20MHz??? If so, can anyone shed any light on what may be happening?? <img src="http://www.ccsinfo.com/pix/forum/sad.gif" border="0">
:=
:=Is it a poerformance problems?? Should I move to another (maybe more efficient) compiler.
:=
:=MDP
___________________________
This message was ported from CCS's old forum
Original Post ID: 11773

[MDP]

How can buffer overruns be detected and cleared??


:=Sounds like you might be getting buffer overrun errors which would cause the pic to stop responding if you do not clear the errors. Do you need communication in both directions? If not, why not just use the hardware UART to receive and then retransmit.
:=
:=
:=:=Hi,
:=:=
:=:=I have been experiementing with PIC for my first time lately. I need to implement a data demultiplexer that reads in a data stream on one port, strips off certain section of data and sends it out another port. However, I have been having severe problems getting this to work at 115200 baud.
:=:=
:=:=I am using a 16F877 (20MHz) and the CCS development board that comes with the kit.
:=:=
:=:=The RS232 streams are dfined like below:
:=:=
:=:=#use rs232(baud=115200,xmit=PIN_C6,rcv=PIN_C7,stream=MAIN)
:=:=#use rs232(baud=115200,xmit=PIN_C4,rcv=PIN_C5,stream=OUTPUT)
:=:=
:=:=The code I am using is very simple:
:=:=- check the main port with kbhit()
:=:=- gets a char on the MAIN stream
:=:=- outputs the char on the OUTPUT port stream
:=:=
:=:=When I reset the PIC it will output a couple chars and stop. I lowered the baud rate to 38400 and it works better but often hangs again after a few seconds and needs to be reset to start again.
:=:=
:=:=Is it possible to do 115200 baud with this PIC at 20MHz??? If so, can anyone shed any light on what may be happening?? <img src="http://www.ccsinfo.com/pix/forum/sad.gif" border="0">
:=:=
:=:=Is it a poerformance problems?? Should I move to another (maybe more efficient) compiler.
:=:=
:=:=MDP
___________________________
This message was ported from CCS's old forum
Original Post ID: 11774

[Mark]

The easiest way since you are probably using CCS's built in functions (I don't use them) is to add the ERRORS option to the #USE RS232 statement. Refer to the manual for more info on this and the other options available.


:=How can buffer overruns be detected and cleared??
:=
:=
:=:=Sounds like you might be getting buffer overrun errors which would cause the pic to stop responding if you do not clear the errors. Do you need communication in both directions? If not, why not just use the hardware UART to receive and then retransmit.
:=:=
:=:=
:=:=:=Hi,
:=:=:=
:=:=:=I have been experiementing with PIC for my first time lately. I need to implement a data demultiplexer that reads in a data stream on one port, strips off certain section of data and sends it out another port. However, I have been having severe problems getting this to work at 115200 baud.
:=:=:=
:=:=:=I am using a 16F877 (20MHz) and the CCS development board that comes with the kit.
:=:=:=
:=:=:=The RS232 streams are dfined like below:
:=:=:=
:=:=:=#use rs232(baud=115200,xmit=PIN_C6,rcv=PIN_C7,stream=MAIN)
:=:=:=#use rs232(baud=115200,xmit=PIN_C4,rcv=PIN_C5,stream=OUTPUT)
:=:=:=
:=:=:=The code I am using is very simple:
:=:=:=- check the main port with kbhit()
:=:=:=- gets a char on the MAIN stream
:=:=:=- outputs the char on the OUTPUT port stream
:=:=:=
:=:=:=When I reset the PIC it will output a couple chars and stop. I lowered the baud rate to 38400 and it works better but often hangs again after a few seconds and needs to be reset to start again.
:=:=:=
:=:=:=Is it possible to do 115200 baud with this PIC at 20MHz??? If so, can anyone shed any light on what may be happening?? <img src="http://www.ccsinfo.com/pix/forum/sad.gif" border="0">
:=:=:=
:=:=:=Is it a poerformance problems?? Should I move to another (maybe more efficient) compiler.
:=:=:=
:=:=:=MDP
___________________________
This message was ported from CCS's old forum
Original Post ID: 11775

[Robert Hargreaves]

I am also having problems with the UART xmit 'latching up'.
It is because of a OERR. I have verified this by using a second RS232 s/w implemented xmit to o/p internal register info.
I have tried to use the following code to clear OERR but to no avail.
if (OERR){
while (RCIF){
RCIF = 0;
q=RCREG;
}
CREN = 0;
CREN = 1;
}
with this code OERR is never reset? Does anyone know why?
The UART is being used to send/recieve info via RS485 where xmit is immediately reflected, so RCV interrupts are generated. I have overcome OERR being set in the first place by using #priorty to set rda as priorty. this stops OERR being set, howver if for some reason OERR is set a would really like to know why the above code will not reset OERR.

:=The easiest way since you are probably using CCS's built in functions (I don't use them) is to add the ERRORS option to the #USE RS232 statement. Refer to the manual for more info on this and the other options available.
:=
___________________________
This message was ported from CCS's old forum
Original Post ID: 11779

[Mark]

:=I am also having problems with the UART xmit 'latching up'.
:=It is because of a OERR. I have verified this by using a second RS232 s/w implemented xmit to o/p internal register info.
:=I have tried to use the following code to clear OERR but to no avail.
:= if (OERR){
:= while (RCIF){
:= RCIF = 0;
:= q=RCREG;
:= }
:= CREN = 0;
:= CREN = 1;
:= }
:=with this code OERR is never reset? Does anyone know why?
Here is part of the recieve interrupt I use for a DMX receiver. I mirror the rx status register to a variable at the beigning and then use that var through the routine. I don't really see a problem with the way you clear the error unless the vars are not defined correctly. As for receiving what you are transmitting, you can disable the receive while you are transmitting. You have to monitor the TRMT bit in the TXSTA reg for a 1 to determine when the transmit shift register is empty.


#INT_RDA
void Rx_Data(void)
{
#define WAIT_FOR_NEXT_BYTE 0
#define WAIT_FOR_BREAK 1
#define WAIT_FOR_START 2
#define WAIT_FOR_DATA 3
#define RECEIVE_DATA 4
#define WAIT_FOR_ADDRESS 5
#define WAIT_FOR_DELAY 6

/* Data that we are receiving */
UINT8 data;
/* State machine for determining the begining of the DMX stream */
static UINT8 Rx_State = WAIT_FOR_BREAK;
/* Duplicate of the RCSTA reg used due to the double buffering of the
fifo. Reading the RCREG reg will cause the second RCSTA reg to be
loaded if there is one. */
union
{
unsigned char byte;
struct {
unsigned char RX9D:1;
unsigned char OERR:1;
unsigned char FERR:1;
unsigned char ADDEN:1;
unsigned char CREN:1;
unsigned char SREN:1;
unsigned char RX9:1;
unsigned char SPEN:1;
} bits ;
}rcsta;

/* DMX frame counter */
static UINT16 DMX_512_Count;
/* receive buffer index */
static UINT8 Rx_Index = 0;

/* disable interrupts */
while (INTCONbits.GIE) /* make sure interrupts were */
INTCONbits.GIE=0; /* disabled. */

/* Keep reading the data so long as it is present. */
while (PIR1bits.RCIF)
{
/* Read the data and the Rx status reg */
rcsta.byte = RCSTA;
data = RCREG;

/* Check for buffer overrun error */
if (rcsta.bits.OERR)
{
RCSTAbits.CREN=0;
RCSTAbits.CREN=1;
/* we just received a buffer overrun so lets wait
for a good data byte before we look for the break signal. */
Rx_State = WAIT_FOR_NEXT_BYTE;
return;
}

switch (Rx_State)
{


:=The UART is being used to send/recieve info via RS485 where xmit is immediately reflected, so RCV interrupts are generated. I have overcome OERR being set in the first place by using #priorty to set rda as priorty. this stops OERR being set, howver if for some reason OERR is set a would really like to know why the above code will not reset OERR.
:=
:=:=The easiest way since you are probably using CCS's built in functions (I don't use them) is to add the ERRORS option to the #USE RS232 statement. Refer to the manual for more info on this and the other options available.
:=:=
___________________________
This message was ported from CCS's old forum
Original Post ID: 11781

[R.J.Hamlett]

:=I am also having problems with the UART xmit 'latching up'.
:=It is because of a OERR. I have verified this by using a second RS232 s/w implemented xmit to o/p internal register info.
:=I have tried to use the following code to clear OERR but to no avail.
:= if (OERR){
:= while (RCIF){
:= RCIF = 0;
:= q=RCREG;
:= }
:= CREN = 0;
:= CREN = 1;
:= }
:=with this code OERR is never reset? Does anyone know why?
I'd suspect, it is because the input buffers are all still full.
Do three character reads on the receive data register to clear these, then clear the RCIF, and reset/set the CREN bit.

Best Wishes

:=The UART is being used to send/recieve info via RS485 where xmit is immediately reflected, so RCV interrupts are generated. I have overcome OERR being set in the first place by using #priorty to set rda as priorty. this stops OERR being set, howver if for some reason OERR is set a would really like to know why the above code will not reset OERR.
:=
:=:=The easiest way since you are probably using CCS's built in functions (I don't use them) is to add the ERRORS option to the #USE RS232 statement. Refer to the manual for more info on this and the other options available.
:=:=
___________________________
This message was ported from CCS's old forum
Original Post ID: 11788