If you take Microsoft’s approach to releasing a Board Support Package (BSP) it is a very simple process, click, click, click and release. But if you want to protect some or all of your intellectual property (IP), or that of a vendor, then you may have some more work to do. In this article, I will discuss some of the issues that will need to be addressed.
First, what is a BSP? A BSP is a collection of board specific code that when built with a Platform Builder project will create a Windows CE OS for your embedded system. The code may include a bootloader, drivers, OAL and configuration files.
Microsoft’s approach is to release all of the code associate with the BSP. Their approach isn’t bad, for them. It works well for your customers, but may cause you to expose your IP in ways that you don’t want to expose it. The common solution is to create a Binary BSP, which is a collection of the binary output files from building your BSP. Those binaries include the exe, dll, lib files, and anything else you want to release. Of course the BSP must also include the necessary configuration files, like platform.bib and config.bib.
I have seen Binary BSPs released in several different forms. The most basic form is to delete all of the source code folders, leaving the FILES, Target and Lib folders. This certainly gets the binaries to your customer, but be sure to test it the way your customer will use it. Your customer will almost certainly run a clean build at some point, which by design will delete the contents of the Target and Lib folders. The only way for them to fix that mess is to reinstall you BSP. You can probably come up with a way to force these files and folders to be read only so that they might not be available to delete, but that fails if your customer uses version control to store your BSP.
A better way would be to put the binaries in a different folder and copy them to an appropriate place when they are needed. This eliminates the problem of your customers doing a clean build. As you can imagine, there are different ways to do this also. The easiest way would be to copy the binaries to the FILES folder, but the easiest way isn’t always the best as this would make for a very cluttered FILES folder. I prefer to use sources and makefile.inc to simulate the build process and copy the binaries to the Target and Lib folders when build runs.
A simple sources and makefile.inc to accomplish this build would look like this:
# The sources file
TARGETTYPE=LIBRARY
RELEASETYPE=PLATFORM
TARGETNAME=DriverShell
SOURCES=
WINCETARGETFILES=DriverShell.DLLCOPY
 
#The makefile.inc file
DriverShell.DLLCOPY:
   xcopy /I /D /Q $*.* $(_TARGETPLATROOT)\target\$(_CPUDEPPATH)
 
These files, along with the “standard” makefile, will build nothing automatically. But after not building anything, it will then process the make target “DriverShell.DLLCOPY” which will copy DriverShell.* from the current folder to the Target folder.
Now, if we get creative we might want to provide our customers with a mix of source code and binaries. My team must do that when we provide a source code BSP because we do have third party source code that we do not have the rights to re-distribute. If you want to get more creative, you will automate the process of creating the Binary BSP, but I am leaving that one as an exercise for you.
Copyright © 2008 – Bruce Eitman
All Rights Reserved