自作テキスト端末「パゴス」を起動させるまで：電源・SDカード・Wi-Fi・電子ペーパー、次々とつまずいた一日

作ってみた
2026.09.04

ハードウェア選定編では、Dell Wyse、ESP32、電子ペーパーの単体基板と何度も迷走した末、最終的に「実際に使いたい」という気持ちを優先してRaspberry Pi 3 A+に着地するまでを書きました。

今回はその続きです。実際にOSを焼き、動かし、書いた文字が本当に電子ペーパーに現れるまでの一日を記録します。結論から言うと、たどり着きました。ただし、想像していたよりずっと遠回りをして。

構成は、Raspberry Pi 3 Model A+とWaveshare 3.7inch e-Paper HAT+ (G)。作業時間は約9時間でした。

電源、また電源

最初のつまずきは、拍子抜けするほど地味なものでした。MacのUSBポートから給電したら、赤LEDが灯るだけで、緑が一度も点滅しません。Raspberry Pi 3系は5V/2.5A前後を要求するのに対し、MacのUSBポートはせいぜい1A弱しか出せません。パソコンの充電用ポートと、基板を動かす電源は、まったくの別物だったわけです。

モバイルバッテリーに繋ぎ替えても、今度は出力が0.4Wしか出ていません。多くのモバイルバッテリーは「スマホの充電プロトコル」を検出できないと出力を絞る仕様になっています。Raspberry Piはそういう律儀な握手をしないので、バッテリー側に「何も繋がっていない」と誤解されていたようです。

SDカードが疑惑の対象になる

電源をどうにか安定させ、書き込みも終え、いざ起動——と思ったら、今度はapt installの途中で派手に壊れました。

EXT4-fs error (device mmcblk0p2): htree_dirblock_to_tree:1051:
  inode #1027: comm systemd: Directory block failed checksum
EXT4-fs error (device mmcblk0p2): ext4_lookup:1787:
  inode #412: comm sudo: iget: checksum invalid

最初は「電源が不安定だからだ」と決めつけて焼き直しました。ですが、二度目も同じように壊れます。vcgencmd get_throttledで調べると0x0で、電圧不足は一度も起きていませんでした。容疑者は電源ではなかったわけです。

決め手になったのは、dmesgの一行でした。

[    2.292170] mmc0: Problem switching card into high-speed mode!

これはファイルシステムより一段下、カード自体の応答異常を示すログです。安価な無名ブランドの32GBカードは、実容量を偽装した粗悪品であることが実際にあります。信頼できるブランド(GREEN HOUSE)のカードに差し替えたところ、書き込みエラーは一度も再発しなくなりました。

安さを追うたびに、別の技術的コストを払う羽目になる。このプロジェクトを通じて何度も思い知らされてきたことを、SDカード一枚でまた確認することになりました。

Wi-Fiが綴りひとつで拒む

起動はします。SSHも待ち受けています。ですがpingはいつまでも同じ言葉を返してきます。

ping: cannot resolve pagos-writer.local: Unknown host

HDMIを繋いでようやく分かりました。画面にはMy IP address is 127.0.1.1と表示されています。これはループバック、つまり実際のネットワークに一度も繋がっていない値です。原因は、Wi-FiのSSIDを手打ちしていたことでした。日本語IMEがオンの状態で英数字を打つと、気づかないうちに文字が化けることがあります。ターミナルでnetworksetup -getairportnetworkを使い、正確な文字列をコピーしてから焼き直すと、今度こそ実際のIPアドレスが画面に浮かびました。

電子ペーパーが沈黙し続ける

SPIを有効化し、Waveshare公式のサンプルを流し込みます。ところが画面は白いまま、ターミナルには同じ一行が居座り続けました。

INFO:root:init and Clear
DEBUG:waveshare_epd.epd3in7:e-Paper busy

GitHubのissueを漁ると、この症状自体は昔から報告のある「busyのまま固まる」現象でした。ですが、本当の原因は別のところにありました。手元の製品名は「3.7inch e-Paper HAT+ (G)」。通常の白黒4階調モデルとは資料も型番も似ているだけの、416×240・黒白赤黄4色の別製品だったのです。使うべきドライバは、メインのサンプルフォルダにはなく、リポジトリの奥深くE-paper_Separate_Program/3in7_e-Paper_G/という専用フォルダの中に、末尾にgが付いたepd_3in7g_test.pyとして隠れていました。

正しいドライバに差し替えた瞬間、何時間も無反応だった画面に、初めて図形と文字が浮かびました。

本命のエディタが動き出し、また止まる

ハードウェアが揃ったところで、本命のPython+cursesエディタzen_editor.pyを書きました。複数行編集、アンドゥ、検索、タイプライタースクロール、そしてEnterのたびに裏で電子ペーパーへ反映するバックグラウンドスレッド。書いては送り、また書いては送る。それらしい動きを見せました。

ですが実機のキーボードで試すと、Ctrl+Sを押した途端に画面が固まります。フロー制御の設定順序を直し、電子ペーパーの初期化をバックグラウンド化しても、まだ直りません。半日近く付き合って、ようやく気づいたのはもっと単純な話でした。

if [ -z "$SSH_CONNECTION" ] && [ "$(tty)" = "/dev/tty1" ]; then
    cd ~/e-Paper/.../examples
    python3 epaper_test.py  # ← 何時間も前に作った試作品のまま
fi

本体で自動起動していたのは、Ctrl+Sという概念すら持たない、一番最初の試作スクリプトでした。SSH越しに手動で立ち上げたときだけ本物のzen_editor.pyが動いていたので、「SSHでは動くのに実機だけ動かない」という、完全に見当違いの謎に長々と付き合わされていたわけです。

最初の一行を送り出す

自動起動先を書き換え、電源を入れ直します。今度こそ、実機に挿したキーボードだけで文字を打ち、Ctrl+Sで保存し、Ctrl+Gを押します。

[main 83ef701] write: 2026-08-22 20:08:12
 1 file changed, 1 insertion(+)
 create mode 100644 00_inbox/20260822200809.md
To github.com:plzsayyes3/mynotebook.git
   0baa997..83ef701  main -> main

Git送信成功: 8件をpushしました

Macを一切介さず、モバイルバッテリーとキーボードと電子ペーパーだけの箱から、GitHubへ文字が届いた瞬間でした。Mac側でgit pullすると、確かにそこにありました。

—

今日直した不具合の九割は、結局「思っていたのと違うものが動いていた」という一言に集約されます。壊れたSDカード、化けたSSID、型番違いのドライバ、書き換え忘れた自動起動スクリプト。どれも壊れていたのは仕組みではなく、こちらの前提の方でした。

日本語入力(SKK方式)はまだ手つかずのまま残っています。ですが今日、パゴスは初めて自分の声でGitHubに向かって何かを言いました。それで十分だと思っています。

日本語入力については、この後さらに実験を重ねることになります。その経緯はmozcローカル変換編に書きました。

コメント

タイトルとURLをコピーしました