世界中のすべてではないにしても、ほとんどの主要なデバイス (医療機器を含む) には、何らかの形式のブートスクリーンが搭載されています。このアニメーションは、多くの場合派手ですが、場合によっては単純なアニメーションで 2 つの目的を果たします。 1 つは、単純に見栄えが良く、さらに企業がカスタマイズしてブランディングを追加できることです。しかし、2 番目の理由の方がおそらくより重要です。これにより、デバイスが動作しており、現在まだ起動段階にあることがユーザーにわかります。

このブログでは、ブート画面の設計と作成方法について説明するため、非常に技術的な内容になります。

特に、このブログでは、POSIX 準拠のオペレーティング システム (OS) である QNX のブート画面の設計に伴う落とし穴や複雑さに対処するためのヒントを共有しています。 QNX は、組み込みシステム、より具体的には安全性が重要なハードウェア上で実行されるように設計されたマイクロカーネル OS です。技術的な詳細を支援するために、QNX ドキュメントへの参照が全体に含まれており、さらに明確になります。

QNX の OS ビルド ファイルの定義

ブート画面を設計する最初のステップは、ブート シーケンスの可能な限り早い時間にブート画面が表示されるように QNX をセットアップすることです。 QNX を使用するには、開発者は OSビルドファイル これは基本的に、どのドライバー、アプリケーション、その他の無関係なファイルを OS イメージに含める必要があるかを記述します。この OS イメージはターゲット システムにフラッシュされ、起動時にどのアプリケーションとドライバーが開始されるかを制御します。 QNX には、として知られるグラフィックス システムがあります。 スクリーンサブシステム。これは、ハードウェアに接続された特定のディスプレイに画像をレンダリングするために使用されます。これは、ブート シーケンス中にできるだけ早く開始する必要があります。ブート シーケンスは、ビルド ファイル内で次のようなスクリプト タグとして定義されます。

[+スクリプト] .script={}

中かっこ内の定義された行はシェル スクリプトのように動作します。ここで Screen サブシステムを開始する必要があります。

Screen サブシステムを開始するコマンドは次のようになります。

screen -c {設定ファイルへのパス}.

詳細情報が見つかりました こちら。 Screen サブシステムが開始されると、続いてブートスクリーン バイナリを開始できます。

スクリーンシステムの操作

次のステップは、ブート画面自体を開発することです。 QNX には、ブート シーケンスの一部として画像やアニメーションを表示するネイティブな方法がありません。これはデバイスごとに開発する必要があります。 Screen API は C で記述されているため、ブートスクリーンも C で記述する必要があります。さらに、C を使用すると、ブート画面をより速く開始できるため、ユーザーにデバイスの操作を通知する時間が短縮されます。ブートスクリーンは、Screen API と通信するためにいくつかの定型コードをセットアップする必要があります。詳細が見つかります こちら ただし、それらを列挙するには、ブートスクリーンでコンテキスト オブジェクト、レンダー ターゲット オブジェクト (この場合、必要なレンダー ターゲットはウィンドウ ターゲット)、そして最後にスクリーン バッファー オブジェクトを作成する必要があります。技術的には、C はオブジェクト指向ではないため、この言語にはオブジェクトの概念が存在しません。ただし、説明を簡単にするために、使用される構造体の種類を説明するためにオブジェクトという用語を使用します。

ここでは、定義したばかりのオブジェクトのいくつかの特定のパラメーターに関する説明と指針を示します。ブート画面の画面コンテキスト オブジェクトを作成する場合、SCREEN_APPLICATION_CONTEXT タイプでは不十分です。代わりに、ブート画面には SCREEN_WINDOW_MANAGER_CONTEXT が必要です。理由については後ほど詳しく説明しますが、基本的にはブート画面をいつ終了する必要があるかを知ることに関係しています。詳しい情報は、 こちら.

次に、レンダー ターゲット (この場合はウィンドウ) の使用法プロパティを定義するとき、ブートスクリーンはレンダー バッファーに書き込むことを目的としていますが、必ずしもレンダー バッファーから読み取る必要はないため、これを少なくとも SCREEN_USAGE_WRITE に設定する必要があります。デフォルトは、書き込みフラグと読み取りフラグの組み合わせです。詳しい情報は、 こちら.

最後に、レンダー ターゲットで使用されるバッファの理想的な数は、使用されるブートスクリーンのタイプに応じて 1 つまたは XNUMX つに設定できます。デバイスに単一のイメージを構成する静的なブート画面がある場合、必要なのは XNUMX つのバッファーだけです。ただし、アニメーションを表示する場合は XNUMX つをお勧めします。 XNUMX つをウィンドウのレンダー ターゲットと組み合わせて使用​​すると、ブート画面を二重バッファリングできます。つまり、アニメーションの XNUMX つのフレームが XNUMX つのバッファにロードされている間、Screen サブシステムは他のバッファを表示できます。その後、バッファーへのロードが完了すると、Screen サブシステムはアクティブなバッファーを新しいバッファーに交換します。

画像ライブラリの操作

ここで、ブート画面イメージまたはアニメーションの特定のフレームを解析してロードするには、2 番目の QNX ライブラリを使用する必要があります。 Screen サブシステムはこれを処理しません。代わりに、 画像ライブラリ 使用されている。ブート画面に使用されるイメージ ファイルのタイプに応じて、異なるコーデックの共有オブジェクト (.so) ファイルが必要になります。これらは OS イメージ ビルド ファイルに含まれており、利用可能なもののリストは次のとおりです。 こちら。アニメーションのフレームを接続された画面にレンダリングするには、一連のステップを実行する必要があります。

これらのステップは定義されています こちら いくつかの注意点があります。重要な注意点の 1 つは、使用しているハードウェアによっては、アニメーションのフレーム セット全体がメモリに収まらない可能性があることです。この場合、フレームをオンザフライでロードし、ロード時にレンダリングする必要があります。 2 番目の注意点は、img_load_file() と img_load() (どちらも上記のリンクで参照) は両方とも最初のフレームのみをロードすることです。静止画の場合はこれで十分ですが、アニメーションの場合は不十分です。これらの関数をループ内で使用して各フレームを読み取ることも、取得するフレーム番号を指定する方法がないため機能しません。常に最初のフレームが返されます。

代わりに、両方の注意点に対処するために、コードはフレームをロードしてデコードし、デコード コールバックでアニメーション フレームを Screen サブシステム バッファーに書き込みます。 img_decode_frame() 関数を使用すると、コールバックを定義できます。特に、frame_f() コールバック内にあります (「 こちら) バッファに画像をロードするコードを入れる必要があります。

データをロードする手順は次のとおりです。 データ パラメーターとして渡されるレンダー ターゲット (この場合は screen) を抽出します (これは、uintptr_t から screen_window_t に型キャストする必要があります)。次に、バッファの SCREEN_PROPERTY_POINTER と SCREEN_PROPERTY_STRIDE (「 こちら) は、画像のデータとストライドにそれぞれ設定する必要があります (コールバックの img_t パラメーター)。最後のステップは、(レンダー ターゲットがウィンドウであるため) screen_post_window() を使用して、新しくロードされたイメージを画面にレンダリングすることです。

QNX イベント システムの使用

最後に、ブート画面は本質的にアニメーションを何度も表示する無限ループであるため、ブート画面はいつ終了するかを認識する必要があります。ここで、コンテキスト タイプを SCREEN_WINDOW_MANAGER_CONTEXT に設定することが重要になります。 QNX には、 イベントシステム 新しいウィンドウの作成、破棄、フォーカスの付与などの場合にイベントが生成されます。イベントの完全なリストは次のとおりです。 こちら。 SCREEN_WINDOW_MANAGER_CONTEXT を使用すると、ブート画面は、他のアプリケーションによって生成されるウィンドウ作成イベントとウィンドウ フォーカス イベントをリッスンできるようになります。

ブート画面の 2 つの重要なイベントは、SCREEN_EVENT_CREATE イベントと SCREEN_EVENT_PROPERTY イベントです。 SCREEN_EVENT_CREATE イベントは、メイン アプリケーション (デバイスのメイン ユーザー インターフェイスを表示する) がウィンドウを作成するタイミング、つまりブートスクリーンがシャットダウン シーケンスを開始するタイミングをリッスンするために使用されます。 screen_get_event_property_X() 関数セットを使用すると、このイベントに関するさらなるプロパティを照会できます。 X は、クエリされたプロパティのタイプを示すために使用されます。メイン アプリケーションが SCREEN_PROPERTY_GROUP を定義している場合は、特定のアプリケーションがイベントを起動したかどうかを調べるためにクエリを実行できます。

SCREEN_EVENT_PROPERTY イベントは、別のウィンドウがフォーカスを取得したときに設定される SCREEN_PROPERTY_FOCUS プロパティと組み合わせて使用​​できます (詳細を参照) こちら）。 X 秒の長さのアニメーション (X はデバイスの起動プロセスの長さ) を使用する代わりにイベント システムを使用するということは、メイン アプリケーションがまだ開始されていない場合にアニメーションをループできることを意味します。これにより、タイミングが異なる可能性が高いため、異なるハードウェア間での移植性が大幅に向上します。

タイミングに関しては、イベントを継続的にリッスンすることができないため (もしリッスンするとメインスレッドがロックアップし、アニメーションに後続のフレームが表示されなくなります)、別の戦術を採用する必要があります。ブート画面が静止フレームの場合、これは問題になりません。ただし、アニメーションの長さに応じて、これらのイベントはフレームのほぼ 4 分の 1 セットごとにリッスンする必要がある場合があります。つまり、アニメーションのフレームの 4 分の 1 がロードされるたびに、次の 4 分の 1 のロードが開始される前に、発生する可能性のあるイベントがないかチェックします。

まとめ

結論として、このブログではブートスクリーンが重要な理由を説明し、QNX 用の医療機器ブートスクリーンのセットアップ方法の詳細を提供し、役立つ可能性のある注意事項と設計提案を提供します。ただし、各デバイスのブート画面には異なる要件があります。そのため、このブログでは、段階的なプロセスではなく、提案を提供します。ただし、これらの提案と詳細により、開発者は特定のニーズを満たす医療機器 QNX ブートスクリーンをセットアップできるようになります。

デンディ・アディソンは、 ソフトウェアエンジニア Starfish Medical では、クライアントによる安全で効率的、効果的な医療機器ソフトウェアの開発を支援しています。彼は、開発したソフトウェアを通じて人々の生活に変化をもたらすことに情熱を持っています。 Dendy は、ファームウェアから UI に至るまで、医療機器のあらゆる側面に楽しく取り組んでいます。

 

• SEO を活用したコンテンツと PR 配信。 今日増幅されます。
• PlatoData.Network 垂直生成 Ai。 自分自身に力を与えましょう。 こちらからアクセスしてください。
• プラトアイストリーム。 Web3 インテリジェンス。 知識増幅。 こちらからアクセスしてください。
• プラトンESG。 カーボン、 クリーンテック、 エネルギー、 環境、 太陽、 廃棄物管理。 こちらからアクセスしてください。
• プラトンヘルス。 バイオテクノロジーと臨床試験のインテリジェンス。 こちらからアクセスしてください。
• 情報源： https://starfishmedical.com/blog/creating-a-medical-device-bootscreen-for-qnx/