複数サブシステムの連携¶
これらのチュートリアルは、ペリフェラル入門で扱うGPIO、シェル、ADC/PWMの基礎、rt_device_find()を使ったドライバーの基本パターンを理解していることを前提としています。ここでは、個々のペリフェラルから、I2Cセンサー、グラフィカルUI、BLEサービス、オーディオ再生、データの永続保存、簡単な共存テストといった、ミドルウェアを含む複合的な処理へと進みます。
各サブシステムを一度動かすだけでなく、SF32ファームウェアの一般的な組み立て方を学ぶことが目的です。用途に合ったSDKサンプルを起点にハードウェア経路を検証し、RT-Threadデバイス層またはミドルウェア層に接続してから、製品のほかの機能と組み合わせてテストします。
個々のペリフェラルが動作し、共有メモリーやタイミング、消費電力、ボード固有の配線、ミドルウェア間の相互作用といった統合上の課題に取り組む段階で、このチュートリアル群を活用してください。各演習では、画面を見せるだけのデモにとどめず、独立してテストできるサブシステムとして機能を切り分けます。
始める前に¶
以下のCコードは抜粋であり、そのままビルドできる完全なソースファイルではありません。プロジェクトやSDKのバージョンに応じて、必要なヘッダー、宣言、エラー処理、リソースの解放を追加してください。
サンプルのパスや対応ボードはSDKのバージョンによって異なる場合があります。ビルド前に、各サンプルの「Supported Platforms」とボード固有のハードウェア要件・設定を確認してください。ある演習に対応しているボードでも、ほかのサンプルに対応しているとは限りません。
| 要件 | 重要な理由 |
|---|---|
| 動作するシェル | list_thread、list_device、ログ、そして迅速な検査が必要です。 |
| 動作確認済みのGPIO入出力 | 多くのミドルウェアのデモは、依然としてボタン、LED、または割り込みを必要とします。 |
| ボードの回路図 | I2Cピン、ディスプレイピン、オーディオ経路、ストレージレイアウトはボード固有です。 |
| 動作確認済みの基準構成 | 機能を組み合わせる前に、正常に動作するビルドを保存しておきます。 |
| 電流測定の手段 | サブシステムを連携させると、一見正常に動作していても、待機時の消費電力が変わることがあります。 |
I2C経由でセンサーを読み取る¶
目標: 単一のGPIOピンではなく、実際のI2Cペリフェラルと通信する。
所要時間: 30〜45分
出発点: example/hal/i2c/masterまたはexample/rt_device/i2c/eeprom
struct rt_i2c_bus_device *bus = (struct rt_i2c_bus_device *)rt_device_find("i2c1");
struct rt_i2c_msg msgs[2] = { /* write register address, then read result */ };
rt_i2c_transfer(bus, msgs, 2);
ここでのi2c1は例示用の名前です。お使いのボードで登録されているI2Cデバイス名を指定し、バスを使う前にrt_device_find()が成功したことを確認してください。
- センサーのデータシートから、I2Cアドレス、レジスターマップ、供給電圧、必要なプルアップを確認してください。
- お使いのボードがどの
i2cXバスとピンを使用しているかを確認してください。 - I2C EEPROMまたはマスターのサンプルをベースに、センサーと通信する処理を実装してください。デバイスIDレジスターがある場合は最初に読み取り、ない場合は期待される動作が分かっているレジスターから確認します。
- 一つの実際の測定値をデコードし、シェル経由で出力してください。
- センサーに割り込みまたはデータレディピンがある場合は、そのピンをGPIOに接続し、ペリフェラル入門の演習2で扱った割り込み処理を適用してください。
- 可能な限り、定期的なポーリングではなく、イベントをきっかけに読み取る方式にしてください。
成功基準: ファームウェアが既知のレジスターを期待どおりに読み取り(デバイスIDレジスターがある場合はその値を読み取り)、妥当なセンサー値をデコードし、デバイスが存在しない場合もシステムをブロックしない。
トラブルシューティング: 読み取り結果がすべて0xff、すべて0x00、またはタイムアウトになる場合は、アドレス幅、7ビットと8ビットのアドレス表記の違い、プルアップ、電源シーケンス、そして別のペリフェラルが同じピンを占有していないかを確認してください。
学んだこと: 複数バイトのI2Cトランザクション、そして割り込み駆動のGPIOピンとバスペリフェラルを組み合わせる方法。
基本的なLVGL画面を作る¶
目標: 生のフレームバッファー書き込みではなく、ディスプレイ上に実際のUI要素を表示する。
所要時間: 45〜60分
出発点: example/multimedia/lvgl/lvgl_v8_examples
lv_obj_t *label = lv_label_create(lv_scr_act());
lv_label_set_text(label, "Hello, SF32!");
lv_obj_align(label, LV_ALIGN_CENTER, 0, 0);
- ディスプレイドライバーを初期化し、LVGLウィジェットをデバッグする前に単色表示を確認してください。
- ラベルとボタンウィジェットを作成してください。
- ボタンのコールバックを配線し、ラベルのテキストを変更してください。
- 小さなアニメーションを一つ追加し、シェルツールでCPU使用率やフレームタイミングを観察してください。
- スケールアップする前に、グラフィックスの概要のバッファー戦略、部分リフレッシュ、ePicassoに関するセクションを読んでください。
成功基準: リセット後も画面が安定して初期化され、利用可能で設定済みのタッチまたはボタン入力によってUIの状態が変わり、簡単なアニメーションがシェルやBluetoothの処理を妨げない。
トラブルシューティング: パネルの問題とLVGLの問題を切り分けてください。単色塗りつぶしが失敗する場合は、LVGLのコードに触れる前に、電源、リセット、初期化シーケンス、ピクセルフォーマット、バイト順を確認してください。
学んだこと: LVGLのオブジェクト/イベントモデルと、グラフィックスを多用するプロジェクトの出発点となるディスプレイの初期化手順。
BLEペリフェラルとしてアドバタイズして接続する¶
目標: 実際に動作するGATTサービスを介して、スマートフォンまたはBLEセントラルデバイスをボードに接続する。
所要時間: 45〜60分
出発点: example/ble/peripheral
- まずシンプルなペリフェラルサンプルから始め、BLEスキャナーアプリでアドバタイズを確認してください。
- スマートフォンから接続し、デバイスが数分間安定していることを確認してください。
- センサーの値を送信する場合は、サンプルのGATTサービスに用途に合ったCharacteristicを設定し、実測値で更新してください。たとえば、「ペリフェラル入門」の演習4で取得したADC値や、このシリーズの演習1で取得したI2Cセンサー値を使えます。
- Characteristicに必要なプロパティを設定します。通知を使う場合は有効にし、値の変化がスマートフォンに届くことを確認してください。
- 切断後の再接続と、接続中にボードをリセットするケースを試してください。
- カスタムサービスを設計する前に、Bluetoothの概要を読んでください。
成功基準: デバイスがアドバタイズして接続し、設定したGATTサービスを公開し、選択したCharacteristicプロパティに応じてデータをやり取りし、切断/再接続後にクリーンな状態に戻る。
トラブルシューティング: 古いボンディング情報が残っている場合、スマートフォン側でデバイスを登録解除した場合、接続中にデバイスを再起動した場合、接続パラメーターを変更した場合の挙動をそれぞれ確認してください。BLEの不具合は、最初の接続が正常に成功した後で初めて現れることも少なくありません。
学んだこと: 多くのBLE製品で使われる、アドバタイズ → 接続 → GATT通知の流れ。
ストレージからローカルオーディオを再生する¶
目標: 合成音ではなく、オーディオファイルを再生する。
所要時間: 45〜60分
出発点: example/multimedia/audio/local_music
現行ドキュメントでは、example/multimedia/audio/mp3_sd_playerの対応プラットフォームとしてsf32lb52-lchspi-ulpが記載されています。お使いのボードも対応しているとは限らないため、使用前に対応プラットフォームとハードウェア要件を確認してください。
- サンプルが想定するストレージメディアに、小さなWAVまたはMP3ファイルをロードしてください。
- サンプルをビルドして書き込んでください。
- 再生が始まり、音声に歪みがなく、再生開始時にボードがリセットしないことを確認してください。
- ペリフェラル入門の演習2で作成したボタンハンドラーに、再生の開始/停止処理を組み込んでください。
- シェルへのログ出力やディスプレイ更新中に、バッファーアンダーランによる音切れが起きないか確認してください。
- サンプルレート、フォーマット、バッファーサイズを変更する前に、オーディオの概要を読んでください。
成功基準: 再生を繰り返し開始・停止・再開しても、ポップノイズやバッファーアンダーランが発生せず、再生停止後に不要な高消費電力状態が残らない。
トラブルシューティング: 音が歪む場合は、サンプルレート、ビット深度、出力経路、コーデック設定、ファイル形式、バッファーサイズを確認してください。また、ストレージからの読み出しがデコーダーへのデータ供給に追いついているかも確認します。
学んだこと: SDKのオーディオミドルウェア、バッファーを使った再生、ファイルのデコードがどのように連携するか。
データを永続化して読み書きする¶
目標: リセットのたびに失うのではなく、再起動をまたいでデータを永続化する。
所要時間: 30〜45分
出発点: example/storage/littlefsまたはexample/storage/flashdb
ファイル単位で扱うデータにはLittleFSを使います。FlashDBは、キー・バリューデータベース(KVDB)と時系列データベース(TSDB)のモードを備えた組み込みデータベースです。ストレージのバックエンドと対応ボードはサンプル構成によって異なります。対象を選ぶ前に、公式のLittleFS NORサンプルとFlashDBサンプルを確認してください。
以下のPOSIX呼び出しは、マウント済みファイルシステムへのアクセス例です。FlashDBのAPIではありません。
int fd = open("/data/log.txt", O_WRONLY | O_CREAT | O_APPEND, 0666);
write(fd, buf, len);
close(fd);
- ファイル形式のログにはLittleFSなどのファイルシステムを使います。構造化された設定や時系列データにはFlashDBのKVDBまたはTSDBを検討し、ボードとメモリーデバイスに合うバックエンドを選んでください。
- サンプルが使用するパーティションとマウントパスを確認してください。
- 一つの小さなログエントリまたは設定を書き込んでください。
- ボードの電源を入れ直し、データがまだ残っていることを確認してください。
- チュートリアル1のセンサー読み取り値を定期的にログしてください。
- ログが際限なく増えないよう、簡単な保持ポリシーを追加してください。
成功基準: 再起動後もデータが残り、ストレージが存在しない、満杯、または初期フォーマット直後の場合でもファームウェアが適切に処理する。
トラブルシューティング: パーティション構成、マウントパス、フラッシュの消去/書き込みエラー、ファイルのクローズ処理を確認してください。また、書き込み頻度がストレージの書き込み耐久目標に対して高すぎないかも確認します。
学んだこと: ファイルシステムと組み込みデータベースの使い分け、そして製品の状態をリセットをまたいで保持する方法。
意図的に二つのサブシステムを組み合わせる¶
目標: 二つのサブシステムを同時に動かし、それらが互いにどう影響するかを学ぶ。
所要時間: 1時間
出発点: チュートリアル1〜5のうち、製品に最も関連する二つ
- 製品で実際に一緒に必要となる二つのサブシステムを選んでください。例えばBLEとI2Cセンサー、あるいはLVGLとオーディオ再生などです。
- まずそれぞれを独立して検証してください。
- 最小限の変更で組み合わせてください。
- 両方を同時に動かして負荷をかけてください。たとえば、I2C読み取り中にBLE通知を送る、オーディオ再生中にUIアニメーションを動かす、センサー更新中にストレージへ書き込む、といった組み合わせです。
- CPU使用率、ログ、メモリー、ユーザーに見える挙動を観察してください。
- 観察結果を、Bluetoothの概要、グラフィックスの概要、低消費電力設計の概要と比較してください。
成功基準: 両方のサブシステムが同時活動下でも動作し続け、テスト停止後にアイドル電流が期待どおりのレベルに戻る。
トラブルシューティング: 長時間ブロックする呼び出し、過剰なログ出力、タイマーの過剰な発生、レイテンシが重要な処理経路でのストレージ書き込み、共有バッファーのキャッシュ処理の誤りがないか確認してください。
学んだこと: 個別には正常に動作するサブシステムでも、CPU時間、メモリー帯域幅、割り込み、電源管理方針を共有すると、互いの動作に影響することがあります。
連携するサブシステムの統合チェックリスト¶
- すべてのチュートリアルが動作確認済みのSDKサンプルから始まっている。
- 各ハードウェア経路の動作を先に確認している: 既知のセンサーレジスターまたは値の読み出し、画面の単色表示、BLEアドバタイズ、音声出力、ストレージのマウントなど。
- 該当する場合、機能がリセットおよび切断/再接続の後も維持される。
- エラー経路がテストされている: センサー未接続、ファイル欠落、スマートフォン切断、ストレージ満杯。
- 少なくとも一つの組み合わせ負荷テストが実行されている。
- 各機能を停止した後のアイドル時の挙動が確認されている。
次に進む先¶
製品検証では、低消費電力の調整、OTA更新、カスタムディスプレイとドライバーの初期化、Bluetoothの複数接続、量産時のデバッグを扱います。ここで学ぶ内容を通じて、動作するデモを製品として出荷できるファームウェアへと仕上げていきます。
最終更新: