8-bit Microcontrollers中的主题 Re: RTI Undocumented "Feature" in QG8 & Similar

RTI Undocumented "Feature" in QG8 & Similar

Wings — Sun, 21 May 2006 16:46:41 GMT

I've discovered that the RTI prescaler is cleared whenever you stop the RTI (by clearing the 3 RTIS bits). All it says in the datasheet is that the RTI is disabled when RTIS = 0:0:0. I asked about this a while back in this forum and now here is the answer to my own Q, in case anyone else has a need for this tidbit.

For my application, this is a good thing.

I tested it this way: I set up a 15ms RTI, and when the RTI fired I delayed 7ms in a software loop, then cleared the RTIS bits and immediately set them back the way they were. The result was that the next RTI occurred 15ms after the RTIS clearing and not 8ms afterwards, so the prescaler must have been cleared as well.

Re: RTI Undocumented "Feature" in QG8 & Similar

Alban — Tue, 06 Jun 2006 18:47:00 GMT

Just noticed ur post,
Being looked into...
The datasheet will be updated when it's properly verified and validated, and reviewed 600 times.

Thanks for highlighting this.
I put a Service Request

Alban.

Re: RTI Undocumented "Feature" in QG8 & Similar

Alban — Tue, 06 Jun 2006 19:52:46 GMT

Euh Wings...Is it not more a software consideration with the clock selection ? (Bus or 1kHz)
See Fig 1-2 of QG8 datasheet rev1.01.
Your problem looks like you're running from the bus and the bus clock is either changed or not the one you expected.

Here something u could look into. FSL is OK with their check.

Alban.

Re: RTI Undocumented "Feature" in QG8 & Similar

mke_et — Tue, 06 Jun 2006 22:06:20 GMT

I took over some 'legacy' code from another project and saw where the guy had counted out his cycles and then calculated back from that for timing on the interrupt. I could never understand why, but then realized the problem he was fighting.

Problem is, when your ISR has a variable time in the interrupt.

I always do my EOI processing at the start of the handler, then put a check to see if it's reentrant.

Would doing that always guarantee that you are inside the window where the time in the interrupt would add to the interrupt time? Or would it at least always give you a guaranteed fixed time for your interrupt to next interrupt? Inquiring minds want to know!

Actually, in my case, I don't treat any RTI as an accurate timer, I always use it as at most a housekeeping timer to clean some things up. If I need an accurate timer, I always use one of the timer channels with a compare and always program the 'next match' so that it's independant of what else is going on. That way even if the int is held off by another routine disabling the int, it will always stay 'on track' with true time.

Mike