DT Elapsed Timer Question

[richard]

you may get some ideas here
http://support.melabs.com/forum/picb...ond-pass/page2

where I failed to convince longpole on the merits of timestamps over elapsed_int
I think there is a 24 bit asm version somewhere too but I can't find it .

[rocket_troy]

Richard,
so, the last link: take the stopwatch example (from a layperson's perspective), I can't see significant difference in overhead between say this and the elapsed timer example but I'm probably missing something? Like, am I correct in concluding there's a awful lot going on for when an interrupt is triggered like saving system variables and whatnot, or as in your stopwatch code, both the timer1 and timer3 interrupts call a PBP subroutine with assembler commands within and because of this, the system variables don't require backup and restoring after each interrupt activation? Apologies for what might be dumb questions, I'm trying to get my head around this.

Troy

[richard]

I can't see significant difference in overhead between say this and the elapsed timer example

correct there is not much overhead difference when pbp interrupts are used , main point was to show that time accuracy using time stamps is easy versus trying to fudge clock counts
so that elapsed_int could be used without modification and also to show that conversion to h:m:s is not too difficult

the main difference between asm and pbp interrupts is whats entailed in ReEnterPBP.bas code . its up to the user to determine if the application can tolerate the overhead or a more efficient method need be developed

[rocket_troy]

So, if I was to make an interrupt routine that only incremented a... say 16 bit variable - say 3 or 4 lines of assembler and that's all it did - would I be risking too much to not back up the system variables?

[richard]

if your isr's only use asm code then there is no need to back up any pbp working registers at all , mcu context must always be saved and restored in the isr process. most advanced core pic's have auto context save/restore otherwise that need to be added to the isr process too, refer to your datasheet

[rocket_troy]

Thanks again Richard. I might have crack at a bleeding minimum overhead routine over the weekend and see what happens.