DEV Community: AbeMarkn

Automated Hardware Testing on Raspberry Pi Pico - Testing ePaper with a Test Jig, Camera, and Gemini API

AbeMarkn — Sun, 23 Aug 2026 08:41:02 +0000

Introduction

AI has made software development much easier. But for embedded software, testing is still tough.

Embedded devices require pressing physical buttons and visually checking the screen. Because hardware is involved, manual testing is usually required.

I wanted to change that, so I built an automated testing setup!

Now, everything from pressing the buttons to verifying the ePaper display with AI is fully automated.

What I Built

I am building a battery-powered "Time Recorder" (punch clock) using a Raspberry Pi Pico and an ePaper display.

When a button is pressed, the device records the time and displays it on the screen.

In this project, I automated the entire test cycle:

Triggering the physical button press via hardware.
Waiting for the ePaper to update.
Capturing the screen with a camera.
Using the Gemini API to verify the displayed content automatically.

How It Works

Normally, pressing Button A (Fig 1: ★1) displays the recorded timestamp on the ePaper (Fig 1: ★2).

To automate this test, the system runs through these steps:

Custom Test Jig: Built a testing jig (Pico_Tester) to control the button lines (Fig 1: ★4).
Automated Button Press: The test jig triggers the button electronically (a green LED turns on so humans can see it was pressed).
Camera Capture & AI Verification: A Raspberry Pi 5 camera captures the ePaper screen (Fig 1: ★5), and the Gemini API inspects the image.
Automated Report: The AI evaluation and test result are reported automatically (Fig 2: ★3).

Fig 1: Overall System Setup

Fig 2: Test Result Report (Google Antigravity)

Fig 3: Circuit Diagram

Gemini API & Google Antigravity

Here is how AI is used in this test pipeline:

Prompt: Sends structured text instructions with the Base64 image, asking to extract text/status and compare it with the expected output.
Accuracy: Recognized custom 7-segment bitmap fonts, timestamps, and punch records (0002-0003, etc.) with 100% accuracy.
Implementation: Uses Python's standard urllib to call the gemini-3.6-flash REST API directly. No external SDKs required.
Integration: The AI output is parsed and saved into the test result JSON (snapshot info + AI verdict) as test evidence.
Development Speed: Pair-programmed with Google Antigravity to quickly design and deploy API endpoints, concurrency locking, timeouts, and live hardware tests.

Prompt Example (Generated by AIJudge)

This image is a photograph of an ePaper display.
Please read the content displayed on the screen and report in the following format:

1. [Extracted Text]: Transcribe all text, numbers, and symbols shown on the screen.
2. [Date/Time]: State any date and time displayed.
3. [Status]: State the status shown at the bottom (SLEEP/KEEP, READY/START, etc.).
4. [Verdict]: Compare with the expected criteria below and judge if it matches:
   Expected: The ePaper displays the date (MM/DD), punch record (HHMM-HHMM), current time at the bottom, and button guide.

   Answer with "OK" or "NG" and provide a concise reason.

Actual Output from Gemini API

1. [Extracted Text]
  - Date Header: 08/22
  - Left Column (Punch History):
      - 0002-0003
      - 0944-0945
      - 2322-2323
      - 2359-2343
      - 1102-1104
  - Bottom Area:
      - Guide: A=START B=FINISH C=KEEP
      - Clock: 08/22 23:04
      - Status: SLEEP READY

2. [Date/Time]
  - Top Header: 08/22
  - Bottom Clock: 08/22 23:04

3. [Status]
  - "SLEEP READY" is displayed on the bottom right.

4. [Verdict]
  - Result: OK
  - Reason: The date (08/22) at the top, punch records (0002-0003, etc.) on the left, current time (08/22 23:04), and button guide (A=START B=FINISH C=KEEP) at the bottom are all clearly displayed and completely match the expected criteria.

Key Benefits

Now I can define test cases on my PC, and the system runs them completely automatically.

Whenever I add a feature or fix a bug, I just tell the tool: "Run Test_0001", and it tests the hardware and generates a report.

No more pressing physical buttons dozens of times manually! No matter how many bugs I create, the automated setup tests tirelessly without complaining. 🎉

Next Steps

Refine and expand the AI evaluation prompts for different test cases.
Build the remaining firmware features for the Time Recorder now that the test loop is ready.
Use the test jig's INA228 power monitoring module and EEPROM to evaluate sleep current and battery life.

Vibe Coding: Building a Raspberry Pi Pico I2S Audio Player Without Writing Code

AbeMarkn — Mon, 17 Aug 2026 05:27:58 +0000

Introduction

As a holiday project in 2026, I decided to experiment with "Vibe Coding"—letting AI lead the entire software development process.

Without writing a single line of code myself, I delegated everything (requirements definition, architecture design, and coding) to AI agents (Gemini, Copilot, ChatGPT / Antigravity, Cursor). In the end, I successfully played audio using an I2S DAC connected to a Pimoroni Tiny2040 (8MB Flash; standard Pico has 2MB)!

The Hardware Setup

📋 Bill of Materials (BOM)

Component	Model / Spec	Role & Notes
MCU Board	Pimoroni Tiny2040 (RP2040)	8MB Flash (Standard Pico has 2MB)
I2S DAC Amp	MAX98357A	3W Class D Mono Amplifier (Easy wiring)
I2S DAC (Alt)	PCM5102 Module	Note: Silk-screen inverted on some batches
Speaker	8Ω 1W Dynamic Speaker	Audio output
RTC Module	DS3231	I2C Real-Time Clock for time announcements
Power Source	LIR2032 (3.7V / 45mAh)	Rechargeable coin cell for bench testing
Controls	Mini Breadboard & 2 Switches	Playback / Volume trigger buttons

For bench testing, I powered the setup using an LIR2032 rechargeable coin battery (3.7V / 45mAh). It booted cleanly and played sound without issues!

🎬 Demo Video & Repository

AbeMarkn / I2S_MAX98357A_PCM5102

I2S 音声フォーマット比較プレイヤー (Pimoroni Tiny2040 + MAX98357A + DS3231 RTC)

【前半】利用者向けマニュアル (User Manual)

1. プロジェクト概要

本システムは、Raspberry Pi Pico互換の Pimoroni Tiny2040 (Flash 8MB) と MAX98357A (I2S D級アンプ)、および 高精度外付けRTC (DS3231) を使用した音声プレイヤーです。

ボタン操作により、3つの音声フォーマット（高品位 44.1kHz/16bit PCM、標準 16.0kHz/16bit PCM、高圧縮 16.0kHz/4bit IMA-ADPCM）を切り替えてスピーカから直接試聴・比較できます。
外付けRTC（バックアップ電池付）により、電源を切っても正確な時刻（JST）を保持し、起動時に自動同期します。

2. 必要環境・ハードウェア

マイコン: Pimoroni Tiny2040 (RP2040 / Flash 8MB)
DAC / アンプ: MAX98357A I2S D級アンプモジュール
外付けRTC: DS3231モジュール（CR2032電池付）
スピーカ: 3W モノラルスピーカ (4Ω〜8Ω)
スイッチ: タクトスイッチ × 2個 (ボタンA: 青, ボタンB: 白)
電源: USB 5V 給電 (Type-C)

3. 配線一覧 (Pimoroni Tiny2040)

3.1 オーディオアンプ & ボタン接続

GP0 (0): MAX98357A BCLK
GP1 (1): MAX98357A LRC
GP2 (2): MAX98357A DIN
3V: MAX98357A VIN
GND: 各モジュール GND
GP6 (6): ボタンA (青)
GP7 (7): ボタンB (白)

3.2 外付けRTC (DS3231) 接続（左側 Pin 5〜8 ストレート配線）

Pin 5 (GP28 / A2): DS3231 VCC（GPIO 3.3V 給電）
Pin 6 (GP27 / A1): DS3231 SCL…

View on GitHub

(Note: Even the README in this repository was 100% generated by AI!)

How Was the Vibe Coding Experience?

My golden rule for this project was: "Humans do not edit the source code."
My only responsibilities were:

Providing requirements
Crafting and refining prompts
Reviewing AI outputs
Verifying operations on physical hardware

I iterated on the prompts by asking Gemini, Copilot, and ChatGPT to review and critique each draft. Once the prompt was refined, I had GitHub Copilot in VS Code summarize the specifications and design. Once I felt the design was solid, I asked it to implement the code.

The Roadblock: Out-of-Memory Infinite Loop

Then came the first major issue.

The original voice samples were in MP3 format, which had to be converted to WAV and stored in the Tiny2040's on-board 8MB flash memory. However, Copilot attempted to write more than 8MB worth of WAV files at once, causing repeated out-of-memory errors.

Instead of identifying that unused audio files could be dropped, Copilot fell into a repetitive loop—trying things like "writing smaller files first" or "changing the file transfer order." It was completely stuck in an infinite loop.

While I paused Copilot and asked it to analyze the converted file sizes in a table, I hit the GitHub Copilot Pro+ monthly limit (7,000 AI credits, $39/mo)!

Breakthrough by Switching to Antigravity

Upgrading to a higher Copilot tier was costly, and it was still going in circles. So I switched development agents to Google Antigravity (Google AI Pro 5TB plan / 2,900 JPY/mo).

With Antigravity, I resumed work and had it analyze the storage footprint. It quickly determined that skipping unused MP3 conversions would keep the total size well within the 8MB limit. It updated the code, and everything started working as intended!
You can view the AI-generated report here.

The entire GitHub repository documentation, including the README, was generated by AI. It was structured surprisingly well. Writing all of this by hand from scratch would have taken days and likely introduced bugs. While there are minor spots where human polishing could help, I kept them as-is to preserve the "100% AI-driven" spirit of this experiment.

Hardware & Sound Quality Evaluation 🎶

I used to think driving a speaker with digital audio had a high barrier to entry. But after discovering I2S, I realized it is quite accessible on microcontrollers like the RP2040.

Audio Quality: For voice announcements, 16kHz / 4-bit IMA ADPCM provides clear and practical quality.
Storage Efficiency: IMA ADPCM drastically reduces file sizes. This allows plenty of voice clips to fit inside the Pico's built-in flash without requiring external SD cards or SPI Flash chips.

The Gotcha: Inverted Silkscreen on the PCM5102 Board

While getting sound took only a few hours, I ran into one hardware trap.

I bought two types of I2S modules. One of them, a PCM5102 board, had defective PCB silkscreen printing.

The labels for the configuration jumpers (H1L, H2L, H3L, H4L) on the back were printed upside down (rotated 180 degrees)! I was suspicious at first, but checking online reviews confirmed other users had run into the exact same issue.
Details and wiring workarounds are documented in CONNECTIONS_e.md.

In contrast, the MAX98357A (built-in amplifier) was extremely easy to wire and worked right away. Although mono, it is highly recommended.

AI Quirks & Realities

During development, I added minor features such as adjustable playback speed and volume.

During hardware testing, the playback speed was not changing. When I pointed this out to the AI, it replied confidently: "All unit tests have passed."
I responded: "Can you set the playback speed to 2x yourself and measure the playback duration?"
The AI admitted: "Ah, there was a bug." AI can definitely produce subtle bugs despite green tests!

Another funny incident: I manually adjusted the playback speed to 1.3x in a configuration file. Later, during an unrelated refactoring, the AI quietly reverted it back to 1.0x.
I caught it during code review, but it was a good reminder: it is wise to add an instruction like "Never modify user values in config files without explicit confirmation."

Next Steps

Prompting Best Practices: Compiling guidelines and patterns for prompt-driven embedded development.
AI Interaction Strategy: Answering every detailed clarification request from AI quickly leads to human fatigue. When human review gets lazy, AI changes can diverge rapidly, consuming large amounts of AI credits. Striking the right balance of autonomy is key.
Automated Physical Testing: I am currently setting up automated button actuators with AI computer vision for hardware pass/fail verification.
Audio Streaming over Wi-Fi: Now that 16kHz / 4-bit audio is verified, the next step is experimenting with audio streaming over Wi-Fi using the Raspberry Pi Pico W (2MB Flash).