??? 01/24/05 16:57 Read: times |
#85672 - alternatives Responding to: ???'s previous message |
Ian Bell said:
I don't know why it was designed as 13 bits - better ask Intel. It's in the "bible" - compatibility reasons. 8051 was meant to be "mostly compatible" with 8048. Why it has a 13-bit timer - well, that's a question... Ian Bell said:
16 bit mode does not have auto reload so, if I used this mode, by the time I have reloaded the timer in an ISR the actual interval is uncertain. It is not uncertain, the timer still runs. It is essentially the same as using the 13-bit mode, with the difference that TL0 counts up to 256 rather than up to 32. You can do the same trick with reloading THx only, with a difference that it needs to be reloaded within 256 cycles rather than 32 (and your timing has a Xtal/12/256 granularity, rather than Xtal/12/32; and the interrupt can run 8x slower). And you can still compensate for interrupt latency by subtracting the current timer value from the reload value - so you get a non-multiple-of-32(256) 16-bit divider for your timing ticks (but the interrupt service routine gets a bit more complicated). For example see Peter Dannegger's page (I referenced to it in the other thread on the same topic today). Jan Waclawek |
Topic | Author | Date |
Timer 0 Mode 0 | 01/01/70 00:00 | |
no and why | 01/01/70 00:00 | |
CD quality sampling freq.? | 01/01/70 00:00 | |
oops | 01/01/70 00:00 | |
Why | 01/01/70 00:00 | |
alternatives | 01/01/70 00:00 | |
Alternatives | 01/01/70 00:00 | |
comment | 01/01/70 00:00 | |
16 vs 13 | 01/01/70 00:00 | |
Why not T2 | 01/01/70 00:00 | |
uC crystal ? | 01/01/70 00:00 | |
uC Crystal | 01/01/70 00:00 | |
cost saving because of may | 01/01/70 00:00 | |
Cost Saving | 01/01/70 00:00 | |
at those volumes | 01/01/70 00:00 | |
baudrates | 01/01/70 00:00 | |
Baud Rates![]() | 01/01/70 00:00 |