The answers to the Circuit Cellar 270 Engineering Quotient are now available. The problems and answers are listed below.
Problem 1: Given a microprocessor that has hardware support for just one level of priority for interrupts, is it possible to implement multiple priorities in software? If so, what are the prerequisites that are required?
Answer 1: Yes, given a few basic capabilities, it is possible to implement multiple levels of interrupt priority in software. The basic requirements are that it must be possible to reenable interrupts from within an interrupt service routine (ISR) and that the different interrupt sources can be individually masked.
Question 2: What is the basic scheme for implementing software interrupt priorities?
Answer 2: In normal operation, all the interrupt sources are enabled, along with the processor’s global-interrupt mask.
When an interrupt occurs, the global interrupt mask is disabled and the “master” ISR is entered. This code must (quickly) determine which interrupt occurred, disable that interrupt and all lower-priority interrupts at their sources, then reenable the global-interrupt mask before jumping to the ISR for that interrupt. This can often be facilitated by precomputing a table of interrupt masks for each priority level.
Question 3: What are some of the problems associated with software interrupt priorities?
Answer 3: For one thing, the start-up latency of all the ISRs is increased by the time spent in the “master” ISR. This can be a problem in time-critical systems. This scheme enables interrupts to be nested, so the stack must be large enough to handle the worst-case nesting of ISRs, on top of the worst-case nesting of non-interrupt subroutine calls.
Finally, it is very tricky to do this in anything other than Assembly language. If you want to use a high-level language, you’ll need to be intimately familiar with the language’s run-time library and how it handles interrupts and reentrancy, in general.
— ADVERTISMENT—
—Advertise Here—
Answer 4: Yes, on most such processors, you can execute a subroutine call to a “return from interrupt” instruction while still in the master ISR, which will then return to the master ISR, but with interrupts enabled.
Check to see whether the “return from interrupt” affects any other processor state (e.g., popping a status word from the stack) and prepare the stack accordingly.
Also, beware that another interrupt could occur immediately thereafter, and make sure the master ISR is reentrant beyond that point.
Contributed by David Tweed
— ADVERTISMENT—
—Advertise Here—
Circuit Cellar's editorial team comprises professional engineers, technical editors, and digital media specialists. You can reach the Editorial Department at editorial@circuitcellar.com, @circuitcellar, and facebook.com/circuitcellar
