Die meisten, wenn nicht alle wichtigen Geräte (einschließlich medizinischer Geräte) auf der ganzen Welt verfügen über eine Art Startbildschirm. Diese oft auffällige, aber manchmal einfache Animation erfüllt zwei Zwecke. Zum einen sieht es einfach gut aus, außerdem können Unternehmen es personalisieren und mit ihrem Branding versehen. Aber der zweite Grund ist wohl wichtiger; Es informiert den Benutzer darüber, dass das Gerät funktioniert und sich derzeit noch in der Startphase befindet.

Dieser Blog wird sehr technisch, da er beschreibt, wie man einen Bootscreen entwirft und erstellt.

Insbesondere gibt der Blog Tipps zur Beseitigung der Fallstricke und Komplikationen, die mit der Entwicklung eines Bootscreens für das POSIX-kompatible Betriebssystem (OS) QNX einhergehen. QNX ist ein Mikrokernel-Betriebssystem, das für die Ausführung auf eingebetteten Systemen und insbesondere auf sicherheitskritischer Hardware entwickelt wurde. Um die technischen Details zu erleichtern, sind zur weiteren Erläuterung durchgehend Verweise auf die QNX-Dokumentation enthalten.

Definieren der Betriebssystem-Build-Datei für QNX

Der erste Schritt beim Entwerfen eines Startbildschirms besteht darin, QNX so einzurichten, dass sichergestellt wird, dass der Startbildschirm zum frühestmöglichen Zeitpunkt in der Startsequenz angezeigt wird. Um QNX verwenden zu können, muss ein Entwickler eine definieren Betriebssystem-Build-Datei Darin wird im Wesentlichen beschrieben, welche Treiber, Anwendungen und andere überflüssige Dateien in das Betriebssystem-Image aufgenommen werden müssen. Dieses Betriebssystem-Image wird dann auf das Zielsystem geflasht und steuert, welche Anwendungen und Treiber beim Booten gestartet werden. QNX verfügt über ein Grafiksystem namens Bildschirm-Subsystem. Es wird verwendet, um das Bild auf einem bestimmten, an die Hardware angeschlossenen Display darzustellen. Dies sollte so schnell wie möglich während der Boot-Sequenz gestartet werden. Die Startsequenz ist in der Build-Datei als Skript-Tag definiert, das wie folgt aussieht:

[+script] .script={}

wobei alle definierten Zeilen innerhalb der geschweiften Klammern wie ein Shell-Skript wirken. Hier sollte das Screen-Subsystem gestartet werden.

Der Befehl zum Starten des Screen-Subsystems sieht folgendermaßen aus:

screen -c {path_to_config_file}.

Weitere Informationen finden Sie hier. Nachdem das Screen-Subsystem gestartet wurde, kann anschließend die Bootscreen-Binärdatei gestartet werden.

Arbeiten mit dem Bildschirmsystem

Der nächste Schritt besteht darin, den Bootscreen selbst zu entwickeln. QNX bietet keine native Möglichkeit, ein Bild oder eine Animation als Teil der Startsequenz anzuzeigen. Dies muss für jedes Gerät einzeln entwickelt werden. Da die Screen-API in C geschrieben ist, sollte auch der Bootscreen in C geschrieben sein. Darüber hinaus stellt die Verwendung von C sicher, dass der Startbildschirm viel schneller gestartet werden kann und somit die Zeit verkürzt wird, den Benutzer über den Gerätebetrieb zu informieren. Der Bootscreen muss einen Boilerplate-Code einrichten, um mit der Screen-API zu kommunizieren. Einzelheiten finden Sie hier hier aber um sie aufzulisten, muss der Bootscreen ein Kontextobjekt, ein Renderzielobjekt (in diesem Fall ist das benötigte Renderziel ein Fensterziel) und schließlich ein Bildschirmpufferobjekt erstellen. Da C technisch gesehen nicht objektorientiert ist, existiert das Konzept von Objekten in der Sprache nicht. Zur Vereinfachung der Erklärung wird jedoch der Begriff „Objekte“ verwendet, um die verwendeten Strukturtypen zu beschreiben.

Hier finden Sie Erläuterungen und Hinweise zu einigen spezifischen Parametern für die gerade definierten Objekte. Beim Erstellen des Bildschirmkontextobjekts für den Bootscreen reicht der Typ SCREEN_APPLICATION_CONTEXT nicht aus. Stattdessen benötigt der Bootscreen den SCREEN_WINDOW_MANAGER_CONTEXT. Der Grund wird später ausführlich erklärt, aber im Wesentlichen hängt es damit zusammen, dass man weiß, wann der Bootscreen beendet werden muss. Weitere Informationen finden Sie unter hier.

Als nächstes sollte beim Definieren der Verwendungseigenschaft des Renderziels, in diesem Fall des Fensters, diese mindestens auf SCREEN_USAGE_WRITE gesetzt werden, da der Bootscreen beabsichtigt, in den Renderpuffer zu schreiben, aber nicht unbedingt daraus lesen muss. Der Standardwert ist eine Kombination aus Schreib- und Leseflags. Weitere Informationen finden Sie unter hier.

Schließlich kann die ideale Anzahl von Puffern, die vom Renderziel verwendet werden sollen, je nach Art des verwendeten Bootscreens auf eins oder zwei festgelegt werden. Wenn das Gerät über einen statischen Startbildschirm verfügen soll, der ein einzelnes Image darstellt, ist nur 1 Puffer erforderlich. Wenn jedoch eine Animation angezeigt wird, werden zwei empfohlen. Durch die Verwendung von zwei in Kombination mit einem Renderziel eines Fensters kann der Startbildschirm doppelt gepuffert werden. Mit anderen Worten: Während ein Frame der Animation in einen Puffer geladen wird, kann das Screen-Subsystem den anderen Puffer anzeigen. Wenn das Laden des Puffers abgeschlossen ist, tauscht das Screen-Subsystem den aktiven Puffer gegen den neuen aus.

Arbeiten mit der Bildbibliothek

Jetzt muss eine zweite QNX-Bibliothek verwendet werden, um bestimmte Frames des Bootscreen-Bildes oder der Bootscreen-Animation zu analysieren und zu laden. Das Screen-Subsystem kann dies nicht verarbeiten. Stattdessen die Bildbibliothek wird eingesetzt. Abhängig von der Art der Bilddatei, die für den Startbildschirm verwendet wird, werden unterschiedliche Codec-Shared-Object-Dateien (.so) benötigt. Diese wären in der Build-Datei des Betriebssystem-Images enthalten und es gibt eine Liste der verfügbaren hier. Um einen Frame einer Animation auf einem angeschlossenen Bildschirm darzustellen, ist eine Abfolge von Schritten erforderlich.

Diese Schritte sind definiert hier mit ein paar Vorbehalten. Eine wichtige Einschränkung besteht darin, dass je nach verwendeter Hardware möglicherweise nicht alle Frames einer Animation in den Speicher passen. In diesem Fall müssten die Frames im laufenden Betrieb geladen und beim Laden gerendert werden. Die zweite Einschränkung besteht darin, dass sowohl img_load_file() als auch img_load() (beide im obigen Link erwähnt) nur den ersten Frame laden. Für ein Standbild ist das ausreichend, für eine Animation jedoch nicht. Die Verwendung dieser Funktionen in einer Schleife zum Einlesen jedes Frames funktioniert ebenfalls nicht, da es keine Möglichkeit gibt, die abzurufende Frame-Nummer anzugeben. Es wird immer der erste Frame zurückgegeben.

Um beide Einschränkungen zu beheben, lädt und dekodiert der Code stattdessen den Frame und schreibt dann im Dekodierungsrückruf den Animationsframe in den Puffer des Screen-Subsystems. Die Funktion img_decode_frame() ermöglicht die Definition von Rückrufen und ist speziell im Rückruf von frame_f() enthalten (siehe hier), dass der Code zum Laden des Bildes in den Puffer abgelegt werden soll.

Die Schritte zum Laden der Daten sind wie folgt: Extrahieren Sie das Renderziel (in diesem Fall Bildschirm), das als Datenparameter übergeben wird (dieser muss von einem uintptr_t in einen screen_window_t umgewandelt werden). Dann sind SCREEN_PROPERTY_POINTER und SCREEN_PROPERTY_STRIDE des Puffers (siehe hier) sollte auf die Daten bzw. den Schritt des Bildes gesetzt werden (der img_t-Parameter des Rückrufs). Der letzte Schritt besteht darin, screen_post_window() zu verwenden (da das Renderziel ein Fenster ist), um das neu geladene Bild auf dem Bildschirm zu rendern.

Arbeiten mit dem QNX Event System

Da der Bootscreen im Wesentlichen eine Endlosschleife ist, die eine Animation immer wieder anzeigen kann, muss der Bootscreen schließlich wissen, wann er beendet werden muss. Hier wird es wichtig, den Kontexttyp auf SCREEN_WINDOW_MANAGER_CONTEXT festzulegen. QNX hat eine Ereignissystem Hier werden Ereignisse generiert, wenn neue Fenster erstellt, zerstört, fokussiert usw. werden. Eine vollständige Liste der Ereignisse finden Sie hier hier. Durch die Verwendung von SCREEN_WINDOW_MANAGER_CONTEXT kann der Bootscreen auf Fenstererstellungs- und Fensterfokussierungsereignisse warten, die von anderen Anwendungen generiert werden.

Zwei wichtige Ereignisse für den Bootscreen sind die Ereignisse SCREEN_EVENT_CREATE und SCREEN_EVENT_PROPERTY. Das SCREEN_EVENT_CREATE-Ereignis wird verwendet, um darauf zu warten, wann die Hauptanwendung (die die Hauptbenutzeroberfläche des Geräts anzeigen würde) das Fenster erstellt und daher der Startbildschirm seine Abschaltsequenz starten soll. Weitere Eigenschaften zu diesem Ereignis können mithilfe des Funktionssatzes screen_get_event_property_X() abgefragt werden. X wird verwendet, um den Typ der abgefragten Eigenschaft anzugeben. Wenn die Hauptanwendung die SCREEN_PROPERTY_GROUP definiert, kann sie abgefragt werden, um herauszufinden, ob die spezifische Anwendung das Ereignis ausgelöst hat.

Das Ereignis SCREEN_EVENT_PROPERTY kann in Verbindung mit der Eigenschaft SCREEN_PROPERTY_FOCUS verwendet werden, die gesetzt wird, wenn ein anderes Fenster den Fokus erhält (weitere Informationen finden Sie hier). hier). Die Verwendung des Ereignissystems anstelle einer Animation mit einer Länge von X Sekunden (wobei X die Länge des Startvorgangs des Geräts ist) bedeutet, dass die Animation in einer Schleife ausgeführt werden kann, wenn die Hauptanwendung noch nicht gestartet wurde. Dies ermöglicht eine viel bessere Portabilität zwischen unterschiedlicher Hardware, da die Timings höchstwahrscheinlich unterschiedlich sein werden.

Was das Timing angeht, muss eine andere Taktik angewendet werden, da die Ereignisse nicht kontinuierlich überwacht werden können (wenn dies der Fall wäre, würde der Hauptthread blockiert werden, was dazu führen würde, dass die Animation keine nachfolgenden Frames anzeigt). Wenn der Startbildschirm ein Standbild ist, stellt dies kein Problem dar. Abhängig von der Länge der Animation müssen diese Ereignisse jedoch möglicherweise etwa bei jedem Viertelsatz von Frames abgehört werden. Das heißt, jedes Mal, wenn ein Viertel der Frames der Animation geladen wird, prüfen Sie, ob mögliche Ereignisse vorliegen, bevor das nächste Viertel geladen wird.

Fazit

Abschließend erklärt dieser Blog, warum Bootscreens wichtig sind, liefert Details zum Einrichten eines Bootscreens für medizinische Geräte für QNX und bietet Vorbehalte und Designvorschläge, die nützlich sein können. Allerdings gelten für den Bootbildschirm jedes Geräts unterschiedliche Anforderungen. Daher bietet dieser Blog Vorschläge anstelle eines schrittweisen Prozesses. Diese Vorschläge und Details sollten es Entwicklern jedoch ermöglichen, einen QNX-Bootscreen für medizinische Geräte einzurichten, der ihren spezifischen Anforderungen entspricht.

Dendy Addison ist ein Software IngenieurIn bei Starfish Medical, der Kunden bei der Entwicklung sicherer, effizienter und effektiver Software für medizinische Geräte unterstützt. Er hat eine Leidenschaft dafür, durch die von ihm entwickelte Software einen Unterschied im Leben der Menschen zu machen. Dendy arbeitet gerne an allen Aspekten medizinischer Geräte, von der Firmware bis zur Benutzeroberfläche.

 

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• PlatoData.Network Vertikale generative KI. Motiviere dich selbst. Hier zugreifen.
• PlatoAiStream. Web3-Intelligenz. Wissen verstärkt. Hier zugreifen.
• PlatoESG. Kohlenstoff, CleanTech, Energie, Umwelt, Solar, Abfallwirtschaft. Hier zugreifen.
• PlatoHealth. Informationen zu Biotechnologie und klinischen Studien. Hier zugreifen.
• Quelle: https://starfishmedical.com/blog/creating-a-medical-device-bootscreen-for-qnx/