View previous topic :: View next topic |
Author |
Message |
jseidmann
Joined: 04 Nov 2004 Posts: 67
|
Curious RS-485 Problem! |
Posted: Wed Oct 12, 2005 9:10 am |
|
|
I am currently using the PIC18F452 in a product which has been in use for quite a while now.
When I communicate with the PIC on RS-485 it works great 99% of the time, but I find that occasionally something happens and it does not get the RS-485 command. I am testing this by sending the same commands over and over and over again. The PIC sends back a response when it gets a valid command, and sends nothing when it gets an invalid command.
My PIC is used in a monitoring application. If i turn the 'monitoring' off, and just leave it in standby (where it can still communicate and so several other things), it works flawlessly for hours on end. I am using the RS-485 interrupt (RDA). There is a higher priority interrupt (timer2) which I use, but i have switched the priorities of the two and it does not help.
My feeling is that this should not be happening because there is an interrupt that should be interrupting anything else thats happening! The timers are never disabled in the code, so I do not know what i can do to find out what is causing this problem. Are there known routines that disable the interrupts like reading/writing to the EEPROM?
Any help would be extremely helpful!
If you have any questions about this, I will respond very quickly! |
|
![](templates/subSilver/images/spacer.gif) |
Neutone
Joined: 08 Sep 2003 Posts: 839 Location: Houston
|
|
Posted: Wed Oct 12, 2005 9:28 am |
|
|
How are you sending the commands?
Do you wait for a reply before sending another command?
Does the PIC delay before sending a reply? |
|
![](templates/subSilver/images/spacer.gif) |
treitmey
Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA
|
|
Posted: Wed Oct 12, 2005 9:30 am |
|
|
As a test, cut down all 'other ' ISR to a get-in and get-out shell. Then we KNOW that this isn't a case of a bad ISR taking up too much time. And the int_RDA/int_tbe won't be missing a char |
|
![](templates/subSilver/images/spacer.gif) |
jseidmann
Joined: 04 Nov 2004 Posts: 67
|
|
Posted: Wed Oct 12, 2005 9:40 am |
|
|
Neutone: I am sending the commands through a VB program, and I do wait 3 seconds before i consider the command 'unanswered'. The PIC sometimes delays for over a second when responding (which is huge!). Remember, the RS-485 works without a problem when the system is in 'standby'.
Treitmey: I will try that test overnight to see if it is the other ISR that is causing problems. |
|
![](templates/subSilver/images/spacer.gif) |
Neutone
Joined: 08 Sep 2003 Posts: 839 Location: Houston
|
|
Posted: Wed Oct 12, 2005 10:42 am |
|
|
Is there some reason why the time to reply would have a huge variance. If the time to reply can vary to more that 3 seconds it would apear to have timed out. I would look for the cause of the variance. |
|
![](templates/subSilver/images/spacer.gif) |
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Wed Oct 12, 2005 10:57 am |
|
|
That one second delay is a big red flag. Could the PIC delay that much if it wanted to? I strongly suspect the PC and VB end of the communication. Can you put a scope on the RS485 lines to verify the timing of the querry and responce at that point? _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
![](templates/subSilver/images/spacer.gif) |
jseidmann
Joined: 04 Nov 2004 Posts: 67
|
|
Posted: Wed Oct 12, 2005 11:20 am |
|
|
I do not suspect the VB code because it works without any problem when the system in in 'standby' mode. I do not know if anyone has had problems with this before, but the ROM is 99% full,and the RAm is 85% full. There is a lot of computation going on, and I will try to see if this problem is caused by the interrupts and I will test that tonight. |
|
![](templates/subSilver/images/spacer.gif) |
Ian McCrum
Joined: 26 Oct 2003 Posts: 14 Location: Northern Ireland
|
Couple of things about RS485, serial code and PICs |
Posted: Mon Oct 17, 2005 3:30 pm |
|
|
Couple of things about RS485, serial code and PICs
(a) occasionally some serial PIC code of mine would hang or freeze, usually permanently sometimes for a second or two. I think this was due to various error conditions occurring - it was necessary to clear the error bits in the uart and then I never saw it hang again.
(b) with RS485 there is sometimes brief periods of time when the line is floating. You can add a pullup and pull down resistor to +5v and gnd at one place in the network to "bias" the network to the idle state. This is in an old app note and probably does reduce your noise immunity a bit - but it works.
(c) you MUST use termination, twice! physically at each end of the party line. If you have drop lines or spurs then this gets difficult. Drop the baud rate in that case.
(d) Because of (b) and also to allow a simple PC to be used as a monitor I usually ended up implementing "4 wire RS485" - one master always transmitting on one pair, received by all slaves and all slaves transmitting on the secondary pair to the one receiving chip in the master. This allows you to use a PC for a master since its transmitter can be permanently enabled. As a side effect it improves problem (b) above.
(e) Of course once you transmit a byte there is a time delay before it actually leaves the usart - your transmit software must either (i) wait with a time delay (ii) listen to itself transmitting or (iii) depend on bits in the UART control register to tell it the buffers are all empty and the byte has left the building. Most code then tristates the RS485 buffer - But it can hep if you add a delay before tristating - provided the far end delays before responding...
Sorry for the core dump - I have not read the thread carefully - hope it helps someone...
![Embarassed](images/smiles/icon_redface.gif) _________________ Ian McCrum, email address held at
www.eej.ulst.ac.uk/~ian |
|
![](templates/subSilver/images/spacer.gif) |
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
Posted: Mon Oct 17, 2005 7:04 pm |
|
|
There are two more things to consider
Lots of PC applications expect to receive a string terminated with carriage return linefeed (0x0d and 0x0a respectively). A common mistake is to mix the order:
Code: |
printf"This is correct\r\n");
printf("This is not\n\r");
|
When the output of these two is examined with a terminal emulation program, such as Hyperterm, both appear to print correctly. However a PC application expectring <CR><LF> termination wil only see the first. The second is still in the receive buffer queue of the application but will not be seen until another string is received that is correctly terminated. In this case the string will be a contactedation of the invalid string and the subsequent string.
The second issue (which may or maynot be relevent) is the RS485 direction control line used to RS485 two wire mode to set the recive/transmit mode of the RS485 transceiver. In transmit mode the CCS compiler incorrectly puts the transceiver in receive mode when the stop bit of the last byte is still being serialized out of the transceiver forcing the bus to float prematurely. If you are unlucky the receiving UART detects this as a framing error. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
![](templates/subSilver/images/spacer.gif) |
|