DEV Community

Cover image for Vibe Coding: Building a Raspberry Pi Pico I2S Audio Player Without Writing Code
AbeMarkn
AbeMarkn

Posted on Originally published at qiita.com

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

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

Hardware overview 1

Hardware overview 2

📋 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

MAX98357A amp

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

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

(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:

  1. Providing requirements
  2. Crafting and refining prompts
  3. Reviewing AI outputs
  4. 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.
PCM5102 back

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. Automated test setup
  • 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).

Top comments (0)