Production-Quality OAL
Other versions of this page are also available for the following:
.gif "A hyphen indicates that the information in this topic is not relevant for this platform, or that the platform does not support the API that is listed.")
.gif "A checkmark indicates that the information in this topic is relevant for this platform, and that any API listed is also supported on this platform.")
8/27/2008
The production-quality OEM adaptation layer (OAL) 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 Embedded 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 SOC Directory Layout. - Conventions for BSP development
For more information, see BSP File-Naming Conventions.
In Windows Embedded CE, 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 Embedded 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 Embedded CE, it will still work in Windows Embedded CE 6.0.
See Also
Concepts
Best Practices for Developing a Production-Quality OAL
Best Practices for Secure and Reliable OAL
Hardware Platforms with Production-Quality OAL Support