Production-Quality OAL (Windows CE 5.0)
The production-quality OEM adaptation layer (OAL) available in Microsoft® Windows® CE 5.0 simplifies and shortens the process of developing an OAL. It provides you with an improved level of OAL componentization through code libraries, directory structures that support code reuse, centralized configuration files, and a consistent architecture across processor families and hardware platforms.
The processor and hardware platform framework provided by the production-quality OAL enables you to develop the most basic Windows CE kernel — a Tiny Kernel image — with little development effort.
The production-quality OAL provides the following improvements over the previous OAL model:
A common set of processor-specific components
OAL software components
For more information, see Production-Quality OAL Components.
A standard directory structure
For more information, see BSP and CSP Directory Layout.
Conventions for BSP development
For more information, see BSP File-Naming Conventions.
In Windows CE 5.0, you can still clone an existing BSP. However, the %_WINCEROOT%\Platform\<Hardware Platform Name> BSP directory now contains minimal code files and these are mainly configuration files. Most of the BSP code files are now located in the %_WINCEROOT%\Platform\Common directory and do not have to be modified unless your hardware platform implementation is significantly different from the Windows CE implementation. You now reference the software components as libraries.
The OAL libraries are a collection of functional, static libraries that you can assemble, in a modular approach, to create an OAL or boot loader. The individual libraries conform to a set of APIs common across all CPU architectures. The hardware library is organized and implemented in a consistent fashion according to hardware architecture, part number, and functional-level to help you determine the level of hardware support needed and to create a self-documenting directory structure.
The production-quality OAL allows you to use consistent hardware across a family of processors. To accomplish this, the hardware library implements the core functions for OAL functionality that interact at the chip level. Board-level operations, such as IRQ routing or glue-logic interactions, remain in the %_WINCEROOT%\Platform\<Hardware Platform Name> directory, but they are simplified and abstracted across all architectures, whenever possible.
You can now extend the functionality in your hardware platform by using callbacks. For example, in the interrupt code for the CPU architectures, a particular CPU interrupt timer has been implemented. However, because some aspects of how interrupts are wired to the system are still board-dependent, there is no comprehensive set of interrupt routines for every hardware platform. Instead, the built-in callbacks can call into OEM code and you can customize how you want the interrupts to be handled.
Note If you have an existing BSP, you are not required to use the production-quality OAL or migrate to the new OAL model. If you have a BSP that works in previous versions of Windows CE, it will still work in Windows CE 5.0.
See Also
Best Practices for Developing a Production-Quality OAL | Best Practices for Secure and Reliable OAL | Hardware Platforms with Production-Quality OAL Support | Developing an OEM Adaptation Layer
Send Feedback on this topic to the authors