hardware-io
npx machina-cli add skill beriberikix/zephyr-agent-skills/hardware-io --openclawZephyr Hardware I/O
Interface with the physical world using Zephyr's standardized driver models and hardware abstraction layers.
Core Workflows
1. Sensor Subsystem
Interact with various sensors using a uniform API for data fetching and decoding.
- Reference: sensors.md
- Key Tools:
sensor_sample_fetch,sensor_channel_get,struct sensor_value.
2. Pinctrl & GPIO
Manage pin multiplexing, electrical configuration, and basic digital input/output.
- Reference: pinctrl_gpio.md
- Key Tools:
pinctrl,gpio_dt_spec,GPIO_DT_SPEC_GET.
3. SoC Configuration
Tune chip-level parameters and manage hardware across multiple board variants.
- Reference: soc_config.md
- Key Tools:
Kconfig,soc_common.dtsi, SoC-level overlays.
Quick Start (Sensor Polling)
#include <zephyr/drivers/sensor.h>
const struct device *temp_sensor = DEVICE_DT_GET(DT_ALIAS(ambient_temp0));
struct sensor_value val;
void poll_sensor(void) {
if (sensor_sample_fetch(temp_sensor) == 0) {
sensor_channel_get(temp_sensor, SENSOR_CHAN_AMBIENT_TEMP, &val);
}
}
Professional Patterns (Hardware Engineering)
- Safe GPIO: Always use
gpio_dt_specto ensure polarity and pin number are automatically handled by the driver. - Background Sampling: Never poll sensors in high-priority threads; use a background work queue. See Work Queues in the kernel-services skill.
- Deferred Pinctrl: Define pin states in a shared
.dtsito simplify multi-revision hardware support.
Resources
- References:
sensors.md: Reading data, channels, and triggers.pinctrl_gpio.md: Pin multiplexing and GPIO specs.soc_config.md: Multi-variant SoC configuration.
Source
git clone https://github.com/beriberikix/zephyr-agent-skills/blob/main/skills/hardware-io/SKILL.mdView on GitHub Overview
Hardware-IO provides a unified way to interface with sensors, manage pin control and GPIOs, and tune SoC-level configurations in Zephyr. It covers the sensor API (fetch and decode), Pinctrl/GPIO bindings via devicetree, and multi-variant board support through overlays.
How This Skill Works
The sensor subsystem is accessed via sensor_sample_fetch and sensor_channel_get on a device obtained from the device tree. Pin control relies on pinctrl and GPIO bindings (gpio_dt_spec, GPIO_DT_SPEC_GET) to safely configure pins. SoC configuration uses Kconfig, soc_common.dtsi, and overlays to adapt hardware across boards.
When to Use It
- Adding a new sensor or peripheral and wiring its Zephyr driver
- Configuring pin multiplexing and electrical settings with Pinctrl/GPIO
- Developing sensor-based applications that poll or stream data with the sensor API
- Tuning SoC-level parameters to support multiple board variants
- Diagnosing hardware integration issues using Devicetree and overlays
Quick Start
- Step 1: Include <zephyr/drivers/sensor.h> and obtain the sensor device via DEVICE_DT_GET(DT_ALIAS(ambient_temp0))
- Step 2: Declare a struct sensor_value variable to hold readings
- Step 3: In a function, call sensor_sample_fetch(temp_sensor) and, if successful, sensor_channel_get(temp_sensor, SENSOR_CHAN_AMBIENT_TEMP, &val)
Best Practices
- Safe GPIO: use gpio_dt_spec to auto-handle polarity and pin numbers
- Sensor polling should use sensor_sample_fetch() followed by sensor_channel_get()
- Perform sampling in a background work queue rather than high-priority threads
- Define pin states in a shared .dtsi for multi-revision hardware support
- Validate device bindings with DEVICE_DT_GET and proper DT_ALIAS before use
Example Use Cases
- Reading ambient temperature from ambient_temp0 using DEVICE_DT_GET(DT_ALIAS(ambient_temp0)) and sensor_sample_fetch
- Configuring pinmux for a peripheral via pinctrl and GPIO_DT_SPEC_GET in a multi-revision board
- Overlays for multi-variant SoCs in soc_config.md to share code across boards
- Polling a sensor with SENSOR_CHAN_AMBIENT_TEMP and decoding with struct sensor_value
- Implementing a background polling task to periodically read sensors
