- 公開日：2025年11月05日
- | 更新日：2025年12月01日
チラシ・郵便物判定システムを作ってみた ～ソフトウェア編～
- ライター：nao
- マイコン
ソフトウェア編はじまり
こんにちは。阿久澤です。
第1話では仕様書作成までを紹介しました。今回はその仕様書をもとにソフトウェアの作成を行っていきます。
ソフトウェアの作成手順
ソフトウェアは以下の手順で作成を行いました。
- FSPのAPIの使い方についてCopilotと学習
- データシートをCopilotに読み込ませて、製品について理解する
- フローチャートを作成
- フローチャートに沿って、プログラム作成
- 作成したプログラムをCopilotに添削してもらう(何度も繰り返す)
FSPの使い方についてはAPIが参照している構造体の中身やAPIに渡す引数、configurationの設定など1から様々なことを学習しました。
データシートの読み取りですが、絶対最大定格や推奨動作条件などは理解できましたが、レジスタ部分に関しては全く理解することができませんでした。この部分に関してもCopilotと会話を繰り返し、使用する製品に関する理解を深めていきました。
この過程で学んだことは、
「挫折せずに、理解できるまでAIに質問を繰り返す」
ことです。
FSPなど、特に0から学ぶ分野に関しては最初何を聞けばよいのかわからない状態からスタートするため、AIに対する質問の質も低いです。そのため、現在の私の理解度では追いつくことができない解答が返ってくることが多々ありました。しかし、私は諦めたくなる葛藤に負けることなく、疑問点をAIに質問し続けました。この繰り返しで徐々に理解が深まり、それに伴って質問の質も向上し、以前よりも少ない会話で情報を得ることができるようになりました。
ここまではAIの活用について記載してきましたが、もちろん周りの先輩方にも頼ってきました。
とくにデバッグ時の不具合や開発環境のエラーなどはAIではなく、先輩方の方が早く解決することができました。特にエラーなどはこれまでの経験から、確認する項目や操作を知っており、解決のスピードが速かったです。FAEとしての付加価値を少し体感できた気がします。
不具合① ～AD変換値が取得できない～
AD変換のコーディングが終了し、いざデバッグを行いましたが、
「プログラムは動作しているのにAD変換値が取得できない、、、」
プログラムのデバックは実行できるのに正常な動作をしない場合は問題点を見つけるのに苦労します。
今回は幸いなことに、光センサはモジュールを使用しており、マイコンボードから光センサモジュールに3本の信号線を差し込むだけだったので、ハード側の問題である可能性は十分に低いことが予想出来ました。
そのため、おそらくソフトが原因であると考え、まずはFSPにおけるADCドライバのシーケンスを振り返りました。
ADCのシーケンスを以下に示します。
- ADCのオープン
→ADCインスタンスを初期化
- スキャン設定
→スキャン対象チャネルを設定（今回はAN006、AN007）
- スキャン開始
→今回はタイマで10msごとにAD変換を開始
- データ取得
→スキャン完了のコールバックが発生したら変換結果を取得
デバッグが正常に実行できたことから、ADCのオープンが失敗していたことは無いと考えられます。
そのため、スキャン設定以降に問題があると考えました。具体的には、
- スキャン対象チャネル設定が間違っている
- タイマのコールバックが機能しておらず、AD変換が開始していない
- スキャン完了のコールバックが発生しておらず、変換結果を取得出来ていない
しかし、この時点ではFSPにおけるADCの設定項目の理解が曖昧だったので、設定項目の確認は飛ばし、スキャン開始以降の問題を探ることにしました。
上記の問題を特定するために、4つの変数を使用し原因の特定を試みました。
実際のコードを以下に示します。
テスト用変数はインクリメントされるようになっています。
デバッグ時にこのテスト用変数を確認することにより、コールバックが呼び出されているか、また呼び出された後に期待する条件式が成立しているかを確認できます。
結果的に、テスト用変数g_adc_count1がインクリメントされていませんでした。
このことから、Scanは開始しているが、その後のAD変換関連のイベント割り込みが発生しておらず、結果としてg_adc_callbackが一度も呼ばれていないことがわかりました。callbackが呼ばれていない場合は設定ミスの可能性が高いため、設定を確認したところ2つの問題点が発覚しました。
1つ目は、AD変換のトリガ条件不一致です。私はソフトウェアトリガでAD変換を開始しようとしていましたが、設定ではハードウェアトリガとなっていました。
2つ目は、チャネル変換の設定です。今回、光センサは2つ使用するためAD変換は2チャネル使用する必要がありましたが、デフォルトの設定では単一チャネル変換となっており、1チャネルのみAD変換値を取得できる設定となっていました。設定の変更は以下の表に示します。
不具合② ～カラーセンサのI2Cが正常に動作しない～
カラーセンサのコーディングとはんだ付けが終了し、いざカラーセンサの単体テストを始めると、
「カラーセンサのMANUFACTURER_IDの期待値が返ってこない、、」
という不具合が発生しました。今回のカラーセンサにおけるMANUFACTURER_IDとは、カラーセンサに供給する電圧や配線が正しい場合に期待値0xE0が格納されるレジスタのことです。
デバッグすると、MANUFACTURER_IDには0xf0や0x70など不定値が格納されており、期待値が格納されません、、
MANUFACTURER_IDの仕様を考慮すると原因はハードにあると考え、配線を確認しましたが
「配線は正しい、、」
原因が特定できず、念のため外部のプルアップ抵抗を追加したところ、
MANUFACTURER_IDの期待値を得ることができました！
この原因を探るために評価ボードのI2Cバスの回路図を確認したところ、私が使用していたバスにはプルアップ抵抗が内蔵されていませんでした。仕様書作成段階では、評価ボードのI2Cバスにプルアップ抵抗が内蔵されていることを確認していたため、外部にプルアップ抵抗を接続していませんでした。
しかし不具合後、もう一度評価ボードの回路図を確認したところ、プルアップは一部のI2Cバスのみ内蔵されており、すべてのI2Cバスには内蔵されていませんでした。結局私は、すべてのI2Cバスにプルアップが内蔵されていると勘違いしており、それが不具合発生の原因でした。
やはり、しっかり確認するべきですね。
カラーセンサの単体テスト
無事、カラーセンサのI2C制御が成功したため、カラーセンサの単体テストを行いました。
この単体テストの目的は以下の2つです。
- カラーセンサと測定物の距離によるRGB値の変化を調べる
- 測定物を照らす照度によるRGB値の変化を調べる
また、自然光によりRGB値は大きな影響を受けるため、暗所で測定を行う必要がありました。
そこで私は以下の測定用ボックスを作成し、距離（1~8cm）と照度（LED1つor LED2つ）を変更してRGB値を取得しました。
測定ボックスは社内の実験室に置いてあったキムワイプを使用しました。ボックスの外側にブレッドボードと評価ボードを配置し、配線を行いました。それらの下に、もう一つのブレッドボードがあり、カラーセンサとLEDを配置しています。ボックスの底面部分をくり抜き、色が測定できるようになっています。
実際の測定の様子は以下になります。
高さ調整に関しては、立体物を作成し、1cm単位で引いた線に合わせて底面のくり抜き部分に立体物を差し込むことで調整を行いました。
気になる測定結果は以下になります！結論から言うと、
「距離1cm、LED1個」
が最適である！
上記のように判断した理由を説明してきます。
以下は距離1cm、LED1個で赤色を測定した際のグラフになります。縦軸が平均RGB値（2回測定したため）を示し、横軸はカラーセンサと測定物の距離を示しています。グラフより、1cmに近いほど、有効なRGB値が取得できていることがわかります。
以下は同様の条件で、LED2個の際のグラフになります。
図9.5と比較すると2cm付近から赤色が判定できなくなっていることがわかります。また、1cmとの比較においてもLED1個と2個で大きな変化は確認できないため、LEDの個数は1個で良いことがわかります。
以下の上図は、距離1cm、LED個数1個の場合のそれぞれの色の平均RGB値を示し、下図は距離1cm、LED個数1個の場合を示しています。比較すると8cmではすべての色においてG値が最も高く出力されており、有効なRGB値が取得出来ていないことがわかります。以上の理由から、カラーセンサと測定物の距離は1cm、LEDの個数は1個で設計を行う必要があることがわかりました。
ソフトウェア編のまとめ
ソフトウェア作成は様々なエラーや不具合に悩まされましたが、事前のルネサス研修の際に身に着けたやり方やAIの活用、先輩方の助けもあり、無事ソフトを完成させることができました。ひとまず安心です。
カラーセンサの単体テストでは、測定ボックスを作成したことで、有効なデータを取得することができました。
次回「第３話：ハードウェア編」