Board bring-up support
Bring clocks, memory and essential peripherals into operation on first hardware, working with electronics engineers on observed behaviour.
Focus topic
BSP & Device Driver Development
Make new hardware usable for software teams: initialised, abstracted and covered by drivers that behave as the board design intends.
Board support and driver work sits directly on the hardware. The scope can be a single peripheral driver, a hardware abstraction layer, or the board support package that lets an RTOS-based or bare-metal system run on a new board.
Where board support sits
Board support and drivers separate product software from the details of one board. Highlighted layers are the typical scope.
- Application and middlewareProduct behaviour
- RTOS or bare-metal schedulerTasks, timing, interrupts
- Hardware abstraction layerStable interface to hardware
- Board support and device driversClocks, memory, peripherals
- Board and microcontrollerSchematic, pin allocation
What the work covers
The agreed assignment determines which activities are included and where the responsibility boundary sits.
Peripheral and device drivers
Develop low-level drivers in embedded C or C++, with Assembly where required, for the interfaces and devices on the board.
Hardware abstraction
Provide a stable interface between hardware-specific code and the software above it, so board changes stay contained.
RTOS and bare-metal integration
Integrate drivers and board support with the selected RTOS or a bare-metal structure, including interrupt and timing behaviour.
Driver verification
Test drivers on target hardware and document configuration, limitations and the hardware revision they apply to.
Typical starting points
First prototypes have arrived and no software runs on them yet.
A component change or second-source part needs a new or modified driver.
Application code depends directly on hardware details and breaks with every board revision.
Example engineering outputs
Outputs are assignment-dependent and agreed for each engagement.
Board support software for the agreed hardware revision.
Device drivers and hardware abstraction interfaces.
Bring-up notes and records of hardware findings.
Driver test results on target hardware.
Common questions
Do you need the hardware on site?
Driver and bring-up work needs access to target hardware and measurement equipment. Whether boards are provided to the team or the work takes place in the customer laboratory is agreed for the assignment.
Which microcontrollers and operating systems do you work with?
The platform is set by the product. Work covers bare-metal and RTOS-based systems; fit for a specific microcontroller family and operating system is confirmed during technical scoping.
Can hardware and driver development be combined?
Yes. Where electronics and platform software are both in scope, they can be developed together so pin allocation, interfaces and bring-up findings are resolved in one team.
Part of
Embedded Software & Platform Engineering
Low-level software, platform configuration, drivers and embedded architecture, from hardware interfaces to integrated software baselines.
Discuss a board bring-up, driver or hardware abstraction scope.
Describe the current state, the interfaces involved and the result you need. Leave confidential technical files out of the first message.