ブログ
ESP32のコードエラー：型変換とコンパイル
型変換エラー、パニックメッセージ、コンパイルは通るのに嘘をつくスケッチ——ESP32のエラーメッセージはそっけないですが、それぞれが特定の修正先を指しています。よくあるエラーの意味と、最初に何を直すべきかを解説します。
ESP32でbytearrayをintに変換できない？
MicroPythonなら int.from_bytes(bytes, ‘little’) が求める関数です。bytearrayはバイトの列であって、それ自体は数値ではありません。C言語で同じ形のエラーが出る場合は、uint8_t の配列をintに代入しようとしています。配列ごと代入するのではなく、値をコピーして渡すように直しましょう。「can’t convert bytearray to int esp32」で検索すると、ヒットするスレッドの半分はMicroPythonのUARTパース、もう半分はCでのstruct読み取りです。原因を切り分けるには、失敗するスケッチをシミュレーターMCPに貼り付けるのが手軽です。エラーをその場で再現してくれます。
「Guru Meditation Error」とは何？
これはパニックのヘッダ部分です。チップが例外を踏むと、リセットする前にバックトレースをシリアルに出力します。「Guru Meditation Error」の後に続く ‘core 1 panic’ のような文字とアドレスが、どこで何が起きたかを教えてくれます。バックトレースに並ぶ各行は、その瞬間に実行中だった関数たちです。読み方のコツは、下から読むこと。パニックは最後に呼ばれた関数で発火するので、いちばん下の行が犯人の居場所です。
バックトレースをデコードするには？
方法は2つ。アドレスを addr2line コマンドに渡すか、ツールに任せるかです。idf.py monitor はバックトレースを自動でデコードしてくれますし、PlatformIOも同様です。解決されると 0x400d1234: loop() at sketch.ino:42 のような行になり、関数名とソースの行番号まで正確にわかります。Arduino IDEだけは自動デコードがなく、手動でアドレスを調べる必要があります。デコード結果の見方がわかれば、クラッシュ原因の特定は5分以内の仕事です。
ESP32が再起動ループになるのはなぜ？
まず最後のシリアル出力を読みましょう。チップは死んだ理由を、毎回ちゃんと出力してくれます。再起動ループの原因は、パニック、ブラウンアウト（電圧低下）、ウォッチドッグリセットの3つに分かれ、メッセージにどれかが明記されています。ブラウンアウトなら電源の強化が答えで、ウォッチドッグならタスクにyield（処理の譲渡）を足すのが答えです。原因によって修正箇所がまったく違うので、メッセージを読まずに推測で直すのはやめましょう。3つの症状の切り分け方はデバッグFAQにまとめてあります。
「exit status 1」って何？
Arduino IDEがビルド失敗をまとめて表示するときの、汎用ラッパーです。本当のエラーは、その数行上にあります。たいてい最初の ‘error:’ の行がそれで、最初のエラーを直せば、あとに続くエラーの連鎖もたいてい一緒に消えます。「exit status 1」という表示そのものが問題なことは、一度もありません。これは要約です。もし触った覚えのないヘッダファイルを指しているなら、ライブラリの更新を疑ってください。
センサー読み取り後の整数がいつも0になるのはなぜ？
定番の原因は3つあります。1つ目、整数除算——Cでは 5/2 の結果は2になります。2つ目、ADCが落ち着く前に値を読んでいる。3つ目、シリアルで ’42n’ のように改行付きで届いた文字列を atoi() が誤読する。どの原因かを見分けるには、まず生の値を表示してみるのが一番早く、10秒で答えが出ます。ちなみに私は先月、DHT22の値が0になる問題に1時間費やしました。原因は3つ目の改行混じり文字列でした。先にデバッグ出力を足すのが、時間を無駄にしないコツです。
正しい入力なのに toInt() が0を返すのはなぜ？
toInt() は失敗しても黙っているからです。ゴミが入れば0を返すだけで、エラーも表示されません。対策は、isDigit() で文字列を検証するか、前後の空白をtrimしてから使うこと。特に末尾の改行が原因であることが多く、シリアル経由で受け取った文字列には高確率で付いてきます。C言語の atoi() も同じで、数値を信じる前に文字列の検証を。0を返されたからといって、最初から入力を疑うのが正解です。
ESP32のスタックオーバーフローとは？
ESP32はスタック破壊を検知する仕組み（カナリア）を持っていて、破壊を検出すると ‘stack canary’ という文字をトレースに出してパニックします。原因の定番は、深い再帰と大きなローカル配列です。対処は、大きなバッファをstaticやヒープに移すことと、xTaskCreate でタスクのスタックサイズを増やすこと。なぜスタックがそんなに重要かは、内部構造FAQがメモリ配置と合わせて解説しています。原因に心当たりがなくても、バッファを静的にすれば大抵治ります。
コンパイルエラーとリンカーエラーは何が違う？
コンパイルエラーは1つのファイルの中の問題です。構文、型、未宣言の名前などで、自分が書いたコードに原因があります。一方、リンカーエラーは「部品の欠落」で、’undefined reference to’ という文言は、関数がどこにも存在しないか、ライブラリがリンクされていないことを意味します。見分け方は簡単で、エラー行の最初の単語がフェーズを教えてくれます。フェーズがわかれば、どこを見ればいいかもわかります。まずはエラーの最初の行を読む癖をつけましょう。
エラーが指す行は問題なさそうに見えるのに？
コンパイラが報告するのは「問題に気づいた場所」であって、「問題が始まった場所」ではないからです。実際の原因は、指された行より数行上にある、閉じブレースやセミコロンの欠落であることがほとんどです。対応は、指された行から逆算して上のコードを確認すること。さらに、IDEの詳細出力（verbose）をオンにすれば、コンパイラがたどった全体の流れが見えるので、手掛かりが格段に増えます。エラー行を疑うより、まずは1つ上の構造を見ましょう。
この記事のテーマのプロジェクトは、sensbench の無料シミュレーターでそのまま実行できます。回路は配線済み、ファームウェア同梱、アカウントもインストールも不要です。