Skip to content
← Case Studies
Embedded Systems

Building a repeatable embedded workflow with Pigweed and Bazel

A representative sensor-device use case connecting portable C++ firmware, Bazel-managed builds, host-side tests and on-device diagnostics with Pigweed.

MODEL → TEST → BUILD → FLASH → DIAGNOSE
Representative engineering scenario. It illustrates the type of problem-solving approach Gnu Group can provide; it is not presented as a named-client testimonial or a claim of specific measured results.
Situation

Start with the observable problem.

An embedded team is developing an environmental sensor device. Developer workstations use different compiler versions, application logic is tightly coupled to board drivers, and manual flashing makes failures difficult to reproduce. The team needs a shared path from a reviewed source revision to tested firmware.

Environment
C++ sensor sampling, filtering and alarm state machine
Pigweed modules and Bazel build graph
Linux development host and CI runner
Raspberry Pi Pico 1 or Pico 2 evaluation board
Board drivers, serial transport and optional debug probe
Signals to investigate
Firmware builds differ between workstations and CI
A board is required to test hardware-independent logic
Flashing scripts are detached from the firmware build
Logs and diagnostics depend on ad hoc serial commands
Test evidence is not tied to the released firmware revision
Engineering approach

Turn uncertainty into a sequence of testable decisions.

01

Define sensor interfaces and isolate filtering, thresholds and alarm transitions from board-specific drivers.

02

Pin the project revision, Bazel version, dependencies and selected toolchains; verify clean builds on developer and CI hosts. Bazel alone does not make every toolchain hermetic.

03

Test threshold boundaries, invalid readings, alarm reset and sensor failures on the host using pw_unit_test with fake sensor inputs.

04

Select the board platform, build its firmware and run a local flashing target that depends on the correct artifact. Keep physical device access outside shared remote build execution.

05

Use pw_console and pw_rpc over the configured transport to inspect logs, read device state and exercise supported commands.

06

Validate real sensor timing, reset behavior and disconnect recovery on hardware; retain test logs, firmware hashes and toolchain identity for release review.

Typical deliverables
Bazel platform and dependency configuration
Portable firmware logic and board-specific adapters
Host test suite and hardware verification checklist
Firmware build, flashing and diagnostic runbook
CI acceptance gates and release evidence manifest
Intended outcomes
A consistent, reviewable build and test workflow
Earlier feedback on hardware-independent defects
Clear separation of application logic and board integration
Traceable firmware artifacts and diagnostic evidence
A foundation for additional boards after driver and timing validation
Have a similar problem?

Discuss the environment, constraints and evidence with an engineer.