Printable View
I have set a 16F877 with a crystal frequency of 20MHz to test interrupt handling using Melanie's Timer as a reference. The program does process interrupts (ON INTERRUPT, etc.) but does so totally independent of Timer1 settings (T1CON definition and Timer loaded values) so I have no control of the interrupt period.
Any clues as to what I should look at?
The original program was designed to run at 4MHz. At 20MHz, with a slowish LCD, you could be overflowing the Timer.
Melanie,
Overrun the Timer? I would expect it to simply run five times faster?
Please clarify - TNX
The Timer just runs and runs and runs. This programs CONCEPT is that the interrupt simply increments some variables and presets the Timer for the next period. It allows for the fact that whatever happens OUTSIDE the Interrupt (eg your WRITE to LCD) will happen WITHIN ONE Timer rotation. If you have a very FAST PIC, and a very slow event, then PICBasics Interrupt system will not jump to the interrupt routine until AFTER the slow event (command) is complete (typically here the LCDOUT command). The TIMER could theoretically spin through SEVERAL rotations before being serviced just ONCE. This is a drawback of PICBasics interrupt system at high speeds. This example uses PICBasics interrupt system.
Caveat Emptor. Programs and examples I post are designed to run correctly within certain specifications - tamper with them at your own risk! I would hope people would take time to understand how something works (which is why it's usually documented), before making too drastic a change. A 500% speed hike is pretty drastic for time-critical functions. The PICs Hardware Timers are OUTSIDE the control of PICBasic and are not compensated by PICBasics OSC statement.