I got some situations where I need to know how many instructions was executed from entry to ISR up to loading some values.
For instance, in a software serial UART (is not my case), I got an interrupt when lines goes down and after testing what cause that interrupt, I have to reload tmr0 register for the next reading and I have to substract the time spent up to reloading Tmr registers. Consider for a byte 0x00 or 0xFF I cannot sync until stop bit, and every drift in time of reading will generate some problems.
While I was using "asm" it was easy for me, but now, with uP context saving I'm never sure how many register save before entering in ISR itself. I can take a look at .lst butI have to do it everytime I recompile my project.
This can be computed at compile-time and can be easy made up to a for/while/repeat statement.
Also, some compiler instructions not to do any context saving for interrupts will be useful - but separate for high and low priority isr.
Thanks
MSI
Counter for number of instruction from ISR up to a point
Re: Counter for number of instruction from ISR up to a point
you can find the number of cycles by running the ISR in the software simulator.
Au royaume des aveugles, les borgnes sont rois.
Re: Counter for number of instruction from ISR up to a point
I can also read from .lst.you can find the number of cycles by running the ISR in the software simulator.
But what I want is something like:
//Next read in 18us
Tmr0:=(0x10000-(Tyc*4*18000)+(InstrCnt)) , to be sure that I don't have time drift because of those instructions spend from entry to ISR up to setup of TMR0. And I can tell that this can lead in many failure of reading peripherals, when time is sensitive and you don't have any sync base of signal.
In fact, not a counter for instructions will be useful but a counter for instruction cycles, since instructions are 1,2 or even 3 cycles.
In this way, if I have to test some more flags in int (like others sources of interrupts) or compiler want to do some magic context saving I can be sure that every time I got the correct set up of timers for ISR.
Regards,
MSI
Re: Counter for number of instruction from ISR up to a point
in such case you would better use a timer that does not require reloading, that will eliminate this requirement which anyway will fail if ever in the code the interrupts are disabled.
Au royaume des aveugles, les borgnes sont rois.
Re: Counter for number of instruction from ISR up to a point
It wont work in many situation: in the same interrupt I have 3 int source:
Pin change status, pin drop low and timer.
In my example, I have to start a timer when pin port drop low for next reading in 75us, then, depending of what I got on first 8 bits I can have to read up to 128 times pin value every 50us(bit period).(don't blame me for this way of sending)
In case that pin change (0->1,1->0) I have to setup timer to make next read in 25us (half time bit period). This is for sync.
Well, if inside my ISR I have to do more stuff, compiler will automatically save registers, adding for each register saved 2 cycle (MOVFF) to ISR. This will make my values loaded in tmr to be obsolete.
But having that CyclesCount I can put a formula at loading of Tmr instead of values (and formula can be calculated at compile time). This will let me do changes inside ISR without thinking that I have to recalculate every time those values for timers. Anyway, I have to use "asm" to be sure that future implementations of newer versions will still work with my code. Having CyclesCount, I can switch to Pascal also in ISR.
This is just an example. But can be many situations that can require that. I hope that you understand now where it can be used.
I found this feature useful, that's why I put it in "Wish List" section. mE can think about for new versions, but anyway they will decide.
It's still a wish. Other things are mandatory.
All the best,
MSI
Pin change status, pin drop low and timer.
In my example, I have to start a timer when pin port drop low for next reading in 75us, then, depending of what I got on first 8 bits I can have to read up to 128 times pin value every 50us(bit period).(don't blame me for this way of sending)
In case that pin change (0->1,1->0) I have to setup timer to make next read in 25us (half time bit period). This is for sync.
Well, if inside my ISR I have to do more stuff, compiler will automatically save registers, adding for each register saved 2 cycle (MOVFF) to ISR. This will make my values loaded in tmr to be obsolete.
But having that CyclesCount I can put a formula at loading of Tmr instead of values (and formula can be calculated at compile time). This will let me do changes inside ISR without thinking that I have to recalculate every time those values for timers. Anyway, I have to use "asm" to be sure that future implementations of newer versions will still work with my code. Having CyclesCount, I can switch to Pascal also in ISR.
This is just an example. But can be many situations that can require that. I hope that you understand now where it can be used.
I found this feature useful, that's why I put it in "Wish List" section. mE can think about for new versions, but anyway they will decide.
It's still a wish. Other things are mandatory.
All the best,
MSI