マイコン開発でハマったことを書いておく。2度同じミスをしないため。
マイコンが一つ増えると考えるべき状況が格段に増して難易度が高くなる
SoC+マイコン1個 からSoC+マイコン2個に増えたときの難易度の増加を甘くみてはいけない。
相手の電源が入っていない時やハングアップしたときのリカバリ、共有すべき情報の同期のことを考えよう。
マイコンの個数は少ないほうがよい。もちろん増やさざるをえない場合もある。その場合は油断しないで覚悟しよう。
ピン数が足りないためにデバッグ用のポートをつぶしてしまうと開発がつらい
フルカラーLEDを3つつけるとそれだけでGPIOポートが9つ必要になる。
部品コスト削減のためにピン数の少ないマイコンを使用し、デバッグ用のポートもGPIOに流用せざるをえないこともある。
マイコンのソフトはそれほど複雑なことはやっていないとはいえ、デバッガがつながらないと想定通りに動かない場合につらい。
低消費電力のマイコンだと外部ピンからのリセットとパワーオンリセットで動作が違うかも
私が使用したマイコンではRTC(リアルタイムクロック)の設定はパワーオンリセットのときだけリセットされ、外部ピンからのリセットでは設定がそのまま残る。
そして、超低消費電力の待機モードではシステムクロックとしてRTCを使用する。
その待機モードがうまくいくときといかないときがあるというバグで何日もハマった。
一度サンプルプログラムを動かしてから外部ピンでリセットかけて自分のプログラムを動かすと正常動作するが、翌朝電源を入れて動かすとダメという症状。
外部ピンのリセットとパワーオンリセットの違いを理解していなかった。
超低消費電力待機モードから復帰したところで暴走する
使用していないピンのpin muxを全てdisable にしたら暴走しなくなった。
超低消費電力モードではピンからのノイズに敏感ということがわかった。
待機中の電力消費がスペックの10倍も大きい
つまり、バッテリーが想定した時間の1/10しか持たない。
デバッグに使えるかもと思ってpin muxを有効のままにしていたUARTのピンから電流が漏れていた。
UARTのpin muxをdisableにして解決。
インターバルタイマのクロックソースを確認しろ
HALの関数のインタフェースではインターバルタイマの間隔をマイクロ秒単位で指定できる。
それなのに、1ミリ秒以下にセットしたら異常動作になった。
インターバルタイマのクロックソースが1KHzだったため。
クロックソースを別のものに変更して解決。
サンプルプログラムでそれっぽく動いたので詳細を確認せずに、HALの関数の引数の変更だけでいけるはずと思い込んだのが敗因。