Many of the Board Support Packages (BSPs) for Windows Embedded that I have seen over the years tend to have several drawbacks. Some lack the full complement of drivers, others only come with binary code. Some show little, if any signs, of ever being tested. I can understand the underlying reason for some of these issues but one that is rather irritating is the lack of a consistent coding style. You would think that at least within an individual BSP a single, consistent coding style could be followed. Most times this is not the case. Over the years different developers work on different pieces, each imposing their own coding style (instead of taking the time and effort to learn the existing style and following the existing norm). Also, as more platforms based on the same SOC come on line, we tend to just “add on” adding deeper levels of abstraction, adding more compile time and macro directives. While it can be argued this is what makes modern day programming so powerful, it also adds “code bloat”, slows down build times and, in general, makes the code hard to understand.

For example, the original TI BSP release for the BeagleBone, which is based on the AM335x processor, has its roots in earlier generation processors. The OMAP 18XX, 24xx, 35XX and 37XX processors all came before and the BSP was built up to support these chips. As they add newer generation parts the developers choose to use “bits and pieces” from existing code. Many times the older code is just left in even though it serves no useful purpose for the processor of interest. This process along with inconsistent naming conventions tends to make the code very hard to follow, especially for beginners i.e. “Can’t see the forest through the trees”.

In an effort to add a little “readability” for the beginner, as will as speed up build times, I have scrubbed much of the BeagleBone BSPs code.  I added consistent file naming and removed many unnecessary files. Still more to be done but it’s a start.