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.

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

Other Resources

Migrating a BSP to Windows Embedded CE 6.0