Timer driven interrupts on the 68K processor |
In order to see the effect that the 68K CISC architecture has on interrupt handling, we shall use exactly the same format in this section as for the PowerPC RISC timer routine.
The main task is essentially a loop that increments a counter. However, the loop is set up in such a way that can never exit without some external agency. The pseudo code for both the 68K and the PowerPC obviously must be identical as the processors are performing the same task.
global variables counter, semaphore; main() { long inc = 1; counter = 0; semaphore = 0; while (semaphore == 0) counter += inc; }
The solution to this task can be found in the file 68kmain.s. Try to develop your own code before downloading my version.
When you examine my code, you will see that I have maximized the chance that the interrupt service routine and the main task will have problems with the semaphore variable. This provides the opportunity to demonstrate (in an over simplistic way) the problem with two tasks reading and writing the same variable, a common problem with a multi-tasking system.
Internal timers on processors come with a variety of properties
The SDS simulator timer effectively has the following structure
struct timer { unsigned char level; // Which interrupt level (0 -- 7) unsigned char vector; // Auto-vector number (0 -- 127) short int notused; long int timer_reload; // Timer reload variable }
You will see the effect of this "timer structure" as we initialize the timer prior to using it. The structure has components that can be recognized as equivalent to the registers of either an internal or external timer.
The interrupt task is to check whether the counter value is even. If it is even then set the semaphore variable to 1 and cause the main task to exit. Again try and develop your own solution before looking at the answer in file 68kisr.s.
Note that the "return-from-interrupt" on the 68K processor is actually an RTE -- return-from-exception. Exception is the name given to interrupts in the 68K family.
Note that there is a possibility that the interrupt service routine will change the semaphore variable, only to have the new value over written by the main task writing the semaphore variable. How would you modify the ISR code to check to see whether that did happen? Would the changes you make in your code to check whether the over write occurred change the chances that the overwrite of the semaphore variable would occur? One of the problems with debugging interrupt code is that the additional code added to the ISR may change conditions sufficiently that the problem disappears (or introduce new ones). Many ISR problems are associated with timing jitter or noise.
The startup code for enabling 68K interrupts has the following format
Set-up the stack De-activate interrupts to avoid problems while initing Clear the semaphore variables Set the timer reload variable (how often interrupts occur) Set the timer interrupt type you can choose any valid interrupt on the SDS simulator Set the interrupt vector address to point to the start of the ISR Set the timer interrupt level Activate the interrupts Call the main code
Look up any necessary operations and memory locations in the processor's User Manual now you know the format of what is required. Try and develop your own start-up routine before examining my version of the code in file 68kinit.s.
There are a number of pieces of magic to get the SDS simulator to recognize the timer and correctly respond to the timer interrupts
You might want to investigate the following
![]() |
Last modified: July 22, 1996 01:33 PM by M. Smith.
Copyright -- M. R. Smith