Handling both RTCC and WKEN_B interrupts
Keith M
Posts: 102
I looked through the standard books, datasheets, whatever, and didn't find my answer.
If I enter an ISR through a WKEN_B interrupt, does this reset/clear the RTCC?· Meaning, if I have RTCC set to overflow at 2us, and I trigger as a result of edge detection, will the next overflow happen 2us later or some amount less than 2us(ie whatever was left on the clock)?· Do I have to manually reset RTCC if I want this functionality(if so, how to?)
I'm guessing the counter (re)starts when I *leave* the ISR as a result of the "RETURNINT" SX/B command or the reti, retiw (IIRC) instructions.· This is the functionality I need.
Thanks.
Keith
·
If I enter an ISR through a WKEN_B interrupt, does this reset/clear the RTCC?· Meaning, if I have RTCC set to overflow at 2us, and I trigger as a result of edge detection, will the next overflow happen 2us later or some amount less than 2us(ie whatever was left on the clock)?· Do I have to manually reset RTCC if I want this functionality(if so, how to?)
I'm guessing the counter (re)starts when I *leave* the ISR as a result of the "RETURNINT" SX/B command or the reti, retiw (IIRC) instructions.· This is the functionality I need.
Thanks.
Keith
·
Comments
The RTCC and RB edge detection are totally independent, although there is ony one interrupt vector, and that is at $000. When either RTCC overflows or an edge is detected, the processor switches to the interrupt routine at that $000 vector.
During an ISR entry due to an edge detect event, the RTCC keeps counting as per normal. Should the value of the RTCC counter have been such that a rollover occurs while it was already in the ISR, then that occurrence would go unnoticed by the interrupt routine and must make specific code to poll the value of the RTCC, and deal with the roll-over in your (ISR) software.
The RTCC is not cleared or adjusted by the processor when an edge detect interrupt occurs, and the next interrupt would occur at the normal next 2 uSec interval. Clearly you will have a conflict if the 2 uSec time roll-over occurs while you are already in an edge detect interrupt. Polling for this occurrence while in interrupt allows you to deal with that.
Cheers,
Peter (pjv)
The first solution may not work if the overflow occurs in those few cycles it takes to compare and decide.
In a nutshell the RTCC is not cleared, if this is the behavior you want, you'll have to clear it manually.
We want an interval of 100 cycles ( 50 Mhz / 500Khz ) or 2 microseconds / .02 microseconds.· The RTCC interrupt happens when the RTCC goes from 255 to 0, so it is counting up during your interrupt.·
Suppose your interrupt took 50 cycles, or half what we want as an interval.· When you do the RETIW with W holding -100, at the end just before the return, the RTCC gets loaded with 50 - 100 or -50 which means it will take it 50 cycles to hit again 0 and trip the interrupt.· Just what you want for regular periodic interrupts.
But that isn't quite what we want.
Remember, in the case of the MFM decoder, we want to use the RTCC as a one shot timer of sorts.·· And the interval you end up with isn't really too critical.· We want to sample a little bit longer than half a cell time, or 2 microseconds.· With no pre scaler on the RTCC we are looking at the 100 counts.
What you want to have happen is for a B pin interrupt to happen so you are in sync,· shift that 1 bit into your bit accumulator or MFM shift register, whatever you want to call it.· You then want to load the RTCC register with 255-100 or· 155 and do a normal RETI.· The additional time just moves us out a little so we don't get an RTCC interrupt before a possible B edge detect.· If you don't get a transition before the 2 microseconds plus a little, the RTCC interrupt happens, you check the B pin WKPND register, and if it isn't set, you clock a 0 into your MFM shift register.· Then reload the timer as before to wait for the next (approximately) half bit boundary.
To make it easier, you could always clear the RTCC at the start of an interrupt, no matter the cause.· At the end do the standard RETIW with the -100 value in W and the intervals will be close enough for jazz. The time should only be off by the difference in cycles from the start of the interrupt to the clear, which, should only be the interrupt latency of 3 cycles plus 1 if you always have the RTCC in register space and use CLR RTCC as the first instruction. If that is a problem, you can just off set the value of W before the RETIW.
Here is my cut at it, tested on SXsim, seems to work the way I intended it to.· Boy that formatted code window has issues with tabs.......
Post Edited (Michael Chadwick) : 3/14/2005 8:12:10 PM GMT
I've made several attempts in SX/B writing the code with a couple different approaches.· None of them have panned out.· I'm sure I'm dealing with sync problems at this point --- I have to play with this stuff more before it starts to get intuitive...· I guarantee my problem is I'm not handling the RTCC correctly.
I'll take a good look at your code.
Thanks to everyone who replied.
Keith
·
Here is a debugging trick you might already be using. Set an output bit at the start of the ISR and clear it at the end. Assuming your scope has dual trace, you can look at when the ISR happens in relation to the incomming data, and see how long the ISR takes by the length of the pulse.
I've edited the code I posted to show that.
If you have more than 2 channels, or if your scope has an external trigger, you could sync on the attention line to the PC and see where the end of the byte is and when the PC is supposed to be transfering it. That would sync you to the start of the next byte, so you could see what should be coming into the shifter, as well as if the attention line is getting set every 8 bits.
Another variation would be to copy the state of the WKPND bit to the output bit, so you can see whether the ISR is interrpreting the data as a 0 or a 1.
With a scope and an output bit, you can get some good visibility into what your code is doing relative to the data.
Mike
<vent> You know, I've been programming(on the side, not for a living) half-seriously for probably about 15 years. Nothing irks me more than to have something very very simple NOT work. It's not the COMPLICATED things I get mad about not working -- I expect to have problems and to spend lots of troubleshooting time on HARD problems. But the easy stuff, that's just supposed to work on its face, that's what I get mad about not working </vent>
I don't particularly like my current routines anyways. I'm going to shift more of the programming out of the ISR and more into the main --- which I guess is a good design goal. Keep the ISR as short as possible.
Keith
My most memorable bug was in my Z80 assembler days, working on the program for a piece of test equipment, a scanning optical densitometer. Used to measure color test targets on printing.
I had coded some new scan routines to do automatic color bar recognition, that seemed to be working pretty well. Finished them up on a Monday. The gizmo was going to be shipped on Tuesday, so it all looked good. Everything tested out OK.
On Tuesday morning the head of the service department, who was going to do the installation, ran through a test of the unit's function, part of which was to test the scanning on the customer's color bar. Didn't work. Bombed most convincingly.
What the *&#%? "It worked fine yesterday!"
I scratched my head a bit thinking about the problem and a light bulb went off. The scanner had a real time clock that displayed the date and time on a CRT as part of the instrument's display. I reset the date to Monday.
It worked just fine. Oooops.
In my scanning code, I had re-used the memory locations used by the clock output. Perfectly legal, and sometimes a must to re-use temp ram like that, which was always in short supply. (1984 ish, ram wasn't cheap.)
But I had forgotten to *clear* it first. Or at least a particular byte that I used to hold flags indicating the state of the scan.
So the program would work fine, except on Tuesdays and Thursdays. Fortunately I found it pretty quickly, and the service guy was able to load the unit into the company van and deliver it on time.
But I won't forget that one.
As you hunt your bugs, keep in mind that the processor (usually) is doing *exactly* what you told it to do.
Mike
This is entirely OT BUT Pantone has this really cute handheld spectro-colorimeter.· Under $250 too!
http://www.pantone.com/products/products.asp?idSubArea=0&idArea=2&showNav=94&idProduct=373
I've contemplating buying one but the reports on it aren't very favorable --- at least not in the serious context....
Keith
Post Edited (Keith M) : 3/17/2005 4:15:39 PM GMT