OpenClaw vs. a 475-page datasheet: let the robot do the transcribing 🦞🤖
-
OpenClaw vs. a 475-page datasheet: let the robot do the transcribing 🦞
-
OpenClaw vs. a 475-page datasheet: let the robot do the transcribing 🦞
The u-blox SAM-M8Q has been sitting on my bench for months. This little GPS module has a built-in antenna, coin cell backup, speaks both NMEA and UBX binary protocol over UART or I2C.
-
The u-blox SAM-M8Q has been sitting on my bench for months. This little GPS module has a built-in antenna, coin cell backup, speaks both NMEA and UBX binary protocol over UART or I2C.
So why isn't it in the shop already? Well, it's mostly cause of the 475-page interfacing datasheet documenting every command, struct, and config register. Hundreds of message types. I got partway through by hand with some Claude Code Sonnet assistance, but ran out of time - plus it was still tedious when babysitting Sonnet.
-
I review the plan to make sure it prioritizes the most common commands and reports, and flagged some unessential sections like automotive-assist or RTK-specific. Then Codex is assigned each message implementation task as a sub-agent and writes the actual C code for the Arduino library.
-
I review the plan to make sure it prioritizes the most common commands and reports, and flagged some unessential sections like automotive-assist or RTK-specific. Then Codex is assigned each message implementation task as a sub-agent and writes the actual C code for the Arduino library.
Opus suggested using struct-based parsing rather than digging through each uint8_t array; we just memcpy the checksummed message raw bytes onto the matching struct and extract the typed bit fields.
-
Opus suggested using struct-based parsing rather than digging through each uint8_t array; we just memcpy the checksummed message raw bytes onto the matching struct and extract the typed bit fields.
We've got four message types done so far. After each message is implemented, Codex also writes a test sketch that will exercise / pretty-print the results of each message, great for self-testing as well as regression testing later. Tonight I'm telling it to keep going while I sleep: code, parse, test against live satellite data, fix failures, commit and push on success, then move on to the next.
-
We've got four message types done so far. After each message is implemented, Codex also writes a test sketch that will exercise / pretty-print the results of each message, great for self-testing as well as regression testing later. Tonight I'm telling it to keep going while I sleep: code, parse, test against live satellite data, fix failures, commit and push on success, then move on to the next.
To me this is a great usage of "agentic" firmware development: there's no creativity in transcribing 84 different structs from a 475-page datasheet. Once the LLMs are done, I can review the PRs as if it were an everyday contributor and even make revision suggestions.
-
@adafruit that repo doesn’t seem to exist?
-
So why isn't it in the shop already? Well, it's mostly cause of the 475-page interfacing datasheet documenting every command, struct, and config register. Hundreds of message types. I got partway through by hand with some Claude Code Sonnet assistance, but ran out of time - plus it was still tedious when babysitting Sonnet.
However, now we're living in an Opus + Codex era! So I pointed my Raspberry Pi OpenClaw at it.
Here's the setup: Raspberry Pi 5 running OpenClaw, wired to a QT Py RP2040, which talks to the SAM-M8Q. Opus 4.6 reads the datasheet (converted to markdown first by Sonnet 4.6 with 1M context to minimize re-parsing that PDF every session) and builds the implementation plan.
-
To me this is a great usage of "agentic" firmware development: there's no creativity in transcribing 84 different structs from a 475-page datasheet. Once the LLMs are done, I can review the PRs as if it were an everyday contributor and even make revision suggestions.
-
R relay@relay.an.exchange shared this topic
