Faulty RS-485 Communication during processor intensive tasks

[jseidmann]

I am currently using the compiler version 3.19.

I have created a data acquisition product which has different "modes". One mode does very very little calculation, it just is in "standby" and calculates temperature. When in this mode, I can communicate to the PIC18F252 for over 72 hours without one dropped RS-485 command.

There is another mode, where the system is doing some processor intensive timing. There is a lot of computation during this task, and when I do continuous RS-485 communications during this time, I get a dropped command once every 5-10 minutes.

I have tried disabling ALL interrupts (Except the RS-485 interrupt) and this did not solve the problem. I have tried making the RS-485 interrupt the highest priority interrupt and that also did not solve the problem. I do not know why this is happening if this is run off of an interrupt and has the highest priority.

Could the intensive calculations be disabling (or delaying) the interrupt long enough to cause the PIC to miss some of the RS-485 commands?

Has anyone had a similar problem or point me in the right direction?

[treitmey]

For a first stab in the dark, I'd try to increase the buffer 485 is using.
Getting data will always throw that IRQ. But if the buufer is too small the data may still get lost.

[jseidmann]

The recieve buffer size is 128 characters. The command being sent to the PIC is 8 ASCII characters plus a CR+LF on both ends. This adds up to 12 total characters. 128 seems to be overkill, no?

I looked at some previous tests that I did, and it seems that replacing some of the computation with hardcoded values (e.g. values are not being calculated but are just being set) and that did not solve the problem, but the failures happenned less often.

Think I should extend the receive buffer from 128 to 256 and give that a shot? Does that make sense?

[asmallri]

From your description your buffer is big enough. Are you making any cals in your interrupt handler to functions that are also called in the main body? If this is the case it could be that the compiler is inserting a disable interrupt instruction in the main body.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[jseidmann]

Perhaps I am misunderstanding your message, but if I am calling a function in my interrupt service routine that is also called in the main body, why would the compiler insert a disable interrupt instruction at this point?

[jseidmann]

As an update on the recieve buffer, I did a test:

I added to the code a line that would write to the EEPROM a value of 255 in a specific address when the current recieve buffer 'value' was greater than HALF of the size of the reieve buffer size. I had a few RS-485 "drops" and I looked in the EEPROM and the value was what it had been originally, so the size of the recieve buffer does not appear to be the problem.

I appreciate everyone's input and help, and I am very grateful!

Thanks.

[Ttelmah]

As Asmalli says, certain combinations can lead to disabled interrupts (some long threads about this, not that long ago). There are also a couple of commands, that in certain circumstances, will disable interrupts, even if not used in both locations. Obvious ones, are things like program memory writes, but also certain operations using table accesses, will do this 'by default'.
One thing that may help, is slightly modifying the RS232 receive code. If you use something like:

[Ttelmah]

[jseidmann]

Thank you for your explanation tTelmah. Looking at my code, in my TIMER2 interrupt (the interrupt which is HIGHER priority than the RS-485), there is:

1 READ_EEPROM command
25 OUTPUT_BIT commands

Would either of these cause the compiler to add a disable_interrupt?

You may be thinking that the TIMER2 interrupt is causing the RS-485 problems, but I have tried making the INT_RDA interrupt higher priority than the TIMER2 with no effect.

Thanks

[jseidmann]

Looking at the code for both TIMER2 and INT_RDA interrupt routines, there is no command in those interrupt routines that is being called from anywhere other than those routines (with the exception of read_eeprom and output_bit commands).

[Ttelmah]

[jseidmann]

In the main code, there are about 25 'read_eeprom' commands, with another probably an extra 30-40 'read_eeprom' in functions CALLED from the main code.

There are no 'write_eeprom' commands from the main loop, although the program I am using to test how many commands are being "dropped" by the RS-485 continuously reads and writes to the EEPROM. I'm not sure this is a problem because when my system is in "standby" mode, it is still performing the RS-485 communication and reading/writing to the EEPROM flawlessly.

I am not sure I can use the #INT_RDA HIGH and 'high_ints = true' because my compiler version is 3.190 and does not have this feature. Any other possibilities?

[Ttelmah]

Do it yourself. The HIGH option should work (you don't need the device option on the older compilers), but will generate a handler, with no register saving. Since you will only have one interrupt source, look through the LST file, and find what registers are changed in the interrupt, save these, then execute your interrupt code, clear the interrupt, restore the registers, and exit. Something possibly like:

[jseidmann]

tTelmah,

I think this register work is a bit beyond my expertise. I think I will just have to bite the bullet and upgrade the compiler and use the HIGH interrupt as you suggested before. I will let you all know how it goes.

BTW, Once I update the compiler, is there any advantage in using the RTOS for this type of stuff? Will it help matters?

[guy]

Probably you don't need it anymore, but in the #use rs232 add the option ERRORS. This is extremely important since if an error occurs (including hardware-buffer full) the software will simply not receive any more characters!