Real-time software concepts are almost as old as conventional programming con- cepts. A software program that allows the machine resources to be divided between multiple tasks is called a real-time kernel. The name kernel is appropriate because a kernel is the small but critical center of the programming environment. It is basi- cally a task switch.
A real-time operating system contains a kernel and the basic disk, keyboard, mouse, and communications facilities found in conventional operating systems. Special microcomputer systems designed for factory automation sported simple real-time operating systems as early as the 1970s.
text
Get Character Subroutine Serial Input Interrupt
Push Registers on Stack_0
Swap Stack Pointer to access Stack_1
Get Serial Byte from UART into Register A
Return from subroutine into
serial program Push Registers
onto Stack_1
Serial Task Exit
Swap Stack Pointer back to Stack_0
Pop Registers off of Stack_0
Return from Interrupt
Call Serial Task Exit
Pop Registers from Stack_1
Return from Subroutine w/
Character
Main Program Thread Communications Thread
The various operations that the computer has been programmed to perform are called tasks or threads. The kernel is the first code to execute when the computer is booted, and it essentially decides which tasks should receive the resources of the CPU and at what time. The kernel controls most of the interrupts of the system.
In most real-time systems, the kernel switches the CPU between tasks so rapidly that all of the tasks appear to be operating simultaneously. This is of course an illu- sion since the CPU can only execute one instruction at a time, but with CPU clock speeds in the gigahertz range, the CPU is virtually performing multiple tasks at the same time.
When the kernel switches tasks, it must do more than simply save the return address of the program it is interrupting. It must save the context. The context is the tempo- rary data that the computer was manipulating to accomplish its task. This is most commonly the values of the CPU’s registers, and any data already on the stack.
;---
; Serial Input Interrupt Procedure
;
SER0IN:PUSH HL PUSH DE PUSH BC PUSH IX
LD (SPMAIN0),SP ;Save main stack pointer.
LD SP,(SP0)
;
IN0 A,(RDR0) ;Get received character.
AND 07FH ;Strip bit 8.
RET ;Return back into LOADER.
;
;---
;GETCHR is called from the serial loader
;program as if it were a subroutine used
;to wait for the next character. The
;the stack is switched back to the main
;program stack and the task is suspended
;until the next character arrives.
;
GETCHR0:PUSH IX PUSH HL PUSH DE
; Back to foreground.
CALL SR0EXIT
; Return from foreground.
POP DE POP HL POP IX RET
;---
; EXIT from Interrupt level 1.
; (Return to Foreground)
SR0EXIT:LD (SP0),SP LD SP,(SPMAIN0) POP IX
POP BC ;Restore registers POP DE
POP HL
RETI ;Restore interrupts & exit.
;
;---
Figure 3.3 demonstrates just how simple a context switching can really be. The
“looking glass” is the middle of the diagram. To the main program thread, the se- quence on the left side of the figure looks like an ordinary serial interrupt. To the communications program thread, the sequence on the right side of the diagram looks like an ordinary subroutine. The communications thread will look like any ordinary program which calls the Get Character routine whenever it needs input. This is the magic routine referenced in Figure 3.2! In addition to making programs easy to code, not a single cycle of the CPU is wasted waiting for the serial character to come in!
The example of Figure 3.3 is shown coded in humble Z-80/Z-180 code in Figure 3.4.
Unlike a conventional serial interrupt routine, the communications thread that calls Get Character maintains its context. That is to say that it can ask for a character until it sees the beginning of an incoming message, and then repeatedly ask for characters it expects to see if the message is valid as shown in Figure 3.2. If a complete message is received, or if invalid characters are received, it will loop back to looking for the beginning of the next incoming message. It looks like an ordinary single threaded program, but it only runs when new data arrives and releases the processor when it has processed that data and needs more.
Now if you have digested this bit of trickery, consider that the left half of the dia- gram does not necessarily represent an interrupt that occurs when the main thread is executing. The fact is it doesn’t matter whether the main thread is executing, or another interrupt, or another independent thread. Context switching is entirely stack-based and therefore indifferent to sequence. Note, however, that the stack- pointers must be kept in dedicated memory storage that is reserved for this single event so that they may be restored during a context switch.
Note also that the stack pointers for all threads must be initialized to point at the top of their respective stacks before interrupts are enabled. Also note the initializa- tion program must push the starting address for each thread onto its respective stack
Figure 3.4. Simple multitasking serial input routine coded for the Z-180 family
so that it will be available for the first “return” into the thread. Only the main thread, which starts at reset, does not require its stack to be initialized in this way.
Finally, notice that even though this process is stack oriented, such interrupts are not reentrant. For this reason, the interrupt that causes the context switch must remain masked (disabled) until the context has been restored. In most systems, this is the default and the programmer would have to reenable the interrupt intentionally to cause a problem.
If you are going to write programs for dedicated microprocessors that do not have operating systems, you need to master this technique. If you are using a system that has context switching, it is important to know how it works in order to use it most efficiently.