delay interferes with INt_rda

[Ringo42]

I'm using a pic18452 at 20mhz, talking 19200 from a pc.

In main I have code that looks like this.

if(SonarEnabled==1)
{
for(SonarNumber=0;SonarNumber<10;SonarNumber++)
{
range=timeEcho2(trig,echo);
delay_ms(Delay_between_readings);
}
}

When SonarEnabled is = to 1 then it is very difficult to send commands to the board. In My PC app I have to send a char, wait 10ms, then send another char, etc. When SonarEnabled=0 I can send a variety of commands with any delay, so I'm assuming it has something to do with the delay_ms. Does delay_ms turn off serial ints?


Here is the TimeEcho code, I don't think there is anything in it that would cause interference.

[dyeatman]

I try to never use delay_ms() type routines at all. They are VERY
inefficient and can also interfere with other processes running in in your
code. With these types of delays your processor is in a tight loop and is
completely wasting time when other things can be accomplished during the
delay.

I set up timers to keep track of delays and just loop in the background
code doing other things until the desired delay flag is set. See one of my
posts in another thread on how it can be done:

http://www.ccsinfo.com/forum/viewtopic.php?t=26600

Also, I don't know what ProcessCommands() does but you should never
try to use PRINTF, PUTC etc. or execute any subroutines while in an RDA
interrupt. The rule of thumb is to keep it "short and sweet". Receive the
RS232 data, put it in a processing queue, set a flag if required and and get
out QUICK. You only have milliseconds (or less depending on baud rate)
between interrupts. Interrupts are NOT re-entrant and you MUST be out of
the interrupt routine before the next interrupt occurs.

Finally, enabling and disabling interrupts in the interrupt routine is not
recommended. Let the compiler take care of this automatically.

I hope this helps....

dave

[Ttelmah]

First, get rid of the interrupt disable/enable in the interrupt handler. This is not wanted, and is doing nothing. The hardware, disables _all_ interrupts, when you are inside the handlers (except when delaing with hardware 'high priority' interrupts). Though this won't cause a problem, it is two wasted instructons!...
Now, delays, _do not disable interrupts_, _unless you use delays inside the interrupt_. You do not show the 'ProcessCommands' code, but if this contains any delays, then this is the cause of your problem.

Best Wishes