The BHI360 is different from a plain accelerometer or gyroscope because it is a sensor hub with its own processor, FIFO, boot flow, and virtual-sensor model. In practice, that means your wearable host firmware is not only reading raw motion data. It is also responsible for booting the BHI360, loading a firmware image, enabling the virtual sensors exposed by that image, and parsing the resulting FIFO events.
That architecture is exactly what makes the device powerful for wearables. It lets you move classification, fusion, and event detection closer to the sensor while keeping the Zephyr host focused on transport, power management, and application logic.
This article explains two things from the actual code in this workspace:
- How to take a custom BHI360 firmware image from Bosch’s firmware SDK workflow and package it for host-side use.
- How the Sens Wear platform’s integrated BHI360 is connected into the Zephyr firmware so that custom firmware can be uploaded, booted, and consumed by the application layer.
What "custom firmware" means for BHI360
On BHI360, custom behavior does not start in the Zephyr application. It starts in a firmware image that runs inside the BHI360 itself. That image defines which virtual sensors exist, what IDs they use, what payload format they emit, and whether the host sees standard motion outputs, custom outputs, or both.
The workspace already shows that model clearly:
examples/load_firmware/load_firmware.c
: in the Bosch BHI360 SensorAPI demonstrates the host-side boot and upload sequence.examples/virtual_sensor_toy_sine/virtual_sensor_toy_sine.c
: demonstrates a custom firmware image that exposes a customer-visible sensor on ID0xA5
.examples/fw2h/fw2h.c
: converts a compiled binary firmware blob into a C header that can be compiled into host firmware.
.fwimage, and the host repo packages and boots it. That is the right mental model for BHI360 development:
- The sensor-side image defines capability.
- The host-side code discovers and consumes that capability.
The Bosch-side workflow
The Bosch examples reveal a practical development loop:
- Create or modify the BHI360 firmware image in Bosch’s firmware SDK flow.
- Export a compiled
.fw
blob. - Convert that blob into a header if the host firmware wants to embed it.
- Boot the BHI360 with that image and confirm the expected virtual sensor IDs are present.
virtual_sensor_toy_sine.cis written to look for
Bosch_Shuttle3_BHI360_ToySine.fw.h, then boot the sensor and subscribe to a custom sensor at
0xA5. In other words, the host application assumes the custom algorithm already exists in the firmware image and is now exposing a new FIFO event stream.
Converting a .fw blob into a host-embeddable header
The helper under
examples/fw2h/fw2h.c
exists for one simple reason: embedded host projects usually want to compile the sensor firmware blob directly into the application image.
Its output format is a C array, so the BHI360 firmware becomes just another static byte array in the build:
No comment