De meeste, zo niet alle grote apparaten (inclusief medische apparaten) over de hele wereld hebben een of andere vorm van een opstartscherm. Deze vaak flitsende maar soms eenvoudige animatie heeft twee doelen. De eerste is simpelweg dat het er goed uitziet, en dat bedrijven het kunnen personaliseren en er hun branding aan kunnen toevoegen. Maar de tweede reden is misschien wel belangrijker; het laat de gebruiker weten dat het apparaat werkt en zich momenteel nog in de opstartfase bevindt.

Deze blog wordt erg technisch omdat het beschrijft hoe je een opstartscherm ontwerpt en maakt.

In het bijzonder deelt de blog tips om de valkuilen en complicaties aan te pakken die gepaard gaan met het ontwerpen van een opstartscherm voor het POSIX-compatibele besturingssysteem (OS), QNX. QNX is een microkernel-besturingssysteem dat is ontworpen om te worden uitgevoerd op ingebedde systemen en meer specifiek op veiligheidskritische hardware. Om te helpen met de technische details zijn overal verwijzingen naar QNX-documentatie opgenomen voor verdere verduidelijking.

QNX definiëren als het OS-buildbestand

De eerste stap bij het ontwerpen van een opstartscherm is het instellen van QNX om ervoor te zorgen dat het opstartscherm zo vroeg mogelijk in de opstartvolgorde wordt weergegeven. Om QNX te gebruiken, moet een ontwikkelaar een OS-buildbestand dat beschrijft in wezen welke stuurprogramma's, applicaties en andere externe bestanden in de OS-image moeten worden opgenomen. Deze OS-image wordt vervolgens naar het doelsysteem geflasht en bepaalt welke applicaties en stuurprogramma's bij het opstarten worden gestart. QNX heeft een grafisch systeem dat bekend staat als de Schermsubsysteem. Het wordt gebruikt om de afbeelding weer te geven op een specifiek scherm dat op de hardware is aangesloten. Dit moet zo snel mogelijk tijdens het opstarten worden gestart. De opstartvolgorde wordt in het buildbestand gedefinieerd als een scripttag die er als volgt uitziet:

[+script] .script={}

waarbij alle gedefinieerde lijnen binnen de accolades fungeren als een shellscript. Dit is waar het Screen-subsysteem moet worden gestart.

De opdracht om het Screen-subsysteem te starten ziet er als volgt uit:

scherm -c {path_to_config_file}.

Meer informatie is te vinden hier. Zodra het Screen-subsysteem is gestart, kan vervolgens het binaire bestand bootscreen worden gestart.

Werken met het schermsysteem

De volgende stap is het ontwikkelen van het opstartscherm zelf. QNX heeft geen eigen manier om een ​​afbeelding of animatie weer te geven als onderdeel van de opstartvolgorde. Dit zal per apparaat moeten worden ontwikkeld. Omdat de Screen API in C is geschreven, moet het opstartscherm ook in C worden geschreven. Bovendien zorgt het gebruik van C ervoor dat het opstartscherm veel sneller kan worden gestart, waardoor de tijd wordt verkort om de gebruiker op de hoogte te stellen van de werking van het apparaat. Het opstartscherm moet een standaardcode instellen om te communiceren met de Screen API. Bijzonderheden zijn te vinden hier maar om ze op te sommen, zal het opstartscherm een ​​contextobject moeten maken, een renderdoelobject (in dit geval is het benodigde renderdoel een vensterdoel) en ten slotte een schermbufferobject. Technisch gezien bestaat het concept van objecten niet in de taal, aangezien C niet objectgeoriënteerd is. Maar voor het gemak van de uitleg zal de term objecten worden gebruikt om de gebruikte typen structuren te beschrijven.

Hier vindt u verduidelijking en aanwijzingen met betrekking tot enkele specifieke parameters voor de objecten die zojuist zijn gedefinieerd. Bij het maken van het schermcontextobject voor het opstartscherm is het type SCREEN_APPLICATION_CONTEXT onvoldoende. In plaats daarvan heeft het opstartscherm de SCREEN_WINDOW_MANAGER_CONTEXT nodig. De reden zal later volledig worden uitgelegd, maar heeft in wezen te maken met weten wanneer het opstartscherm moet worden beëindigd. Meer informatie is hier.

Vervolgens moet bij het definiëren van de gebruikseigenschap van het renderdoel, in dit geval het venster, deze op zijn minst worden ingesteld op SCREEN_USAGE_WRITE, omdat het opstartscherm naar de renderbuffer wil schrijven, maar er niet noodzakelijkerwijs uit hoeft te lezen. De standaardinstelling is een combinatie van de schrijf- en leesvlaggen. Meer informatie is hier.

Ten slotte kan het ideale aantal buffers dat door het renderdoel moet worden gebruikt, worden ingesteld op één of twee, afhankelijk van het gebruikte type opstartscherm. Als het apparaat een statisch opstartscherm krijgt, dat één enkele afbeelding zal vormen, dan is 1 buffer alles wat nodig is. Als er echter een animatie wordt weergegeven, worden er twee aanbevolen. Door er twee te gebruiken in combinatie met een renderdoel van een venster, kan het opstartscherm dubbel gebufferd worden. Met andere woorden, terwijl één frame van de animatie in één buffer wordt geladen, kan het Screen-subsysteem de andere buffer tonen. Wanneer het laden van de buffer voltooid is, zal het Screen-subsysteem de actieve buffer omwisselen naar de nieuwe.

Werken met de beeldbibliotheek

Nu moet een tweede QNX-bibliotheek worden gebruikt om specifieke frames van de opstartschermafbeelding of -animatie te ontleden en te laden. Het Screen-subsysteem verwerkt dit niet. In plaats daarvan, de Afbeeldingenbibliotheek is gebruikt. Afhankelijk van het type afbeeldingsbestand dat voor het opstartscherm wordt gebruikt, zijn verschillende codec Shared Object (.so)-bestanden nodig. Deze zouden worden opgenomen in het OS-image-buildbestand en er wordt een lijst met beschikbare versies weergegeven hier. Er moet een reeks stappen worden uitgevoerd om een ​​frame van een animatie op een bijgevoegd scherm weer te geven.

Deze stappen zijn gedefinieerd hier met een paar kanttekeningen. Een belangrijk voorbehoud is de mogelijkheid dat, afhankelijk van de gebruikte hardware, de hele set frames van een animatie niet in het geheugen past. Als dit het geval is, moeten de frames direct worden geladen en weergegeven terwijl ze worden geladen. Het tweede voorbehoud is dat zowel img_load_file() als img_load() (beide waarnaar wordt verwezen in de bovenstaande link) alleen het eerste frame laden. Voor een stilstaand beeld is dit voldoende, maar voor een animatie niet. Het gebruik van deze functies in een lus om elk frame in te lezen zal ook niet werken, omdat er geen manier is om het framenummer op te geven dat moet worden opgehaald. Er wordt altijd het eerste frame geretourneerd.

Om beide kanttekeningen te plaatsen, zal de code in plaats daarvan het frame laden en decoderen, en vervolgens in de decodeer-callback het animatieframe naar de schermsubsysteembuffer schrijven. Met de functie img_decode_frame() kunnen callbacks worden gedefinieerd en deze bevindt zich specifiek in de frame_f() callback (zie hier) dat de code om de afbeelding in de buffer te laden moet worden geplaatst.

De stappen om de gegevens te laden zijn als volgt: Extraheer het renderdoel (scherm in dit geval) dat wordt doorgegeven als de gegevensparameter (dit moet worden getypeerd van een uintptr_t naar een screen_window_t). Vervolgens de buffer SCREEN_PROPERTY_POINTER en SCREEN_PROPERTY_STRIDE (zie hier) moet respectievelijk worden ingesteld op de gegevens en stride van de afbeelding (de parameter img_t van de callback). De laatste stap is het gebruik van screen_post_window() (omdat het renderdoel een venster is) om de nieuw geladen afbeelding op het scherm weer te geven.

Werken met het QNX-evenementsysteem

Tenslotte, omdat het opstartscherm in wezen een oneindige lus is die keer op keer een animatie kan weergeven, moet het opstartscherm weten wanneer het moet eindigen. Dit is waar het instellen van het contexttype op SCREEN_WINDOW_MANAGER_CONTEXT belangrijk wordt. QNX heeft een Evenementen systeem waar gebeurtenissen worden gegenereerd als er nieuwe vensters worden gemaakt, vernietigd, focus krijgen, enz. Een volledige lijst met gebeurtenissen is hier. Door SCREEN_WINDOW_MANAGER_CONTEXT te gebruiken, kan het opstartscherm luisteren naar gebeurtenissen voor het maken van vensters en het focussen van vensters die door andere toepassingen worden gegenereerd.

Twee belangrijke gebeurtenissen voor het opstartscherm zijn de SCREEN_EVENT_CREATE en de SCREEN_EVENT_PROPERTY gebeurtenissen. De gebeurtenis SCREEN_EVENT_CREATE wordt gebruikt om te luisteren wanneer de hoofdtoepassing (die de hoofdgebruikersinterface van het apparaat toont) het venster aanmaakt en dus wanneer het opstartscherm moet beginnen met afsluiten. Verdere eigenschappen kunnen over deze gebeurtenis worden opgevraagd door gebruik te maken van de set functies screen_get_event_property_X(). X wordt gebruikt om het type van de opgevraagde eigenschap aan te duiden. Als de hoofdtoepassing de SCREEN_PROPERTY_GROUP definieert, kan er een query worden uitgevoerd om erachter te komen of de specifieke toepassing de gebeurtenis heeft geactiveerd.

De SCREEN_EVENT_PROPERTY gebeurtenis kan worden gebruikt in combinatie met de SCREEN_PROPERTY_FOCUS eigenschap die wordt ingesteld wanneer een ander venster de focus krijgt (lees meer informatie hier). Het gebruik van het gebeurtenissysteem in plaats van een animatie van X seconden lang (waarbij X de lengte is van het opstartproces van het apparaat) betekent dat de animatie kan worden herhaald als de hoofdtoepassing nog niet is gestart. Dit zorgt voor een veel betere draagbaarheid tussen verschillende hardware, aangezien de timing hoogstwaarschijnlijk anders zal zijn.

Wat betreft timing: omdat de gebeurtenissen niet continu kunnen worden beluisterd (als dat wel het geval zou zijn, zou de rode draad vastlopen waardoor de animatie geen volgende frames laat zien), moet een andere tactiek worden toegepast. Als het opstartscherm een ​​stilstaand frame is, is dit geen probleem. Afhankelijk van de lengte van de animatie moeten deze gebeurtenissen echter mogelijk voor ongeveer elke kwart set frames worden beluisterd. Dat wil zeggen: elke keer dat een kwart van de animatieframes wordt geladen, voordat het volgende kwart wordt geladen, controleert u op mogelijke gebeurtenissen.

Conclusie

Concluderend legt deze blog uit waarom opstartschermen belangrijk zijn, geeft details over hoe je een opstartscherm voor medische apparaten voor QNX kunt instellen, en biedt kanttekeningen en ontwerpsuggesties die nuttig kunnen zijn. Het opstartscherm van elk apparaat stelt echter andere eisen. Daarom biedt deze blog suggesties in plaats van een stapsgewijs proces. Deze suggesties en details zouden ontwikkelaars echter in staat moeten stellen een QNX-opstartscherm voor medische apparaten op te zetten dat aan hun specifieke behoeften voldoet.

Dendy Addison is een Software Engineer bij Starfish Medical, die klanten helpt bij het ontwikkelen van veilige, efficiënte en effectieve software voor medische apparatuur. Hij heeft een passie voor het maken van een verschil in het leven van mensen door middel van de software die hij ontwikkelt. Dendy werkt graag aan alle facetten van medische apparaten, van firmware tot gebruikersinterface.

 

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://starfishmedical.com/blog/creating-a-medical-device-bootscreen-for-qnx/