Delay without using pause

[stanon1]

hi all, i have been scratching my head thinking of how to avoid pbp pause in my routines bcos the command;

1) seems to change system registers (correct me if i'm wrong),
2) is the main cause of many problems i have had with ISR's in the past
3) is blocking, i dont want to waste cycles

i have been trying to make sense of the previous posts in this thread. pls can someone help with a robust snippet.

i think of a delay based on an interrupt timer that serves as the heartbeat with a resolution of say 1us. in the isr, multiple regs (each loaded when needed from various routines) are decremented to act as counters, when anyone hits zero a corresponding flag is set etc...

am i making any sense? i think this is simillar to how some rtos work. is there a better way?

[HenrikOlsson]

Hi,

> 1) seems to change system registers (correct me if i'm wrong),

What do you mean with system registers? If you mean the PBP system variables then yes, it has to use something to keep track of time - in the same way as you suggest in your method and the compiler uses its internal variables for that. But I don't really see the problem, are you using the system variables in your code?


> 2) is the main cause of many problems i have had with ISR's in the past

How are you "doing" your interrupts and what problems are we talking about?
If you're spending a lot of cycles in your ISR then a PAUSE in the main program won't be accurate because the main program isn't really executing at the desired speed due to the interrupt "stealing" time away from it. If you're using a PAUSE in the ISR then of course the main program will "halt" during that period.

> 3) is blocking, i dont want to waste cycles

It is. Just like all PBP commands.

> i think of a delay based on an interrupt timer that serves as the heartbeat with a resolution of say 1us. in the isr, multiple regs (each loaded when needed from various routines) are decremented to act as counters, when anyone hits zero a corresponding flag is set etc...

The overall idea is doable but forget 1us resolution. Even at 64MHz there would only be 16 instructions between each interrupt - perhaps you could manage ONE timer if written in tight ASM but then there wouldn't be much time left for anything else. Depending on the oscillator speed and the number of timers you want to maintain 100us or 1ms might be more appropriate, 10ms certainly doable.

/Henrik.