Board Support Package Development by Focus Embedded
 

Key Points

  • Applications developers don't interact with your hardware. They interact with your software API's.
  • A good BSP for so-so hardware will get more market traction than a poor BSP for stellar hardware.
  • With an unstable BSP, you'll spend untold time, money, and misery chasing problems at the applications level.
  • If your customer is the applications developer, he'll remember your bad BSP for years if you write him one.

Board Support Package Development

Board support package (BSP) development is where the rubber meets the road and the silicon meets the code.  Build a BSP correctly, and a wide open highway for applications development is yours to command.  Botch one, and you’re headed for a traffic jam.
 
Essentially good board support package design depends on being able to do good device driver design while also being mindful of the eventual requirements of an operating system (which may bind parts of the BSP as OS kernel calls). Similarly a BSP designer must remain cognizant of the kinds of applications that might eventually make calls into the firmware drivers that are part of the board support package. Obviously the quality (and utility) of a BSP can hinge on the degree to which low-level bit-manipulation functions are abstracted away from any API above them – so no application developer need concern himself with how something like a mapping application for an iPhone gets GPS coordinates or an embedded Linux board talks to a motor controller or position sensor.
 
Without well done low-level firmware development, any of the following can happen:

  • A new peripheral device fails to work properly.
  • What should be a benign change to an operating system causes it to stop working.
  • Application code debug and kernel aware debug are bothrendered difficult to impossible.
  • Application code can be forced to peek and poke down through a hardware abstraction layer (HAL) – inviting problems with task scheduling, resource management, memory allocation and cleanup.
  • All of the above.

At Focus Embedded we’ve done BSP’s for a wide variety of target boards, including (but not limited to) those with the following processors:

  • ARM and ARM-Cortex variants
  • SHARC, Blackfin, ADSP-2100 and ADSP21000 DSP’s
  • TMS320 DSP variants
  • 8051 Microcontroller
  • x86, including embedded variants
  • PowerPC
  • Motorola/Freescale Coldfire
  • Freescale Kinetis
  • Freescale QorIQ
  • TI OMAP (particularly the OMAP3530 and Beagle Board variants)
  • Microchip PIC and dsPIC
  • TMS320
  • Cypress M8 core / FX and FX2 USB endpoint controllers
  • Cypress PSoC
  • Intel 80C196
  • TI MSP430

At Focus Embedded, we’re equally home writing in C or assembly language, the two most popular languages when you have to resort to serious low-level bit manipulation.  (Although some assembly languages, such as that for the TMS320, aren’t exactly the friendliest things, and it takes some skill to write with them given how many things a single instruction may execute in parallel.)  And we’ve seen the quirks of a few processors that carry “legacy” features (such as odd “paging” schemes or “segmented addressing” and “real and protected modes”) with them.  Along the way, we’ve done quite a bit of power management device driver support for mobile devices.
 
We’ve also, as FPGA designers, done cross-development with FPGA’s as memory-mapped peripherals connected to host processors – and defined FPGA registers in “include” files such that they were that much easier to keep in sync with similar header files on the software driver side.  We think like hardware designers a lot of the time (because we also do hardware design when we’re not coding), so we can switch gears like that.  And the result, even when we’re not the ones doing the hardware design ourselves, is usually a much better BSP in the end.  If nothing else, we comprehend somebody else’s hardware design more quickly and get to a solution sooner than just about anybody else out there.  (Often it’s our knowledge of FPGA’s that enables us to make suggestions about what’d logically go on either side of the FPGA-driver interface, and this results not only in a better BSP but ultimately in better HDL source code on the hardware side.)
 
And we’re always up for joint development with your hardware team.
 
By all means poke around our project portfolio and sound us out on how we can be of help moving your hardware and application code development effort down the road in the fast lane.