Firmware

Firmware written against the board we designed, so a driver bug is traced to the wire, not a datasheet guess.

Bare-metal and RTOS firmware developed alongside the hardware, so bring-up and driver work start the day boards arrive.

Firmware architectureHow the image is laid out. The driver layer is where "the board works" and "the software works" stop being separate claims.Application taskscontrol · protocol · diagnosticsBootloaderverify · rollbackRTOSpriorities, stack and latency budgetsField updatesigned image · A/BDrivers · HALwritten against the boardSilicon · peripheralsADC · timers · CAN · UART · DMA

Scope

What we do

  • Board support and device drivers on STM32 and other Cortex-M and Cortex-A parts.
  • RTOS integration on FreeRTOS and Zephyr, with interrupt-latency and stack budgets.
  • Bootloaders and field-update paths with image verification and rollback.
  • Communication stacks — Modbus, CAN/CAN FD, industrial serial — timed against the bus, not the datasheet.
  • Low-power design: sleep states, wake sources, measured current budgets.
  • MISRA-aligned coding and static analysis where the target class requires it.

Typical stack

  • stm32
  • real-time
  • determinism
  • can-fd
  • rs-485
  • modbus
  • secure-boot
  • ota-updates
  • bring-up

Standards worked to

Applicable standards are agreed at the start of a programme and written into the scope. Certificates we hold are shared on request.

Deeper reading: Hardware & PCB Design

Talk to an engineer

Ask about this capability directly — the person who answers has shipped it.

Talk to an engineer