problems using delay_ms with #int_RDA

Vector Research · Joined: 16 Feb 2004 Posts: 10 Location: Kelowna B.C

im having some strange problems with using #int_RDA while using a Delay_ms(1000); in my main loop. when ever the delay is executed the interrupt is never fired on buffer full, Im allways getting overflow errors.

Its like interrupts are being disabled in the Delay_ms function. Anyone have any experience or data on this?.

in looking at the actual code developed by the compiler it looks like the Delay_ms function is not working as documented in the manual.

the manual states:
Function: This function will create code to perform a delay of the
specified length. Time is specified in milliseconds. This function works by executing a precise number of instructions to cause the requested delay. It does not use any timers. If interrupts are enabled the time spent in an interrupt routine is not counted toward the time. The delay time may be longer than requested if an interrupt is serviced during the delay. The time spent in the ISR does not count toward the delay time.

in my case, my isr is very small so it does not signifiantly affect the timing, as well as i dont need precision timing, im just looking for an approximate delay. However, the code generated for delay_ms(500) is as
follows:

neil · Joined: 08 Sep 2003 Posts: 128

Hi, I think Ttelmah explained this one before on one of my posts a while back. Search for posts by 'neil' and look for replies by 'ttelmah' within them.
I avoid using 'delay_ms' functions totally when interrupts are used. They are so wasteful of code. The processor is tied up in the delay for the duration, and I don't trust the reliability of interrupts while using them.
I create a known timebase from a timer interrupt and use a prescale variable to divide that time down into variable lengths, then set a bit variable when the time is reached.

Regards,
Neil.

Vector Research · Joined: 16 Feb 2004 Posts: 10 Location: Kelowna B.C

I searched for that thread but it looks like the sands of time has eaten it up..
That means that this has been a known problem for over a year. I cant believe this, they let an error like this go unchecked in the compiler/manual for more than a year! Evil or Very Mad

This is a perfect example of what is wrong with CCS's whole corporate mentality. Yes compiler/documentation bugs happen, but for there to be nothing done about it really burns me. I wasted a week of my time, and had to buy a ICD to find this problem..

They wont see me purchase support anytime soon. and to think ive been using CCS since their first release back in 94 or 95. I need to go put my fist through a wall or something.. Im really ticked off..

If you have any copies of Ttelmah's posts on this subject, a repost would be greatly appreciated.

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Various posts which discuss this issue:

http://www.ccsinfo.com/forum/viewtopic.php?t=17661&highlight=delayms+interrupts

http://www.ccsinfo.com/forum/viewtopic.php?t=14228&highlight=delayms+interrupts

http://www.ccsinfo.com/forum/viewtopic.php?t=14426&highlight=delayms+interrupts

http://www.ccsinfo.com/forum/viewtopic.php?t=2074&highlight=delayms+interrupts

Guest · Posted: Wed Feb 18, 2004 4:20 am

Oh the joys of software! It can be the most rewarding job, and the next day the most frustrating! I wouldn't be too harsh on CCS though, the disabling of interrupts in a delay (as mentioned in one of the links above) is there for a good reason - to prevent a sort of 'circular call' within a function.

As I said earlier, use hardware timers with 'postscale' variables to get your desired delay lengths for all but the simplest of programs. All you need in the timer ISR is a 'variable--;' or ++ and do a test for a certain value, then set a flag. This approach keeps your code running smoothly, never tying up the processor in a delay loop. If your main loop runs quickly, checking for event flags and jumping off to do something only when required, you code will start to look like a multitasking system!

Enough rambling! Shocked

Regards,
Neil.

Darren Rook · Joined: 06 Sep 2003 Posts: 287 Location: Milwaukee, WI

When you saw this warning generated by the compiler:

"Interrupts disabled to prevent re-entrancy: @delay_ms"

Didn't you think that maybe it was important?

Darren Rook · Joined: 06 Sep 2003 Posts: 287 Location: Milwaukee, WI

I have posted a work-around on the FAQ:

http://www.ccsinfo.com/faq/?50

Laurent Chouinard · Joined: 12 Sep 2003 Posts: 43

Thank you very much for that faq entry! It certainly did save my day. I didn't know that we could create several entities of the #use delay code generator, it's good to know!

It took me quite a while though to pinpoint exactly where I was having a re-entrant function that was forcing the compiler to disable interrupts. I see you made reference to this error message:

"Interrupts disabled to prevent re-entrancy: @delay_ms"

I never saw that message. I've checked the .lst file and the others. Furthermore, the .err file says "no errors". Where should I be watching for that compiler message then? Seeing that would have probably saved me a couple of hours, but i'm already happy to have found the problem itself...