 |
 |
| View previous topic :: View next topic |
| Author |
Message |
jamesjl
Joined: 22 Sep 2003
Posts: 52
Location: UK
|
| Framing and Overrun Errors on RS485 bus |
 Posted: Wed Apr 06, 2005 12:55 am |
 |
|
Hi all,
PIC: 18F6220 and 16F874A
PCWH 3.218
I am having some problems with a multi PIC RS485 bus and the collision of the packets that I am sending. I have CRC error checking, re-tries for collisions and bus busy detection code written. However, occasionally the bus fails and I need to reset the PICs to get them to communicate again. I have biased the RS485 bus to ensure 200mV between the two wires of the transmission line.
I have been reading the news groups about framing errors and over-run errors and have put together what I believe to be the correct code to handle over-run and framing errors for the second hardware UART on my PIC18F6620. However, I have a couple of questions.
Where should I place this code?
Should it be outside of my ISR for my UART recieve?
Should I disable the interrupt before running this code?
Will this code handle both framing and over-run errors?
| Code: | #byte RCSTA2 = 0xF6B
#byte RCREG2 = 0xF6E
#bit OERR=RCSTA2.1
#bit FERR=RCSTA2.2
#bit CREN=RCSTA2.4
byte ch;
while (RCSTA2 & 0x06)
{
ch=RCREG2;
if (OERR)
{
CREN=0;
CREN=1;
}
} |
Many thanks in advance for your thoughts and comments.
Regards,
Jason. |
|
 |
TSchultz
Joined: 08 Sep 2003
Posts: 66
Location: Toronto, Canada
|
|
| Posted: Wed Apr 06, 2005 6:30 am |
|
|
One thing you need to make sure of is that there is a turn-around delay before any node transmits. This is especially critical if the connection is a 2 wire, half duplex interface. There has to be a delay to ensure that the last device that transmitted has switched to an idle or receive mode before anything is transmitted. Also make sure your grounding is correct between all the various nodes. This is a common source of problems.
Make sure you use the ERRORS switch in the use rs232 define. If not you have to ensure you properly handle the error flag. |
|
|
jamesjl
Joined: 22 Sep 2003
Posts: 52
Location: UK
|
|
| Posted: Wed Apr 06, 2005 8:07 am |
|
|
TSchultz,
the RS232 is defined as
| Code: | | #use rs232(baud=9600,parity=N,xmit=PIN_G1,rcv=PIN_G2,bits=8,ENABLE=PIN_G0,stream=RS485, ERRORS) |
and should handle the errors, however I have added over-run and framing handling also.
Do you have a suggestion as to how long the turn around time should be?
Thanks,
Jason. |
|
|
treitmey
Joined: 23 Jan 2004
Posts: 1094
Location: Appleton,WI USA
|
|
| Posted: Wed Apr 06, 2005 8:15 am |
|
|
I clear the CREN 2 places. On error in the interrupt routine. and where you first enable the serial interrupt.(that way you start with a clear CREN bit) This is my ISR.
| Code: | //=======================RXisr============================//
//Takes RX data from a stream and puts it into a buffer via interrupts
#INT_RDA
void RXisr(void)
{
idle_bus=FALSE;
//fprintf(DEBUG,"B\n\r");//busy bus
RX_BUF[rx_indx_i]=RCREG;
rx_indx_i++;
if (rx_indx_i==rx_indx_o) // check for buffer overflow
{
bit_set(ERRORS,2);//set error flag bit 2 for RXbuffer overflow
}
if (OERR)
{
bit_set(ERRORS,0);//set error flag bit 0 for USART overflow
CREN = 0;
#asm nop #endasm
CREN = 1;
}
set_timer1(TIMER1_INIT);
}
|
For you error problem think about making some rand pause. Read a voltage, or temp or something and loop a rand routeen to get all pics on the bus with different rand numbers. Then when you want to transmitt, make sure the buss is idle, (idle n mS) then wait your rand time, then check idle again and then tranmitt. In a nutshell, thats what I do.
For your questions.
1) in the ISR
2) it is in the ISR, interupts are already disabled
3) Not sure, but a think CREN is just your 2 byte buffer overflowing, and NOT framing. Framing is a different bit(I think). |
|
|
Humberto
Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata
|
|
| Posted: Wed Apr 06, 2005 8:58 am |
|
|
treitmey wrote:
| Quote: |
Framing is a different bit(I think).
|
Framing error means that someting that looked like a character arrived
but that it was not formatted properly. No stop bit, incorrect number of
data bits, etc etc. In general the problem is a noisy line. If you are using
RS485 it would be discarded.
The parameter ERRORS only does the trick for you if the problem is
regarding to framing or PIC UART buffer overflow.
Collision errors is tipical in multipoint communications lines and has a
close relationship with the line discipline manager that you are using to
prevent and ovoid that two or more transmitter transmit at the same time.
So I would re-check the time share of the whole network involved.
Keep well,
Humberto [/quote] |
|
|
TSchultz
Joined: 08 Sep 2003
Posts: 66
Location: Toronto, Canada
|
|
| Posted: Wed Apr 06, 2005 10:02 am |
|
|
For a turn-around delay, in a strict environment where I have designed all nodes, I normally use a delay of 3-5 byte periods (most of my links operate at 57.6Kbps or 115.2Kbps). If I have a PC involved, especially with Windoes, this normally extends to a minumum of 5mS. If you are using third-part devices the minimum delay is normally listed in the device and/or protocol specs somewhere.
You basically need to wait long enough for the slowest transmitting node to finish the transmit loop and set it's RS-485 to receive mode.
This works flawlessly in a host/slave relationship with a poll/response type protocol. More care has to be taken if you are in an environment with multiple masters operating in an async manner.
The protocol I use has timeout checking where this a maximum delay between bytes as well as for the overall packet. This is in addition to an node ID, CRC and packet framing (start and end) check. |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
