| ??? 11/29/06 06:01 Read: times |
#128650 - Timer and an interrupt Responding to: ???'s previous message |
Bob Baggins said:
I'm hoping one of you fine chaps might lend me a hand with calculating delays on a Dallas 89C450 uC. I'm doing this as a hobby and am a programmer by trade so treat me with kid gloves if you can.
From the documentation on this uC, it differs from the traditional 8051 in that it only uses one clock per machine cycle ( though instructions can now take between one to ten cycles). So I'm assuming then that using a 16.384MHz crystal and keeping the default clock divide at divide by 1 that the uC will be able to perform 16,384,000 machine cycles per second. Is this correct? I think you're on the right track. It also seems like you've already noticed that there are additional internal clock controls that can be used to affect the relationship between the physical oscillator period and the actual machine cycle period. If so then I'd further assume that an instruction such as DJNZ Rn,rel , taking 5cycles on the 89C450, could be called ~3,276,800 per second ( 16384000/5). Is this right?
Again, assuming the above is correct I'd imagine I could then create a somewhat accurate delay routine by creating a simple loop of instructions whose cycle sum when divided into 16384000 results in my desired delay? Somewhat accurate, at best. If you change to a different derivative or change oscillator speeds, you'll be busy retooling your micro's busy wait loop. Moreover, all bets on accuracy are off if you handle interrupts while executing your busy wait loop. Additionally, you can't get any real work done while you're busy waiting. So, why not leave these limitations behind, and do a non-blocking wait, using a timer and an interrupt? I've no true need for super accuracy but when I want to create a delay routine for an LCD init process, for instance, I'd like a 5us delay to be fairly close to 5us of real time. You can realistically realize this using your approach in a trivial system. However, in a large number of applications, neither the overhead nor the uncertainty in the performance (e.g., due to aperiodic interrupts) would be acceptable. --Sasha Jevtic |
| Topic | Author | Date |
| Calculating a delay on Dallas 89C4XX uC | 01/01/70 00:00 | |
| Timer and an interrupt | 01/01/70 00:00 | |
| Yup, not ideal | 01/01/70 00:00 | |
| ADC 16-b it ACQUISITION IS NOT DESCRIPTIVE | 01/01/70 00:00 | |
| It\'s time for a little reading | 01/01/70 00:00 | |
| Read the book | 01/01/70 00:00 | |
start a new thread | 01/01/70 00:00 |