I guess ..
Timer1 starts count from 0xf830. When it reaches 0xffff and overflows it makes TMR1IF=1.At the time of counting (i.e from 0xf830 to 0xffff) the empty while loop Wait for Timer1 overflow interrupt flag. When the overflow interrupt flag is high, the empty while loop fails .And the code continue executing the next line
This sort of stuff is only good for extremely short waits measured in low cycle counts. Usually better to set up an interrupt on timer and sleep the CPU.
but one would hope that you could have an ISR called when a condition, such as a particular overflow, occurred.
Quotebut one would hope that you could have an ISR called when a condition, such as a particular overflow, occurred.Interrupts are great. If you use interrupts, you can have your empty while loop sit around and wait for a variable to be changed by the ISR, instead of waiting for a bit to change in the IO register...
:-)
This sort of stuff is only good for extremely short waits measured in low cycle counts. Usually better to set up an interrupt on timer and sleep the CPU.Applicability is entirely application dependent, so "usually better" is meaningless.
You may not care about power draw.
You may need fast continuation once the condition is met.
You may have other interrupt tasks.
Completely off topic, but :- humorously I have seen this quite a few times in non embedded programming.
Everything works fine on the developers workstation, but when the program is run on a shared server it all turns to custard. Convincing them it is their program is the first problem...
This is because while the wait is spinning away waiting for the user to click OK or whatever the criteria is, it is consuming 100% of a core of the CPU. Get a few people using such a program and the server drops to its knees when several happen to get to the that point in the program.
I wouldn't go so far as to blame embedded programmers who have escaped to the dark side as its mostly seen in MS Access and VB apps. If you see a core at 100% for no reason this is very often the culprit.
A dirty hack is to stick a sleep in the loop, even a few ms sleep will radically improve things.
Quotebut one would hope that you could have an ISR called when a condition, such as a particular overflow, occurred.Interrupts are great. If you use interrupts, you can have your empty while loop sit around and wait for a variable to be changed by the ISR, instead of waiting for a bit to change in the IO register...
:-)At which point you realise that a polled loop and state machine(s) is often a more useful architecture.
Maybe worth mentioning that this will - with any reasonably optimizing compiler - only work if the variable you wait to change is declared volatile.
Maybe worth mentioning that this will - with any reasonably optimizing compiler - only work if the variable you wait to change is declared volatile.
If PIC's headers don't declare hardware registers as volatile then something is very wrong :-)
Quotebut one would hope that you could have an ISR called when a condition, such as a particular overflow, occurred.Interrupts are great. If you use interrupts, you can have your empty while loop sit around and wait for a variable to be changed by the ISR, instead of waiting for a bit to change in the IO register...
:-)