Optimize Sysgen Usage (Compact 2013)
3/26/2014
Catalog items are associated with Sysgen variables. When you select a catalog item in Platform Builder, you increase ROM size because you are pulling in the code for the selected Sysgen and any Sysgens that it depends on. This topic discusses some ways to minimize the number of Sysgens that you use (and therefore the amount of code that gets added to your build).
- Analyze the Sysgens that are enabled in your OS to eliminate unnecessary code and files. Focus on Sysgens that control your module and Sysgens that your module depends on. To perform this analysis, check in Platform Builder, batch files, and ceconfig.h. For more information, see Analyze OS Configuration.
- Use only the Sysgens that your project requires to successfully build. If your module can build without a Sysgen, you do not need it. For example, perhaps you wrote a reusable module that works with or without a software-based input panel (SIP). In this module, you call SipGetInfo to test whether a SIP is present, and then act accordingly. However, you know that the particular device for which you are designing the OS does not use a SIP. In this case, you do not want to include SYSGEN_SOFTKB in the OS because it will take up space unnecessarily. Instead of enabling SYSGEN_SOFTKB, you could write a stub for SipGetInfo, delay-load the DLL, or use GetProcAddress to determine whether an implementation of SipGetInfo exists, and if not, treat it as if the SIP is disabled.
- Create a board support package (BSP) that can adapt to Sysgens. Have your BSP adapt to different Sysgen combinations by using Cesysgen conditional statements and by compiling components into separate libraries. For more information, see Cesysgen Conditional Statements [Optimization] in the Optimize ROM Usage guide. The following section discusses this strategy in greater detail.
Sysgen-Aware BSPs
Making your board support package adaptable to Sysgens primarily benefits silicon vendors (SVs), original equipment manufacturers (OEMs), or their partners who create BSPs that are designed to support platforms with multiple configurations, such as option packages.
- Use Cesysgen conditional statements. You can use Cesysgen conditional statements to build only the BSP components that your OS will use. For example, you can use conditional statements in files such as platform.bib, platform.reg, and DIRS. In the following excerpt of a DIRS file, the battery driver code is included only if the battery module is needed.
.png "Optimizing ROM Footprint - DIRS2")
- Compile separate libraries. Another (more advanced) way that you can adapt your BSP to different Sysgen combinations is to compile it in such a way that the components are in separate libraries, and link to the libraries only when necessary. For example, you can compile a touch driver into its own library and, when touch is enabled in the OS design, have the linker pull in the driver. This approach shortens BSP build time too.
You can create a build rule in %_WINCEROOT%\platform\<BSP Name>\cesysgen\makefile to support compiling separate libraries. How to create build rules is beyond the scope of this guide, but you can look at %_WINCEROOT\public\common\cesysgen\makefile for reference, or search for the term “build rules” on MSDN. The sample BSPs that ship with Windows Embedded Compact 2013 do not often use build rules, but the Device Emulator BSP that shipped with Windows Embedded CE 6.0 used many, so you can look at the makefile file of the Device Emulator BSP if you have Windows Embedded CE 6.0 installed. For more information about the build tools and makefiles, see Build System Command Line Tools.