timer interrupted delay routine bug?

[dorinm]

Hello all,

first of all, here's a topic I found on this forum regarding my issue:
http://pic-c.ccsinfo.com/forum/viewtopic.php?p=26

...basically, I am experiencing the same problem, that the delay routine built into CCS somehow get stucked. I don't have the time to debug the asm so I'm asking if someone experienced this recently and what would be the workaround, excepting the custom delay routine one.

I've tried to compile the following code using 3.xxx version of CCS, also the latest 4.120(demo), the same result: the TIMER1 should fire every~18msec but it fires every ~250msec; if I comment the delay in main loop, everything works as expected:

[Ttelmah]

Your issue is not the one in the thread.

The PIC, does not have a data stack.
Because of this, local registers in functions can't be saved.
Because of this, functions can't (easily) be made 're-entrant' (you can't call a function inside itself).
Hence your problem.

Your interrupt code, uses the delay_ms routine. So does your 'main' code.
So to _ensure_ that the delay is not called inside itself, interrupts will be disabled in the 'delay_ms(500)', in the main.

Now, I'd not expect the interrupt to fire every '~250mSec', but every 500mSec. Effectively the code sits in the delay in 'main', with the interrupts disabled, then just for the single instruction as you loop back, interrupts are turned on. At this moment, the timer code gets called. Your code is not stuck in the delay, the delay is fine. It is that interrupts are turned off in the delay, because you are using delays in the timer interrupt.

Basically, interrupt handlers in general, should do just the job of handling the interrupt. Delays inside handlers are 'poor practice'. It is possible to make the compiler generate a separate delay routine for inside the interrupt, but 'better' to use the hardware to fire the delay.

So:

[dorinm]

Just made some more testing on a friend computer ...basically what I've discovered is that the code compiled with retail 4.120 runs fine, but in 4.120 demo and older version (i think last one i've been trying was 4.114, also 3.xxx) is happening what you are saying.

Your point makes sense yet I don't understand why if I keep the delay in isr short (~10-6-700us), everything works ok, but not with msecs.
I also don't understand why other isr's (like uart, rb) don't seem to be affected by the delay (delays) in main loop ....i've been using delays (like everybody else) for many years now and this is the first time (I'm using timers with delay in them) I see something like this.

Thank you, I think it's time to buy CCS as far as the demo version doesn't compile workable code and the retail version does

[Ttelmah]

Delay_us, is a different routine to delay_ms. The problem will then disappear, since you are not using the same routine both inside and outside the interrupt.....
Interrupts like int_rda, _will_ be affected. But remember that there are a couple of characters of buffering in the UART. Provided no more than a couple of characters arrive while the interrupts are disabled, things will still work.
Using delays inside the interrupt handlers, is _not_ 'like everybody else'. Most professional programmers use something like a 'tick' event (an interrupt at perhaps 100*/sec), and use this for all their main delays, rather than using the CCS delay code. You can then just set a counter, which is decremented in this 'tick', and do something else while it is not zero.

Best Wishes

[dorinm]

thank you, this is a better way to do delays I never thought!
About delay_us, delay_ms, I'm not so sure that they don't have the same behaviour (even if they are slightly different routines) as far as even if I tried to use delay_us(2000) insead of delay_ms(2), the code behaviour was exactly the same
Neverthless, now I've learned something... not to rely on built-in routines and instead use some good programming practices like make my own routines for what is not standard programing; maybe some bugs are just optimization bugs yet I don't have the time to test everything in every combination )
Thanks again!

[Ttelmah]

It would be.
They use a slightly different code, dependant on the _length_ of the delay. Delay_us values that are _less_ than a mSec, use 'unique' delay_us code. With delay_us(2000), the compiler will substitute a call to the simpler (but lower resolution) delay_ms code.

Best Wishes