Startup Operation

When the OS first starts, it performs a series of functions as described in Chapters 1 through 3. Prior to executing the first user task, the final function performed enables the user inter-rupts. This is accomplished with the use of an application-specific constant defined by the developer to enable the interrupts. This constant, INITIAL_INTERRUPT_DESCRIPTOR, is specific to both the application and the implementation. In this constant, any bit set to 1 enables the corresponding interrupt source. Essentially, the OS uses this constant as a parameter that is passed to EnableInterrupt().

8.4 Example Program

The example program now is optimized to use the power of interrupts to eliminate sampling of the shuffling switch and keypad. If I were to apply a profiler to the software at this point, I would observe that almost all of the time the software is running, it is in the background task.

The only time the application runs is after the player presses a key and a calculation is made.

In an application running in a battery-operated device, the background task would perform power management duties during these idle times to conserve the batteries.

Example Program

101 8.4.1 Modules

The modules startup.s,initspr.s,cinit.s,init.c,hw.c, and carddeck.c were not modi-fied.

main.c This module was modified to add a specific initialization function required by the board support package provided by Wind River. Init_ExtISRs() initializes the Wind River external ISR routines to a dummy ISR routine that traps spurious interrupts.

debug.c This module was modified to allow the ErrorHook() hook routine to log the cur-rent status of the interrupt mask to the error log. In addition, a special flag was added to avoid recursive calls of ErrorHook() because the current version (as of the writing of this book) of OSEKWorks only meets the OSEK/VDX OS v2.0 requirements. In the version 2.1 specification, recursive calls to this hook routine are prevented — the OS will not call Error-Hook() if an error occurs while it is running. The application must check service return values to trap an OS error in a service called from within ErrorHook().

cardgame.c This module was modified to eliminate the alarm SampleShuffleSwitchAlarm, which is not needed when using interrupts. In addition, one function was added to support the ISR.

GameState GetGameState(void)

This function simply returns the current state of the blackjack game, which is used in the ISR.

dispdrv.c OutputNewDisplay() now disables all interrupts while writing to the display, as discussed in this chapter.

keypad.c This module was extensively modified to support an interrupt-based keypad ver-sus a sampled keypad. The IOSampleKeypad task was replaced by the ISR IOReadKeypadISR and was significantly shortened. In addition, one new function was added.

void InitKeypad(InitType type)

This initialization function is invoked by InitSystem() and registers the ISR in the OSEK-Works-specific board support package. The initialization of the registers required to handle an interrupt is performed during startup within InitReg16() and InitReg32() using the tables defined in init.cfg with the names InitHardwareRegs16 and InitHardwareRegs32. os.c This module was modified to add DisableAllInterrupts() and EnableAllInter-rupts(), which are new to version 2.1 of the OS. In order to test the application code using these services, I had to simulate the function because OSEKWorks v4.0 only supports OSEK/VDX OS v2.0. When the new version of OSEKWorks is released, these two services will have to be removed or the build will fail at the link stage.

shuffle.c This module was also modified extensively to support the interrupts generated by the shuffle switch.

void InitShuffleSwitch(InitType type)

102

This initialization routine was modified to remove the initial state of the input and to register the ISR to the OSEKWorks board support package.

IOShuffleSwitchISR This ISR, which was discussed in this chapter, replaces the prior task,IOSampleShuffleSwitch, and extensively shortens the code. The INTERRUPT modifier is not defined because the board support package does not support ISR category 3 inter-rupts. However, if this routine is used on a different processor, the INTERRUPT macro should be defined as the modifier for an interrupt routine for the specific compiler. The definition for INTERRUPT is found in os.h.

ShufflingComplete task This task is activated when ShufflingCompleteAlarm times out, indicating that the switch is released.

8.4.2 Exercises

1. In an exercise in Chapter 5, a switch was added and the number of times that it was depressed was counted. Make sure that the switch is connected to an input that can gener-ate an interrupt when the switch is depressed and modify the routine to be an ISR.

2. Set a breakpoint in OutputNewDisplay() after the interrupts are disabled. Also set a break-point at the entrance to the keypad ISR. Press a key on the keypad and then step through the rest of the routine. Verify that the interrupt does not occur until after EnableAllInter-rupts() is invoked.

3. Review the source code and determine if there are other critical sections that need to be added.

8.5 Summary

In this chapter, I discussed how interrupts are handled in the OSEK/VDX OS. The categories of ISRs were introduced and the requirements for each category, with respect to the OS, was described. In addition, the many different methods of enabling and disabling interrupts and determining current interrupt status were discussed.

Interrupts are the most powerful method of optimizing throughput in the application.

However, when interrupts are introduced into an application, the possibility of problems increases because it is very difficult to debug interrupt-driven software. The example program uses interrupts for all user inputs because the application will probably be installed in a bat-tery-driven system, so it is very important to conserve battery power. The developer of the application will have to make the trade-off decision about using interrupts — complexity ver-sus efficiency.

103

9

Chapter 9

Interprocess

Communication

The final OS objects are interprocess communication, or messaging, objects that are actually part of the communication (COM) standard. In version 2.1 of the OS standard, any OS that is OSEK/VDX-compliant must support, at a minimum, conformance class A from the COM standard. Some implementations could include communication conformance class B, but this chapter describes the attributes of conformance class A only and the services available to sup-port this level of interprocess communication.

The OSEK/VDX COM standard is very complex and is covered in detail in Part 2. How-ever, some of the features, as they apply to the minimal requirements of the OS, are intro-duced here.

9.1 Communication Model

The OSEK/VDX COM standard supports both interprocess and interprocessor communica-tion. Many different features are required to support this wide range of communicacommunica-tion. The communication model for the limited requirements of a conformance class A implementation is as follows.

Unqueued messages Messages are not queued under a conformance class A implementa-tion. This means that a message can be read by an application any number of times and the data received last is returned every time; that is, it is not consumed by being read.