Can anyone advise on the setup required to achieve an OC timer interrupt only, with no hardware output pin? It doesn't seem possible, but I would like to verify.
The modulo register should not alter, because the timer overflow would represent a further fixed timing interval.
Thank you in anticipation.
Regards,
It's supposed to be possible and I've done it somewhere.
Using the Output Compare with the free running timer is a good way to create a time base for the MCU.
For instance, if you put the Data Direction Register as Input, I'm pretty sure you will not drive the port pin from the Timer.
I'm having a look ...
Cheers,
Posted: Fri Oct 07, 2005 5:38 pm
Do you need to be interrupt-based? I'm using the OC and just looking at the timer overflow flag bit in my main loop. That works really well.
However, I can't seem to get much more delay than about 2 seconds, even at the highest bus clock divisor.
Posted: Mon Oct 10, 2005 9:40 am
By adding a counter within the overflow ISR, you can get longer periods.
You would only toggle once you get to the proper number of ISR.
Cheers,
Posted: Mon Oct 10, 2005 10:49 am
Hi all,
software only output compare is possible. Look into datasheet, e.g. QT/QY rev. 5, page 131, table 14-3, the line with "Software compare only". That's what is looked for. The interrupts are generated but pin is not controlled by timer. Older versions of datasheet didn't have this information clear enough.
All other modes (IC, OC, buffered OC) *do* supersede DDRx and PTx settings, simply timer pin functions do have higher priority than simple I/O.
AN2637 shows many modes of controlling pins with timer (this is for software SCI routine).
Regards,
Freescale Czech
Posted: Wed Oct 12, 2005 6:04 am
Thank you for the information. I was using an old data sheet, where the interrupt only operation was not specifically addressed.
For longer time delays, I would normally use a timer overflow ISR counter, as Alban has explained.
The limitation of this simple method is the lower delay resolution and accuracy - an integral number of timer overflow periods, with an uncertainty of one timer overflow period. But quite adequate for non-critical applications such as key de-bounce and LED flash intervals.
Within the ISR, I would usually test the counter, and if non-zero, decrement the value. This means that the counter can't go below zero, so you can never miss a timeout event. Within the main program loop you only need to stuff a value into the counter, and then test for when the counter becomes zero.
Best regards,
Posted: Wed Oct 19, 2005 10:26 am
If you keep the output compare and count the number of overflow, you don't lose any resolution/accuracy at all 
Except if you introduce too much latency interrupt and want to match on a value next to 0x0000. Beware of interrupt priority and order they will be taken, there is a special Application Note on this.
If someone wants reference to this AppNote, just yell and I'll put a link.
Cheers,
Posted: Wed Oct 19, 2005 4:56 pm
Yes, the Application Note link would be of interest to me.
Fortunately, I have thus far been able to avoid these extra complications - I have been able to make the output compare period less than the overflow period. Further, my longer timing intervals are generally non-critical, so that the simpler polling methods are suitable, and with no hardware limits imposed for multiple timeout periods.
Regards,
Posted: Thu Oct 20, 2005 2:11 pm
Hi All,
It's actually an Engineering Bulletin, my mistake.
Link follows: Engineering Bulletin 389
Enjoy,
