How to use Codex to test ESP32 UART firmware
Codex compiled, flashed and tested ESP32 firmware through a UART REPL. Mock sensor inputs limited the demo; the owner checked electrical signals with a scope.
linkedin.com
Suggested prompt
Suggested prompt written by Agents In Use, not the source author. Replace bracketed inputs and review tool permissions first.
Build and flash this ESP32 UART-REPL firmware, exercise its logic with explicitly labelled sensor mocks and capture serial self-test results. Give me expected PWM signals to check on an oscilloscope. Keep physical-sensor behavior unverified until real sensors are connected.
Reach people exploring AI agents
See placements →Evidence at a glance
Sourced account- Source author
- Bryan Lopez
- Original account
- Read the source ↗
- Published
- Source link checked
- Reported result
- Firmware was compiled, flashed and self-tested on an ESP32, with output signals checked by the human using an oscilloscope. Sensor inputs were compile-time mocks.
- Human involvement
- Lopez supplied the board and project behavior, watched the run and used an oscilloscope to confirm electrical signals.
A linked account supports attribution. It does not mean we independently reproduced its result.
Report an issue with this case
Open correction emailOpens your email app with the case link included. Nothing is sent automatically.
How the agent did it
- Lopez supplied an ESP32 board, a UART REPL and a description of the desired behavior.
- Codex compiled, flashed and exercised firmware self-tests through the serial interface.
- Lopez confirmed electrical signals with an oscilloscope while noting that sensor inputs were mocked.
Bryan Lopez gave Codex an ESP32 development board and a UART interface while developing firmware for end-of-line sensor behavior. Instead of accepting generated code as the result, he let the agent build, flash and inspect the board through a serial REPL.
Lopez described the desired behavior in ordinary language. Codex used project skills to compile the firmware, upload it and run self-tests through the serial connection. That loop let execution results influence the next change rather than making the human relay every console response manually.
The sensor inputs were compile-time mocks because the physical sensors were not connected. This is an important boundary of the demonstration: the agent exercised firmware logic and PWM behavior, but did not validate a complete installed sensor system. Lopez separately checked the generated signals with an oscilloscope and watched the process.
The reported outcome is firmware that could be built, flashed and checked against serial feedback on real hardware, with electrical output confirmed by the human. The account supplies a specific embedded-development pattern, but does not establish long-term sensor accuracy or unattended field operation. Its strongest evidence comes from combining the agent's repeatable serial checks with a separate physical measurement.
Prompt
Suggested prompt (written by Agents In Use, not the author's)
Source: LinkedIn · Bryan Lopez
Frequently asked questions
Were real sensors connected?
No. The demonstrated end-of-line sensor inputs were compile-time mocks.
How did Codex inspect execution?
It used the board's UART serial REPL after building and flashing firmware.
What did the human measure?
Lopez used an oscilloscope to confirm the generated electrical signals.
More details
About this account
Lopez supplied an ESP32 board, a UART REPL and a description of the desired behavior. Codex compiled, flashed and exercised firmware self-tests through the serial interface.
Opened firsthand post and primary HTML metadata. End-of-line sensors were compile-time mocks rather than connected sensors; actual signal checks used an oscilloscope. Suggested prompt written by Agents In Use; no original task prompt was published in the verified account.
Credit: Bryan Lopez — LinkedIn
Source published
Added to Agents In Use
Source checked
Tools and topics
Codex · ESP32 · UART · Oscilloscope
Firmware tests · Serial feedback
Editorial completeness: 100/100. Measures documented fields, not agent performance or verified outcomes.