利益:
- 明確なプロンプトを使用してマイクロコントローラーのレジスタ、割り込み、タイミング要件を定義する機能
- AIによって生成されたC/Arduinoコードをレジスタ設定、バッファオーバーフロー、リアルタイム制約に関してチェックする機能
- 生成されたコードをハードウェア (オシロスコープ、シリアル ポート) で測定して検証する習慣を適用する機能
組み込みシステム開発は、ソフトウェアとハードウェアが交差する場所です。レジスタ ビットの設定が間違っていたり、割り込みが長すぎたり、バッファがオーバーフローしたりすると、たとえコードが「コンパイル」されて実行されたとしても、現場で再現が困難な奇妙なエラーが発生します。 AI はまさにこの分野の加速器です。初期スケルトン、ハードウェア抽象化関数、ステート マシン、および通信ルーチンを生成できます。しかし、AI はカードのデータシートを参照せず、クロック周波数を認識せず、リアルタイムの制約を感知しません。この単元では、AI に対するマイクロコントローラーの動作を明確に定義する方法、生成された C/Arduino コードを確認する方法、すべてをハードウェアで測定する必要がある理由について説明します。
要件を明確に定義: 見当、カッティング、タイミング
AI に「LED を点灯せよ」と命令しても機能しません。どのカード、どのピン、どのクロック周波数、どのタイミングでしょうか？組み込みタスクを AI に割り当てるときは、ハードウェア (MCU ファミリ、クロック、ピン)、機能 (何が起こるか)、制約 (タイミング、電力、メモリ)、およびインターフェイス (レジスタ、HAL、Arduino ライブラリ) のフレームワークを使用します。
弱いプロンプト / 強いプロンプト
WEAK: 「STM32 で PWM を生成します。」 (結果: どのタイマー、どの周波数、どのピンが不明瞭です。一般的に、コードという名前のレジスタが間違っている可能性があります。) 強い: 「STM32F103 (72 MHz システム クロック) の TIM3 CH1 (PA6) で 20 kHz、0 ～ 100% 調整可能なデューティ PWM を生成します。レジスタ レベルで書き込みます (HAL ではありません)。 - 20 kHz のプリスケーラと ARR の値を計算し、コメント行に計算を表示します。 - デューティを設定します。関数パラメータは 0 ～ 100 です。 - 使用する各レジスタ ビットをコメントにします。クロックの仮定が間違っていると値が変わることに注意してください。
違いは、強力なプロンプトによりモデルに計算が表示され、クロックの仮定が明らかになることです。したがって、プリスケーラー/ARR 値を個別に確認できます。
20 kHz PWM (72 MHz クロック) の場合:Timer_lock = 72 MHzプリスケーラー = 72-1 → カウンタ クロック = 1 MHzARR = (1 MHz / 20 kHz) - 1 = 50 - 1 = 49検証: 1e6 / (49+1) = 20 000 Hz ✓
AI コードの監査: 何を探すべきか?
生成されたコードがコンパイルされたからといって、それが正しく動作するとは限りません。このチェックリストに従ってください。
コントロールエリア
何を探すべきか
レジスタ/ビット設定
データシートとの完全な互換性、正しいビットマスク
割り込み(ISR)
短いですか？ブロッカー遅延はありませんか?揮発性が使用されていますか?
バッファ/配列
国境管理はありますか？オーバーフローの危険性は？
タイミング
遅延またはタイマー付きですか?実際の時間制限は満たされていますか?
種類と幅
8/16/32 ビット オーバーフロー、符号付き/符号なしの混乱
パワー/ウォッチドッグ
無限ループ給餌ウォッチドッグ?
割り込みサービス ルーチン (ISR) は、最も一般的なエラーの原因です。 AI は、ISR 内に遅延() または長いループを挿入することがあります。これにより、他の割り込みが見逃され、ウォッチドッグがリセットされます。ルール: ISR はできるだけ短くする必要があります。主な仕事は、フラグを設定してメインループに移動することです。
// WEAK (AI がこれを生成する場合があります): ISR のブロッカー関数 void TIM3_IRQHandler(void) { if (TIM3->SR & TIM_SR_UIF) { TIM3->SR &= ~TIM_SR_UIF; read_sensor(); // 時間がかかる可能性があります - BAD CASE_Delay(10); // ISR の遅延 - 非常に悪い }}// STRONG: ISR が不足しています。ジョブはメインループに移動しますvolatile uint8_t tiny_flag = 0; // 揮発性の CONDITIONvoid TIM3_IRQHandler(void) { if (TIM3->SR & TIM_SR_UIF) { TIM3->SR &= ~TIM_SR_UIF; ティックフラグ = 1; // フラグを設定するだけです }}// メインループ内:if (tick_flag) { ticket_flag = 0; read_sensor(); }
注意: 割り込みとメインループ間で共有される変数はすべて揮発性である必要があります。そうしないと、コンパイラが変数をレジスタにキャッシュし、更新を見逃す可能性があります。 AI はこのキーワードを忘れてしまうことがよくあります。コードを読むときに特に探してください。
バッファオーバーフローとタイプエラー
AI は、境界チェックを行わずにシリアル ポートから固定サイズの配列にデータをコピーできます。組み込みシステムでは、これは連続したメモリの破壊と原因不明のクラッシュを意味します。各 strcpy、配列インデックス、DMA バッファーで制限がチェックされていることを確認してください。同様に、8 ビット カウンタは 255 の後にリセットされます。 AI はこれを無視して、あふれるアカウントに依存する可能性があります。
ハードウェアでの検証: 「動作」は想定されるものではなく測定される
組み込みシステムでは、最も信頼できる証拠はコンパイラではなくメーターです。生成されたコードを次の 3 つの方法で検証します。
- オシロスコープ/ロジックアナライザ: PWM周波数、信号タイミング、通信波形を測定します。 20 kHz が必要な場合は、画面上の 20 kHz を参照してください。
- シリアル ポート (UART) ログ: 変数値、状態遷移、およびエラー カウンターを出力し、予想される動作と比較します。
- 限界テストとストレス テスト: 最高の負荷、最速のデータ、最悪のタイミングの下でシステムが耐えられるかどうかをテストします。
測定値が計算と一致しない場合は、クロックの仮定、プリスケーラの値、またはレジスタの設定が正しくありません。追跡。
ミニケース
学生チームは、HC-SR04超音波センサーを使用してAIに距離測定コードを印刷させます。コードはコンパイルされますが、距離は常にとんでもない値になります。これをオシロスコープに接続すると、エコー レッグがマイクロ秒ではなくミリ秒でタイミングを計算していることがわかります。 AI は micros() の代わりに millis() を使用しました。この 1 ワードのエラーにより、測定全体が 1000 倍も混乱しました。生のエコー時間をシリアル ログに出力し、実際の定規と比較すると、エラーが見つかり、修正されます。教訓: コンパイルされたコードは正しいコードではありません。ハードウェアで測定すると、エラーがすぐにわかります。
よくある間違い
- レジスタ名とビット マスクをデータシートと比較せずに受け入れる。
- ISR 内でのブロッキング遅延または長時間の処理を許可します。
- 共有変数の volatile を忘れます。
- バッファーと配列の境界チェックをバイパスします。オーバーフローが見えない。
- クロック周波数とタイミングの仮定を検証せずに信頼する。
- オシロスコープやシリアルログで測定せずに、コードが「動作している」とみなします。
要約すると
- ハードウェア、機能、制約、インターフェイスの観点から組み込みタスクを明確に定義します。
- AIにプリスケーラー/ARRなどのタイミング値を計算させ、独自に検証させます。
- ISR は短くし、共有変数には volatile を使用します。
- 特に、レジスタ、バッファ制限、およびタイプ幅のエラーを探します。
- 「動作する」ことはコンパイラではなく、オシロスコープ、ロジックアナライザ、シリアルログで証明されます。
- 測定値が計算と一致しない場合は、仮定を追跡します。
アプリケーションタスク
お持ちのマイコン（Arduino、STM32、ESP32）を使用して、AI に PWM または特定の周波数での周期的なタスクを依頼します。コードをロードする前に、(1) コメント行でアカウントとは独立して頻度/タイミング値を確認します。(2) ISR および共有変数の揮発性とブロッキングを確認します。アップロード後、オシロスコープやロジックアナライザで実際の周波数を測定し、ターゲットと比較します。逸脱がある場合は、ソースを見つけて修正し、何が間違っていると思われたかを書き留めます。