add I2C and SPI tools for hardware interaction#140
Merged
mengzhuo merged 2 commits intosipeed:mainfrom Feb 14, 2026
Merged
Conversation
- Implemented I2CTool for I2C bus interaction, including device scanning, reading, and writing. - Implemented SPITool for SPI bus communication, supporting device listing, data transfer, and reading. - Added platform-specific implementations for Linux and stubs for non-Linux platforms. - Updated agent loop to register new I2C and SPI tools. - Created documentation for hardware skills, including usage examples and pinmux setup instructions.
mengzhuo
reviewed
Feb 14, 2026
Collaborator
mengzhuo
left a comment
There was a problem hiding this comment.
Thanks for your contributions
emadomedher
pushed a commit
to emadomedher/picoclaw
that referenced
this pull request
Feb 17, 2026
* add I2C and SPI tools for hardware interaction - Implemented I2CTool for I2C bus interaction, including device scanning, reading, and writing. - Implemented SPITool for SPI bus communication, supporting device listing, data transfer, and reading. - Added platform-specific implementations for Linux and stubs for non-Linux platforms. - Updated agent loop to register new I2C and SPI tools. - Created documentation for hardware skills, including usage examples and pinmux setup instructions. * Remove build constraints for Linux from I2C and SPI tool files.
StarWindv
referenced
this pull request
in StarWindv/PicoClaw-shou
Feb 19, 2026
* add I2C and SPI tools for hardware interaction - Implemented I2CTool for I2C bus interaction, including device scanning, reading, and writing. - Implemented SPITool for SPI bus communication, supporting device listing, data transfer, and reading. - Added platform-specific implementations for Linux and stubs for non-Linux platforms. - Updated agent loop to register new I2C and SPI tools. - Created documentation for hardware skills, including usage examples and pinmux setup instructions. * Remove build constraints for Linux from I2C and SPI tool files.
Contributor
|
@thtskaran I2C and SPI tool support is awesome, this really opens up PicoClaw for hardware interaction use cases. Thanks for putting this together! We're growing the PicoClaw Dev Group on Discord for contributors to share ideas and collaborate. If you want in, send an email to |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds I2C and SPI tools that let the agent interact with hardware peripherals — not as a dumb pipe to
i2cget, but as an agent that understands device protocols and can turn "what'sthe temperature?" into a multi-step hardware interaction.
Why an LLM for I2C/SPI?
The agent isn't replacing CLI tools. It's replacing the human knowledge between raw bytes and useful answers:
User: "what's the temperature?"
Agent internally:
Agent: "Temperature is 23.5°C, humidity is 41.2%"
Seven steps — bus discovery, device identification by address, protocol knowledge, multi-step init/trigger/read, raw byte parsing with datasheet formulas — from one natural language
request.
The skill system makes this work. The
hardwareskill ships with reference docs covering register maps, init sequences, and parsing formulas for common devices (AHT20, BME280,SSD1306, MPU6050, DS3231, INA219, PCA9685, MCP3008, and more), plus board-specific pinmux setup for Sipeed boards.
What's included
Tools (
pkg/tools/):i2c— detect buses, scan for devices, read/write with register addressingspi— list devices, full-duplex transfer, readImplementation details:
_linux.go(real syscall/ioctl) and_other.go(stubs)i2cdetectMODE_AUTO — SMBus Quick Write for most addresses, SMBus Read Byte only for EEPROM ranges (0x30-0x37, 0x50-0x5F) to avoidcorrupting AT24RF08 chips or locking write-only devices
spi_ioc_transferstruct with verified ioctl constants,runtime.KeepAlivefor GC safety on buffer pointersconfirm: truesafety guardEBUSYdevices (claimed by kernel drivers) during scanHardware skill (
skills/hardware/):SKILL.md— quick start, safety notes, troubleshootingreferences/board-pinout.md— pinmux setup for LicheeRV Nano, MaixCAM, MaixCAM2, NanoKVM (verified against Sipeed wiki)references/common-devices.md— register maps and formulas for 10 common I2C/SPI devices (verified against datasheets)Test plan
make fmt+git diff --exit-codego vet ./...go test ./..._IOWmacro calculationspiTransferstruct layout verified field-by-field against kernelspi_ioc_transferCloses #107