Classic/Legacy CodeWarrior中的主题 Re: Need some code samples of nested interrupts for MC68HC908AZ60A

Need some code samples of nested interrupts for MC68HC908AZ60A

Naveen — Wed, 13 Jun 2007 16:57:41 GMT

Hi all,
Could any one provide some code samples of nested interrupts for MC68HC908AZ60A microcontroller.
Thanks and regards
Naveen

Re: Need some code samples of nested interrupts for MC68HC908AZ60A

J2MEJediMaster — Wed, 13 Jun 2007 21:34:30 GMT

I couldn't find any application note that expressly mentioned nested interrupts, but I've attached two application notes that implement several interrupt routines simultaneously for a derivative MCU. The other thing I found out in my search is that you really have to watch your stack if you're going to nest interrupts. HTH.

---Tom

AN2687.pdf

AN2637.pdf

Message Edited by t.dowe on 2009-09-16 10:33 AM

Re: Need some code samples of nested interrupts for MC68HC908AZ60A

rocco — Sun, 17 Jun 2007 04:12:18 GMT

Hi, Naveen:

Sorry, I don't have any code examples that I can share, but I can offer a few tips. There are different situations where nesting interrupts are necessary, and I don't know what your situation is, so a code example may not be useful.

As Tom implied, nested interrupts can get messy in the '08 family, since the CPU has no interrupt priority level. On the '08s, interrupts are either globally enabled or globally disabled. The interrupt priority mechanism in the '08 family means nothing in this situation, as it only determines which interrupt is serviced when more then one occur at the same time. You can enable and disable interrupts individually for each device, but that can get very time consuming and error-prone when you try to do that within other interrupt service routines.

In my experience, there are two general situations where you need to nest interrupts. The first is where you have a single ISR that takes so long that you wish all other interrupts to preempt it. The second is where you have a single interrupt that is so critical that you wish it to preempt all other interrupts. All other situations are beyond the capability of my meager brain. Is your situation one of these two?

The first situation, where you have a single ISR that takes too long, is simpler than the second. Here, you simply enable interrupts globally within the ISR that you wish to allow to be preempted, typically near the beginning of the ISR. There is no need to disable interrupts again later, as the hardware will handle that. This will allow other interrupts to preempt this one ISR, but only one additional interrupt at a time. You will need an additional 5 bytes of stack space for the additional nested interrupt.

This first situation can be avoided if the processing that is making the ISR too long can be rolled out of the ISR and queued to run as a separate task by the ISR. This is how I would handle this situation today, but that is a topic for a separate thread.

The second situation, where you have a single critical ISR, is much uglier, spelled with a capital ug. Unfortunately, it is also more common, and the '08 family has no elegant way to handle it. The best solution is to avoid it by making all other ISRs as short as possible.

If it must be done, it could be done by globally enabling interrupts in all ISR except for the critical one. But this means that any interrupt can preempt any other, with the exception of the critical one, so shared resources must be carefully managed and critical sections identified and controlled. You must also insure that an interrupt can't re-occur while its ISR is still active, recursively re-executing the ISR and crashing your system. Also, enough stack space needs to be allocated for the potential situation where every ISR is active (5 bytes multiplied by the total number of possible interrupts).

As I eluded to earlier, you can prevent unnecessary nesting by disabling and later re-enabling individual interrupts prior to enabling interrupts globally within an ISR, but that would add some serious overhead within each ISR. If the point was to enhance the response to interrupts, then this approach could be counter-productive.

Re: Need some code samples of nested interrupts for MC68HC908AZ60A

bigmac — Sun, 17 Jun 2007 13:13:29 GMT

Hello,

Further to Rocco's valuable comments, I got to thinking about the single critical ISR case, and considered just how much overhead would be necessary for the disabling and re-enabling of non-critical interrupts within each non-critical ISRs. It occurred to me that often HC908 and HCS08 applications do not require to have very many operational interrupts, and the overhead might not be too severe if there were perhaps, say only 2 or 3 non-critical interrupt sources.

The following is my perception of what a non-critical ISR might need to do -

ISR_PROC:

PSHH

; Clear current interrupt flag - normal requirement

; Disable current interrupt to prevent recursion,

MOV #val,CTRL_REG ; 4 cycles

; For each other non-critical interrupt:

; Store current control register value to stack,

LDA CTRL_REG ; 3 cycles

PSHA ; 2 cycles

; Disable non-critical interrupt,

MOV #val,CTRL_REG ; 4 cycles

CLI ; Enable interrupts, 2 cycles

; ISR processing code

SEI ; Disable interrupts, 2 cycles

; Re-enable current interrupt,

MOV #val,CTRL_REG ; 4 cycles

; For each other non-critical interrupt:

; Restore previous register value,

PULA ; 2 cycles

STA CTRL_REG ; 3 cycles

PULH

RTI

For example, for one critical interrupt and three non-critical interrupts, the following additional overheads would be necessary:

Prior to enabling interrupts within the ISR, 24 cycles.

After interrupts are again disabled, and prior to exit from ISR, 14 cycles.

To keep these additional overheads in perspective, the "normal" overheads for an ISR, not including the ISR processing code, would amount to about 26 cycles.

ISR_PROC: ; 9 cycles for entry

PSHH ; 2 cycles

; Clear current interrupt flag, assume 6 cycles

; ISR processing code

PULH ; 2 cycles

RTI ; 7 cycles

Regards,

Mac