A legtöbb, ha nem az összes főbb eszköz (beleértve az orvosi eszközöket is) világszerte rendelkezik valamilyen rendszerindító képernyővel. Ez a gyakran mutatós, de néha egyszerű animáció két célt szolgál. Az egyik egyszerűen az, hogy jól néz ki, ráadásul a cégek személyre szabhatják és hozzáadhatják a márkáját. De a második ok vitathatatlanul fontosabb; tudatja a felhasználóval, hogy az eszköz működik, és jelenleg még az indítási fázisban van.
Ez a blog nagyon technikai lesz, mivel leírja, hogyan kell megtervezni és létrehozni egy indítóképernyőt.
A blog különösen a POSIX-kompatibilis QNX operációs rendszer (OS) rendszerindító képernyőjének tervezésével járó buktatók és bonyodalmak kezelésére oszt meg tippeket. QNX egy mikro-kernel operációs rendszer, amelyet beágyazott rendszereken és pontosabban a biztonság szempontjából kritikus hardvereken való futtatásra terveztek. A technikai részletek megkönnyítése érdekében a QNX dokumentációra való hivatkozások a további tisztázás érdekében.
A QNX meghatározása az operációs rendszer összeállítási fájljában
A rendszerindító képernyő tervezésének első lépése a QNX beállítása annak biztosítására, hogy a rendszerindító képernyő a lehető legkorábbi időpontban jelenjen meg a rendszerindítási sorrendben. A QNX használatához a fejlesztőnek meg kell határoznia egy OS build fájl amely lényegében leírja, hogy mely illesztőprogramokat, alkalmazásokat és egyéb idegen fájlokat kell tartalmaznia az operációs rendszer lemezképében. Ezt az operációs rendszer lemezképet ezután a rendszer a célrendszerre küldi, és szabályozza, hogy mely alkalmazások és illesztőprogramok induljanak el rendszerindításkor. A QNX grafikus rendszere a Képernyő alrendszer. A kép a hardverhez csatlakoztatott speciális kijelzőn való megjelenítésére szolgál. Ezt a lehető leghamarabb el kell kezdeni a rendszerindítási folyamat során. A rendszerindítási szekvencia a build fájlban szkriptcímkeként van definiálva, amely így fog kinézni:
[+script] .script={}
a kapcsos zárójelek belsejében meghatározott sorokkal, amelyek shell-szkriptként működnek. Itt kell elindítani a Képernyő alrendszert.
A Képernyő alrendszer indítására szolgáló parancs így fog kinézni:
képernyő -c {config_file_útvonala}.
További információ található itt. A Képernyő alrendszer elindítása után a rendszerindító képernyő bináris fájl elindítható.
Munka a képernyőrendszerrel
A következő lépés maga a rendszerindító képernyő fejlesztése. A QNX-nek nincs natív módja a kép vagy animáció megjelenítésére a rendszerindítási szekvencia részeként. Ezt eszközönként kell fejleszteni. Mivel a Screen API C-ben van írva, a rendszerindító képernyőt is C-ben kell írni. Ezenkívül a C használata biztosítja, hogy a rendszerindító képernyő sokkal gyorsabban indítható el, és így csökkenjen az idő, amíg a felhasználót tájékoztatni kell az eszköz működéséről. A rendszerindító képernyőnek be kell állítania néhány alapkódot a Screen API-val való kommunikációhoz. A konkrétumok megtalálhatók itt de ezek felsorolásához a rendszerindító képernyőnek létre kell hoznia egy kontextusobjektumot, egy renderelési célobjektumot (ebben az esetben a renderelési cél egy ablakcél), és végül egy képernyőpuffer objektumot. Technikailag, mivel a C nem objektum-orientált, az objektumok fogalma nem létezik a nyelvben. De a könnyebb magyarázat kedvéért az objektumok kifejezést használjuk a használt struktúrák típusainak leírására.
Íme az imént definiált objektumok néhány konkrét paraméterére vonatkozó magyarázatok és mutatók. A rendszerindító képernyő képernyőkörnyezet-objektumának létrehozásakor a SCREEN_APPLICATION_CONTEXT típus nem elegendő. Ehelyett a rendszerindító képernyőnek a SCREEN_WINDOW_MANAGER_CONTEXT-ra van szüksége. Az okot később részletesen elmagyarázzuk, de ez alapvetően ahhoz kapcsolódik, hogy tudjuk, mikor kell leállnia a rendszerindító képernyőnek. További információ az itt.
Ezután a renderelési cél, jelen esetben az ablak használati tulajdonságának meghatározásakor ezt legalább a SCREEN_USAGE_WRITE értékre kell állítani, mivel a rendszerindító képernyő a renderelési pufferbe kíván írni, de nem feltétlenül kell olvasnia onnan. Az alapértelmezett az írási és olvasási jelzők kombinációja. További információ az itt.
Végül, a renderelési cél által használandó pufferek ideális száma beállítható egy vagy kettőre a használt rendszerindító képernyő típusától függően. Ha az eszköznek statikus rendszerindító képernyője lesz, amely egyetlen képet alkot, akkor 1 pufferre van szükség. Ha azonban animációt fog mutatni, akkor kettő ajánlott. Ha kettőt használ egy ablak renderelési céljával együtt, akkor a rendszerindító képernyő duplán pufferelt lesz. Más szóval, miközben az animáció egyik képkockája az egyik pufferbe töltődik, a Képernyő alrendszer megjelenítheti a másik puffert. Majd amikor a puffer betöltése befejeződött, a Képernyő alrendszer lecseréli az aktív puffert az újra.
Munka a képtárral
Most egy második QNX könyvtárat kell használni a rendszerindító kép vagy animáció meghatározott képkockáinak elemzéséhez és betöltéséhez. A Képernyő alrendszer ezt nem kezeli. Ehelyett a Képtár használt. A rendszerindító képernyőhöz használt képfájl típusától függően különböző Codec Shared Object (.so) fájlokra lesz szükség. Ezek szerepelnének az operációs rendszer image build fájljában, és az elérhetők listája is megtalálható itt. Lépések sorozatát kell végrehajtani annak érdekében, hogy egy animáció keretét egy csatolt képernyőn jelenítse meg.
Ezek a lépések meghatározottak itt néhány figyelmeztetéssel. Az egyik fontos figyelmeztetés az a lehetőség, hogy a használt hardvertől függően az animáció teljes képkockája nem fér el a memóriában. Ha ez a helyzet, akkor a képkockákat menet közben kell betölteni, és betöltésükkor kell renderelni. A második figyelmeztetés az, hogy az img_load_file() és az img_load() is (mindkettőre hivatkozik a fenti hivatkozás) csak az első keretet tölti be. Állóképhez ez elegendő, animációhoz viszont nem. Ezeknek a függvényeknek a ciklusban történő használata az egyes keretekben történő beolvasáshoz sem fog működni, mert nincs mód a lekérni kívánt keretszám megadására. Mindig az első képkockát adja vissza.
Ehelyett mindkét figyelmeztetés kiküszöbölése érdekében a kód betölti és dekódolja a keretet, majd a dekódolási visszahívás során beírja az animációs keretet a Képernyő alrendszer pufferébe. Az img_decode_frame() függvény lehetővé teszi a visszahívások meghatározását, és kifejezetten a frame_f() visszahívásban van (lásd itt), hogy a kép pufferbe való betöltéséhez szükséges kódot el kell helyezni.
Az adatok betöltésének lépései a következők: Bontsa ki a renderelési célt (ebben az esetben a képernyőt), amely adatparaméterként kerül átadásra (ezt az uintptr_t-ből át kell adni a screen_window_t-be). Ezután a puffer SCREEN_PROPERTY_POINTER és SCREEN_PROPERTY_STRIDE pontja (lásd itt) értéket a kép adataira és lépésre kell állítani (a visszahívás img_t paramétere). Az utolsó lépés a screen_post_window() használata (mivel a renderelési cél egy ablak) az újonnan betöltött kép megjelenítéséhez a képernyőn.
Munka a QNX eseményrendszerrel
Végül, mivel a rendszerindító képernyő lényegében egy végtelen ciklus, amely újra és újra megjeleníthet egy animációt, a rendszerindító képernyőnek tudnia kell, mikor kell befejezni. Itt válik fontossá a kontextustípus SCREEN_WINDOW_MANAGER_CONTEXT beállítása. A QNX-nek van egy Rendezvényrendszer ahol események generálódnak, ha új ablakokat hoznak létre, megsemmisítenek, fókuszba helyezik stb. Az események teljes listája itt található itt. A SCREEN_WINDOW_MANAGER_CONTEXT használatával a rendszerindító képernyő figyeli a más alkalmazások által generált ablaklétrehozási és -fókuszálási eseményeket.
A rendszerindító képernyő két fontos eseménye a SCREEN_EVENT_CREATE és a SCREEN_EVENT_PROPERTY esemény. A SCREEN_EVENT_CREATE esemény arra szolgál, hogy figyeljen arra, hogy a fő alkalmazás (amely az eszköz fő felhasználói felületét jelenítse meg) mikor hozza létre az ablakot, és ezért mikor kell a rendszerindító képernyőnek elindítania a leállási sorozatát. További tulajdonságok kérdezhetők le erről az eseményről a screen_get_event_property_X() függvénykészlet használatával. Az X a lekérdezett tulajdonság típusának jelölésére szolgál. Ha a fő alkalmazás definiálja a SCREEN_PROPERTY_GROUP-ot, akkor lekérdezhető, hogy megtudja, az adott alkalmazás indította-e el az eseményt.
A SCREEN_EVENT_PROPERTY esemény a SCREEN_PROPERTY_FOCUS tulajdonsággal együtt használható, amely akkor van beállítva, ha egy másik ablak kerül fókuszba (további információ itt). Az eseményrendszer használata X másodperces animáció helyett (ahol X az eszköz rendszerindítási folyamatának hossza) azt jelenti, hogy az animáció hurkolható, ha a fő alkalmazás még nem indult el. Ez sokkal jobb hordozhatóságot tesz lehetővé a különböző hardverek között, mivel az időzítések valószínűleg eltérőek lesznek.
Ami az időzítést illeti, mivel az eseményeket nem lehet folyamatosan hallgatni (ha így lenne, akkor a főszálat lezárnák, ami miatt az animáció nem jeleníti meg a következő képkockákat), más taktikát kell alkalmazni. Ha a rendszerindító képernyő állókép, ez nem jelent problémát. Az animáció hosszától függően azonban előfordulhat, hogy ezeket az eseményeket körülbelül minden negyed képkockán keresztül meg kell hallgatni. Ez azt jelenti, hogy minden alkalommal, amikor az animáció képkockáinak negyede betöltődik, mielőtt a következő negyed betöltődik, ellenőrizze az esetleges eseményeket.
Következtetés
Összefoglalva, ez a blog elmagyarázza, miért fontosak a rendszerindító képernyők, részleteket ad az orvosi eszköz indítóképernyőjének beállításáról a QNX számára, valamint figyelmeztetéseket és tervezési javaslatokat kínál, amelyek hasznosak lehetnek. Azonban minden eszköz indítóképernyőjének más-más követelményei vannak. Ennek eredményeként ez a blog javaslatokat ad a lépésről lépésre történő folyamat helyett. Ezeknek a javaslatoknak és részleteknek azonban lehetővé kell tenniük a fejlesztők számára, hogy speciális igényeiknek megfelelő QNX rendszerindító képernyőt állítsanak be az orvosi eszközön.
Dendy Addison a Software Engineer a Starfish Medicalnál, aki segít az ügyfeleknek biztonságos, hatékony és hatékony orvosi eszközök szoftverének kifejlesztésében. Szenvedélye, hogy az általa kifejlesztett szoftverekkel változást hozzon az emberek életébe. Dendy szívesen dolgozik az orvosi eszközök minden területén, a firmware-től a felhasználói felületig.
- SEO által támogatott tartalom és PR terjesztés. Erősödjön még ma.
- PlatoData.Network Vertical Generative Ai. Erősítse meg magát. Hozzáférés itt.
- PlatoAiStream. Web3 Intelligence. Felerősített tudás. Hozzáférés itt.
- PlatoESG. Carbon, CleanTech, Energia, Környezet, Nap, Hulladékgazdálkodás. Hozzáférés itt.
- PlatoHealth. Biotechnológiai és klinikai vizsgálatok intelligencia. Hozzáférés itt.
- Forrás: https://starfishmedical.com/blog/creating-a-medical-device-bootscreen-for-qnx/
