Kernel Independent Transport Layer
The OEMInit function is the main OAL routine that initializes board-specific peripherals, sets up the kernel variables, and starts KITL by passing a KITL IOCTL to the kernel. If you added and enabled KITL in the run-time image, the kernel starts KITL for debugging over different transport layers, as discussed in Chapter 4, "Debugging and Testing the System."
Table 5-6 lists the functions that the OAL must include to enable KITL support on a new platform.
Table 5-6 KITL support functions
| Function | Description |
|---|---|
| OEMKitlInit | Initializes KITL. |
| OEMKitlGetSecs | Returns the current time in seconds. |
| TransportDecode | Decodes recevied frames. |
| TransportEnableInt | Enables or disables KITL interrupt if it is interrupt based. |
| TransportEncode | Encodes data accroding the transport's required frame structure. |
| TransportGetDevCfg | Retrieves the device's KITL transport configuration. |
| TransportReceive | Receives a frame from the transport. |
| TransportSend | Sends a frame using the transport. |
| KitlInit | Initializes KITL system. |
| KitlSendRawData | Sends raw data using the transport bypassing the protocol. |
| KitlSetTimerCallback | Registers a callback that is called after a specified amount of time. |
| KitlStopTimerCallback | Disables a timer used by the above routine. |
Profile Timer Support
Located at the core of the operating system, the OAL is a perfect choice for mechanisms to measure the performance of the system and support performance optimization. As discussed in Chapter 3, "Performing System Programming," you can use the Interrupt Latency Timing (ILTiming) tool to measure the time it takes to invoke an interrupt service routine (ISR) after an interrupt occurred (ISR latency) and the time between when the ISR exits and the interrupt service thread (IST) actually starts (IST latency). However, this tool requires a system hardware tick timer or alternative high-resolution timer that is not available on all hardware platforms. If the new hardware platform supports a high-resolution hardware timer, you can support ILTiming and similar tools by implementing the functions listed in Table 5-7.
Table 5-7 Profile timer support functions
| Function | Description |
|---|---|
| OEMProfileTimerEnable | Enables a profiler timer. |
| OEMProfileTimerDisable | Disables a profiler timer. |
The OAL must also support interrupt handling and the kernel scheduler. The scheduler is independent of the processor type, yet interrupt handling must be optimized for different types of processors.
Integrating New Device Drivers
Apart from the core system functions, the BSP also contains device drivers for peripherals. These peripheral devices can be components on the processor chip or external components. Even when separate from the processor, they remain an integral part of the hardware platform.
Device Driver Code Locations
Table 5-8 lists the source code locations for device drivers according to the PQOAL model. If your BSP is based on the same processor as the reference BSP, then the adaptation of device drivers mainly requires modification to the source code in the %TGTPLATROOT% folder. It is also possible to add new drivers to the BSP if the new platform includes peripherals that are not present in the reference platform. For more information about developing device drivers, see Chapter 6, "Developing Device Drivers."
Table 5-8 Source code folders for device drivers
| Folder | Description |
|---|---|
| %_WINCEROOT%\Platform\%_TGTPLAT% | Contains platform dependent drivers. |
| %_WINCEROOT%\Platform\Common\Src\Soc | Contains drivers for processor-native peripherals. |
| %_WINCEROOT%\Public\Common\Oak\Drivers | Contains drivers for non-native peripherals that include external controllers. |