コンテンツにスキップ

製品検証

これらのチュートリアルは、複数サブシステムの連携までの内容を身につけていることを前提としています。ペリフェラルを動かしてミドルウェアと連携させ、少なくとも1つの共存問題を実際に経験している段階です。ここでは、動作するデモを製品として出荷できる状態にするための作業を扱います。消費電力の測定、更新中断後の復旧を考慮したOTA、カスタムハードウェアの初期化、クラッシュ解析、Bluetoothの複数接続、再利用可能なドライバーなどです。

製品検証では、単一のサンプルをコピーするより、検証結果を証跡として積み上げることが重要です。各チュートリアルについて、ボードのリビジョン、SDKのバージョン、ベースにしたサンプル、テスト環境、期待した結果、実際の結果、変更点を記録してください。

機能を一度動かすだけでなく、消費電力の測定、失敗から復旧できる更新、再現可能なカスタムハードウェアの初期化、通常の処理経路以外で発生する障害の証跡が必要な場合に、このシリーズを活用してください。

SiFli-SDKのサンプルパスや対応ボードは、SDKのバージョンによって異なる場合があります。ビルド前に各サンプルの最新の「Supported Platforms」と、ボード固有のハードウェア要件・設定を確認してください。ある演習に対応していても、同じボードがほかのサンプルやすべての機能の組み合わせに対応しているとは限りません。

低消費電力モードとウェイクアップ要因をチューニングする

目標： ファームウェアがスリープ関数を呼び出しているだけで低消費電力だと判断せず、実測に基づいてバッテリー駆動時間を評価する。

所要時間： 2時間以上、測定セットアップ込み

出発点： example/pm/classical、example/pm/raise_wrist

  1. 低消費電力の概要の手順に従って、電流測定環境を用意してください。
  2. 起動時、アクティブ時、接続アイドル時、ディスプレイオフアイドル時、そして可能であればDeep Sleep時のベースラインを記録してください。
  3. classical PMサンプルから始め、rt_pm_request(PM_SLEEP_MODE_IDLE)でIDLEより深い低消費電力モードへの移行を抑止し、後でrt_pm_release(PM_SLEEP_MODE_IDLE)でその制限を解除している箇所を確認してください。また、ペリフェラル動作中にドライバーフレームワークが自動的にスリープを抑止するかも確認してください。
  4. 次にraise-to-wakeサンプルを調べ、加速度計のサンプリング、手首のジェスチャー認識、ディスプレイの点灯、スリープへの復帰の流れを確認してください。割り込みを使っていると決めつけず、実際のサンプリング方法とウェイクシーケンスを確認してください。
  5. 同じ省電力設計の考え方を自分の製品に適用してください。ハードウェアとドライバーが対応している場合は、不要なタイマーやポーリングを避けるために割り込みまたはイベント駆動処理を使います。
  6. 各変更のたびに再測定してください。
  7. Deep Sleepが期待ほど深くならない場合は、list_thread、list_device、PMログ、ウェイクアップ要因の診断情報を使って、まだ動作しているサブシステムを特定してください。

成功基準： ファームウェアが期待される低消費電力状態に到達し、電流が実行間で再現可能であり、ウェイクアップ要因が偶発的ではなく意図的である。

トラブルシューティング： 一度は消費電力が良好でも後で悪化する場合は、エラー処理と再接続処理、ディスプレイの終了処理、オーディオセッションの終了処理、起動後に作成されるタイマーを確認してください。

学んだこと： 「低消費電力のはず」という想定から実測へ移る方法と、解除されずに残っているPMの電源状態要求を特定する方法。

BLE経由でOTAファームウェア更新を追加する

目標： 有線接続なしで、現場でファームウェアを更新する。

所要時間： 2時間

出発点： example/ble/peripheral_with_ota

  1. OTA対応のペリフェラルサンプルをビルドして書き込んでください。
  2. 更新を試みる前に、通常のBLEペリフェラルの挙動がまだ動作することを確認してください。
  3. OTA更新をトリガーし、デバイスが新しいイメージで起動することを確認してください。
  4. 明確な復旧手順があるテスト機で、一度に一つずつ中断ケースを試してください。例えば、転送中に接続を切る、または通信範囲外に移動します。ボードの資料と製品の復旧設計で安全性が明示されていない限り、電源を遮断しないでください。
  5. 更新が中断または拒否された後に製品が実際に行う処理（再試行、再開、復旧モード、ロールバックなど）を確認してください。ロールバックは、ブート処理とパーティション設計で実装されている場合にのみ要件とします。
  6. 古いボンディング情報が残っている状態、スマートフォン側でデバイスの登録を解除した後、デバイスを再起動した後にも、それぞれOTAをテストしてください。
  7. 製品がすでにデータ通信にPANを使用している場合は、PAN OTAパスを別の設計上の選択肢として評価してください。

成功基準： 更新に成功すると新しいイメージで起動し、中断または拒否された更新は製品で定めた復旧ポリシーに従い、ユーザーが現在の状態を判断できること。すべてのOTA設計がロールバックに対応するとは限らないため、前提にしないでください。

トラブルシューティング： パーティションレイアウト、使用している場合はイメージの署名や整合性チェック、起動イメージの選択と復旧動作、設計にロールバックが含まれるか、転送中の接続パラメーター、ボンディング情報やストレージ上の変更が更新後も保持されるかを確認してください。

学んだこと： パーティション、イメージ検証、起動選択、復旧ポリシーがOTAの挙動をどう決めるか、そして更新成功だけでは中断後の復旧を証明できない理由。

カスタムディスプレイモジュールを立ち上げる

目標： 既に対応済みのリファレンスパネルに頼らず、新しいLCD、AMOLED、EPD、またはメモリーディスプレイを移植する。

所要時間： 3時間以上

出発点： SDK内でお使いのパネルに最も近い既存のディスプレイドライバー

  1. パネルのデータシート、初期化シーケンス、タイミングパラメーター、インターフェースタイプ、リセット要件、電源シーケンスを収集してください。
  2. 選定したSF32デバイスとパッケージが、必要なインターフェースとピン配置に対応していることを確認してください。
  3. 最も近い既存のディスプレイドライバーをコピーし、パネル固有の初期化シーケンスとレジスターマップを置き換えてください。
  4. まず単色表示を確認してください。パネルに簡単なパターンを表示できるようになるまで、LVGLウィジェットのデバッグを始めないでください。
  5. カラー順序、バイト順、向き、アドレスウィンドウ、部分更新の挙動を検証してください。
  6. 「複数サブシステムの連携」の演習2で使用したLVGLを再び組み込んでください。
  7. 選択したチップ、ディスプレイ経路、ドライバー、SDKが対応している場合に限り、DMA、部分リフレッシュ、ePicasso高速化を1つずつ有効にしてください。
  8. ディスプレイ消灯、スリープ、復帰、再初期化の各動作をテストしてください。

成功基準： パネルがコールドブートとリセットの後に確実に初期化され、既知のパターンを正しく描画し、破損なしにスリープ/ウェイクを乗り越える。

トラブルシューティング： 単色表示が正しくない場合は、UIコードを変更する前に、ピクセルフォーマット、MADCTL/向きビット、バイト順、コマンド/データ配線、リセットタイミング、電源レールの投入順序を確認してください。

学んだこと： 電気的な問題や初期化シーケンスの問題を、UIフレームワークの設定問題と切り分ける方法。

CPU使用率をプロファイルしクラッシュを解析する

目標： デバッガーを接続した状態では再現しにくい問題を調べる。

所要時間： 2時間

出発点： example/system/cpu_usage_profiler、example/system/coredump

  1. 「複数サブシステムの連携」で組み合わせたワークロードの1つを対象に、CPU使用率プロファイラーのサンプルを実行してください。
  2. どのタスクがCPU時間を消費しているか、そしてそれが想定と一致するかを特定してください。
  3. 練習用ブランチや使い捨てのサンプルに制御された不具合を追加し、コアダンプを取得してください。
  4. SDKのダンプ解析ツールを使って、不具合の発生元関数とコールスタックを特定してください。
  5. list_thread、ログ、直近のイベントとクラッシュのコンテキストを比較してください。
  6. 意図的な不具合を取り除き、実際の断続的な問題があればそのフローを繰り返してください。

成功基準： 推測ではなく、取得した証跡を使ってパフォーマンス問題とクラッシュの両方を説明できる。

トラブルシューティング： コールスタックを解釈する前に、シンボルが書き込み済みのバイナリと一致していること、ログにファームウェアバージョンが含まれていること、最適化レベルが把握されていることを確認してください。

学んだこと： 遅い処理経路に対する能動的なプロファイリングと、ライブでは捕まえにくい失敗に対する事後のダンプ解析。

マルチコネクションBLE製品を構築する

目標： 複数の同時BLEロールまたは接続をサポートする。

所要時間： 2時間

出発点： example/ble/central_and_peripheral、example/ble/multi_connection

  1. 「複数サブシステムの連携」の演習3で確認したペリフェラルの動作を出発点にしてください。
  2. それに加えて、セントラルロールを追加してください。例えばスマートフォンに対してはペリフェラルとして、センサーアクセサリに対してはセントラルとして動作するなどです。
  3. 複数の同時接続に拡張してください。
  4. 各接続について、接続間隔、スレーブレイテンシ、監視タイムアウト、通知レートを記録してください。
  5. アプリケーションコードを疑う前に、SDKのスループットサンプルを使って基準となるスループットを測定してください。
  6. 再接続、スマートフォンのスリープ、アクセサリの喪失、同時通知バーストをテストしてください。

成功基準： すべての意図したロールが確実に接続、切断、再接続し、組み合わせた活動下でも接続パラメーターの選択が安定している。

トラブルシューティング： 互換性のないパラメーター要求、過剰な通知トラフィック、処理をブロックするアプリケーションコールバック、リンクイベントのたびにメインCPUを起こす電源管理方針がないか確認してください。

学んだこと： 対応するSiFli-SDKのBLE構成ではペリフェラルロールとセントラルロールを組み合わせられ、一部の構成では複数の同時接続も可能です。対象チップ、スタック設定、サンプルでサポートされるロールと接続数を確認してください。複数のリンクが無線スケジュールを共有すると、接続パラメーターの選択が互いに影響します。

カスタムRT-Threadデバイスドライバーを書く

目標： SDKに既存ドライバーがないペリフェラルを、その場限りのアプリケーション処理ではなく、RT-Threadデバイスとして正しく統合する。

所要時間： 3時間以上

出発点： SDKのアプリケーション開発ガイドと、最も近い既存ドライバー

  1. SDKがボード定義、ピンマルチプレクス、クロック、ペリフェラルドライバーをどのように編成しているかを確認してください。
  2. ペリフェラルにアーキテクチャ的に最も近い既存のドライバーから始めてください。
  3. バスアクセス、デバイス登録、設定、アプリケーションロジックを分離した状態に保ってください。
  4. デバイスを登録し、それがlist_deviceの下に表示されることを確認してください。
  5. これまでのチュートリアルでADC、PWM、I2C、ストレージデバイスを検証したのと同じ方法で、ドライバーをテストしてください。
  6. ハードウェア欠落、無効な引数、タイムアウト、サスペンド/レジュームに対するエラー処理を追加してください。
  7. ドライバーが再利用可能であれば、製品間でコピーアンドペーストするのではなく、SDKコンポーネントとしてパッケージ化してください。

成功基準： アプリケーションコードが通常のRT-Threadデバイスモデルを通じてドライバーを見つけて使用でき、ドライバーが初期化、使用、エラー、スリープ/ウェイクの各経路にわたって予測可能に動作する。

トラブルシューティング： ドライバーが1つのアプリケーションファイルからしか使えない場合、デバイスモデルを迂回している可能性があります。組み込みのデバイスドライバーと同じように使えるまでリファクタリングしてください。

学んだこと： 保守上の負債を作るのではなく、SDKのエコシステムをきれいに拡張する方法。

製品検証のリリースチェックリスト

  • 電力の数値が測定済みで、再現可能であり、名前付きのテストシナリオに紐づいている。
  • 製品で定めたポリシーに照らして、OTAの成功、整合性チェック、中断後の復旧を検証済みである。ロールバックは設計で実装されている場合にのみ、検証済み能力として扱う。
  • カスタムディスプレイの初期化が、LVGLの複雑な機能を追加する前にテストパターンで検証されている。
  • プロファイリングとコアダンプのワークフローがチーム向けに文書化されている。
  • マルチコネクションBluetoothが、再接続とスマートフォン/アクセサリのエッジケースにわたってテストされている。
  • カスタムドライバーがRT-Threadデバイスモデルを使用し、スリープ/ウェイクを処理する。
  • 組み合わせ負荷テストに、該当する場合はディスプレイ、Bluetooth、ストレージ、オーディオ、センサー、AIが含まれている。

次に進む先

ここまでで、ペリフェラル、ミドルウェア、共存性、消費電力管理、OTA、カスタムハードウェアの初期化、事後デバッグ、ドライバー統合に必要な一通りの手段を学びました。今後は、サンプルカタログとグラフィックスの概要を継続的なリファレンスとして活用してください。最初から順に読むのではなく、必要な機能に応じて参照します。

最終更新: