??? 06/19/09 18:05 Read: times |
#166262 - Try unsigned subtraction with borrow Responding to: ???'s previous message |
Let's say you have a 16-bit counter ticking downward and automatically going from 0 to 0xffff on turn-around.
Let's say you want to wait 4900 ticks, so you write: if (start-current >= 4900) have_timeout(); Let's say you make your first sample at 53719. 53719-53719 = 0, so not time yet. 53719-53718 = 1, so not time yet. 53719-53717 = 2, so not time yet. ... 53719-48820 = 4899, so not time yet. 53719-48819 = 4900 => timeout. 53719-48818 = 4901, so we are one tick late. ... Let's now say that your first sample was at 3019, i.e. the timer will turn around during your wait. 3019-3019 = 0, so not time yet. 3019-3018 = 1, so not time yet. ... 3019-0 = 3019, so not time yet. (time for a turnaround) 3019-65535 = -62516 which is 0xffff0bcc in 32-bit hex or 0x0bcc in 16-bit hex or 3020 decimal. ... 3019-63656 = -60637 which is 0xffff1323 in 32-bit hex or 0x1323 in 16-bit hex or 4899 decimal. Not yet. 3019-63655 = -60636 which is 0xffff1324 in 32-bit hex or 0x1324 in 16-bit hex or 4900 decimal. Timeout 3019-63654 = -60635 which is 0xffff1325 in 32-bit hex or 0x1325 in 16-bit hex or 4901 decimal. One tick late The subtraction will still produce the correct number of ticks after the turnaround. But you have to be a bit careful if your delay time gets close to the full period time of the timer, since the amount of ticks available for detecting the end of the delay may not be enough. If the timer ticks with 1MHz and your loop can't guarantee that it polls time timer more often than every 100us, then a 16-bit timer would be unsafe to use with this method if your delay is so long that it gets close to 65536-100. |