BSP Directory Rearchitecture Porting and Best Practices (Windows Embedded CE 6.0)
1/5/2010
In Windows Embedded CE 6.0, the BSP directories have been restructured to improve the production-quality OEM adaptation layer (OAL), and to take maximum advantage of code reusability.
Directory Structure Changes
The following list is a summary of the differences between Windows CE 5.0 and Windows Embedded CE 6.0:
Public\Common\OAK\CSP\...
has been moved to
Platform\Common\Src\SOC\...Chipset-specific code in:
- Platform\Common\Src\x86\...
- Platform\Common\Src\ARM\...
- Platform\Common\Src\MIPS\...
- Platform\Common\Src\SHx\...
has been moved to - Platform\Common\Src\SOC\...
Note
Code that is specific to a CPU or is reusable by all platforms will still reside in Platform\Common\Src<cpu> or Platform\Common\Src\Common.
In the process of migrating to Platform\Common\Src\SOC\..., the directory, library, and dll names have been associated with a vendor and version to prevent conflicts.
The naming convention for the directory is:
<soc name>_<vendor name>_<version>.
Each compiled library or dll should have the directory string embedded somewhere in it. This guarantees there will be no conflicts.
For example, the code supporting the HD64465 companion chip for the Renesas Tahoe board resides in the Platform\Common\Src\SOC\HD64465_ms_v1 directory.
This indicates to that the code is for the HD64465 board, the code was created by Microsoft, and this is the first iteration of that code in the Platform\Common\Src\SOC directory.
Porting Guidelines
To port your BSP from Windows CE 5.0 to CE 6.0, you will need to make some minor changes in your BSP sources files.
Here are the porting guidelines:
- If you were including a .dll built in the Public\Common\OAK\CSP directory, you will need to rename that .dll in your Platform.bib file to match the versioned name.
For example, you would need to change the HD64465_ochi.dll entry in your Platform.bib file to HD64465_ms_v1_ochi.dll. - If you were linking with a static library with a "_lib" suffix built in the Public\Common\OAK\CSP directory, you will need to find the corresponding code in Platform\Common\Src\SOC, clone that code into your BSP (platform\<bsp name>) directory, and build a static library to link with there.
For example, if you were linking with HD64465_uart_lib.lib you would need to copy the Platform\Common\Src\SOC\HD64465_ms_v1\Serial directory into your BSP, create a sources file with TARGETTYPE=LIBRARY, and link with that library instead. - If you were linking with a static library without a "_lib" suffix built in the Public\Common\OAK\CSP directory, you will need to rename your link target in your sources file to match the new versioned name, and change the target path to Platform\Common\Lib\... from the public path.
For example, if you were linking with $(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\HD64465_wavedev.lib you would need to link with $(_PLATCOMMONLIB)\$(_CPUDEPPATH)\HD64465_ms_v1_wavedev.lib. - If you were including header files from Public\Common\OAK\CSP\..., you will need to change your $(INCLUDES) in your sources file to point at the corresponding Platform\Common\Src\SOC\... include directory.
For example, if you were including files from Public\Common\OAK\CSP\SHx\HD64465\Inc, you should now include files form Platform\Common\Src\SOC\HD64465_ms_V1\Inc. - If you were linking with a SoC-specific library in Platform\Common\Src\<cpu>\..., you will need to update your sources file to link with the versioned name.
For example, if you were linking with Oal_power_shx7750r.lib, you would now need to link with oal_power_shx7750r_ms_v1.lib.
Now that all your SOC/CSP code is located in one place, you can ship your reusable code in the same place that Microsoft does.
The following table contains a list of the changes.
| Previous Location | New Location | Changes Required |
|---|---|---|
Public\Common\OAK\CSP\MIPS\Broadcom |
Removed (the BCM11 BSP is no longer supported) |
If you were including these headers, clone the previous version's headers into your platform directory. |
Public\Common\OAK\CSP\SHx\HD64465\Inc |
Platform\Common\Src\SOC\HD64465_MS_v1\Inc |
If you were including these headers, replace the Public\Common\OAK\CSP include path with Platform\Common\Src\SOC include path. |
Public\Common\OAK\CSP\SHx\HD64465\Kbdmouse |
Platform\Common\Src\SOC\HD64465_MS_v1\Kbdmouse |
|
Public\Common\OAK\CSP\SHx\HD64465\Serial |
Platform\Common\Src\SOC\HD64465_MS_v1\Serial |
HD64465_uart.dll becomes HD64465_ms_v1_uart.dll. Still built normally. Drivers linking with $(_COMMONOAKROOT)\Lib\$(_CPUINDPATH)\HD64465_uart_lib.lib should now clone the code from the new location into their Platform directories and link there. |
Public\Common\OAK\CSP\SHx\HD64465\USB |
Platform\Common\Src\SOC\HD64465_MS_v1\USB |
HD64465_ochi.dll becomes HD64465_ms_v1_ochi.dll. Still built normally. Drivers linking with $(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\HD64465_ochi_lib.lib should now clone the code from the new location into their Platform directories and link there. |
Public\Common\OAK\CSP\SHx\HD64465\Wavedev |
Platform\Common\Src\SOC\HD64465_MS_v1\Wavedev |
HD64465_wavedev.lib becomes HD64465_ms_v1_wavedev.lib. Drivers linking with $(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\HD64465_wavedev.lib \ should now link with $(_PLATCOMMONLIB)\$(_CPUDEPPATH)\HD64465_ms_v1_wavedev.lib. |
Public\Common\OAK\CSP\MIPS\NEC\VR4131\Inc |
Platform\commonsrc\SOC\Vr4131_MS_v1\Inc |
If you were including these headers, replace the Public\Common\OAK\CSP include path with Platform\Common\Src\SOC include path. |
Public\Common\OAK\CSP\MIPS\NEC\Vr4131\Serial |
Platform\Common\Src\SOC\Vr4131\Serial |
Drivers linking with $(_COMMONOAKROOT)\lib\$(_CPUINDPATH)\vr4131uart_lib.lib should clone necessary code from Platform\Common\Src\SOC\Vr4131\Serial into the Platform directory and use it there. |
Public\Common\OAK\CSP\MIPS\NEC\Vrc5477\Inc |
Platform\Common\Src\SOC\Vrc5477_MS_v1\Inc |
If you were including these headers, replace the Public\Common\OAK\CSP include path with Platform\Common\Src\SOC include path. |
.gif "Ee478201.collapse(en-US,WinEmbedded.60).gif")
Best Practices
The following list shows best practices for using the SOC directory:
- Follow the naming convention, <soc name>_<vendor name>_<version>, for the directory name and all library names.
- The dirs file in your directory should correspond to the CPU type that your SoC supports.
For example, an ARM-based SoC would have:
DIRS_ARM=\
directory1 \
directory2 \
etc. - Ensure that your code in the SOC directory is high quality. Putting code in the SOC directory is your way of saying that it is fit for reuse.
To enable code reuse, use good design practices, comment your code thoroughly, and avoid conditional compilation. - Place Catalog files in the Platform\Common\Src\SOC\<soc name>_<vendor name>_<version>\Catalog directory.
- Separate your reusable driver code from your reusable OAL code. Put driver code in the base directory and create an "OAL" a subdirectory for the OAL code.
See Also
Concepts
BSP Implementation Guide
Windows Embedded CE 6.0 BSP Directory Structure
BSP Migration Guide