De flesta om inte alla större enheter (inklusive medicinsk utrustning) i hela världen har någon form av startskärm. Denna ofta flashiga men ibland enkla animation har två syften. En är helt enkelt att det ser bra ut, plus att företag kan anpassa och lägga till sitt varumärke till det. Men det andra skälet är utan tvekan viktigare; den låter användaren veta att enheten fungerar och för närvarande fortfarande är i uppstartsfasen.

Den här bloggen kommer att bli väldigt teknisk eftersom den beskriver hur man designar och skapar en startskärm.

I synnerhet delar bloggen tips för att ta itu med de fallgropar och komplikationer som kommer med att designa en startskärm för det POSIX-kompatibla operativsystemet (OS), QNX. QNX är ett mikrokärnoperativsystem designat för att köras på inbyggda system och mer specifikt säkerhetskritisk hårdvara. För att hjälpa till med de tekniska detaljerna finns hänvisningar till QNX-dokumentationen genomgående för ytterligare förtydligande.

Definiera QNX OS Build-filen

Det första steget för att designa en startskärm är att ställa in QNX för att säkerställa att startskärmen kommer att visas så tidigt som möjligt i startsekvensen. För att använda QNX måste en utvecklare definiera en OS byggfil som i huvudsak kommer att beskriva vilka drivrutiner, applikationer och andra främmande filer som måste inkluderas i OS-avbildningen. Denna OS-avbildning kommer sedan att blinka till målsystemet och styra vilka applikationer och drivrutiner som startas vid uppstart. QNX har ett grafiksystem som kallas Skärmdelsystem. Den kommer att användas för att återge bilden på en specifik skärm kopplad till hårdvaran. Detta bör startas så snart som möjligt under uppstartssekvensen. Startsekvensen definieras i byggfilen som en skripttagg som kommer att se ut så här:

[+script] .script={}

med alla definierade linjer inuti hängslen som fungerar som ett skalskript. Det är här som undersystemet Screen ska startas.

Kommandot för att starta undersystemet Skärm kommer att se ut så här:

skärm -c {path_to_config_file}.

Mer information finns här.. När undersystemet Screen har startats kan bootscreen-binären sedan startas.

Arbeta med skärmsystemet

Nästa steg är att utveckla själva startskärmen. QNX har inget inbyggt sätt att visa en bild eller animation som en del av startsekvensen. Detta kommer att behöva utvecklas på en enhetsbasis. Eftersom Screen API är skrivet i C, bör startskärmen också skrivas i C. Dessutom kommer användningen av C att säkerställa att startskärmen kan startas mycket snabbare och därmed minska tiden för att informera användaren om enhetens funktion. Startskärmen måste ställa in en kod för att kommunicera med Screen API. Specifikationer kan hittas här. men för att lista ut dem måste startskärmen skapa ett kontextobjekt, ett rendermålobjekt (i det här fallet är renderingsmålet som behövs ett fönstermål) och slutligen ett skärmbuffertobjekt. Tekniskt sett, eftersom C inte är objektorienterat, existerar inte begreppet objekt i språket. Men för att underlätta förklaringen kommer termen objekt att användas för att beskriva de typer av strukturer som används.

Här är förtydliganden och tips om några specifika parametrar för de objekt som just definierats. När du skapar skärmkontextobjektet för startskärmen är typen SCREEN_APPLICATION_CONTEXT otillräcklig. Istället behöver startskärmen SCREEN_WINDOW_MANAGER_CONTEXT. Orsaken kommer att förklaras fullständigt senare, men det har i huvudsak att göra med att veta när startskärmen måste avslutas. Mer information är här..

Därefter, när du definierar användningsegenskapen för rendermålet, i det här fallet fönstret, bör detta åtminstone ställas in på SCREEN_USAGE_WRITE eftersom startskärmen avser att skriva till renderingsbufferten men inte nödvändigtvis behöver läsa från den. Standard är en kombination av skriv- och läsflaggor. Mer information är här..

Slutligen kan det ideala antalet buffertar som ska användas av renderingsmålet ställas in på en eller två beroende på vilken typ av startskärm som används. Om enheten ska ha en statisk startskärm, som kommer att utgöra en enda bild, så är 1 buffert allt som behövs. Men om den ska visa en animation rekommenderas två. Genom att använda två i kombination med ett renderingsmål för ett fönster kommer startskärmen att dubbelbuffras. Med andra ord, medan en bildruta av animationen laddas in i en buffert kan undersystemet Screen visa den andra bufferten. Sedan när bufferten är klar med att laddas in, kommer Screen-undersystemet att byta ut den aktiva bufferten till den nya.

Arbeta med bildbiblioteket

Nu måste ett andra QNX-bibliotek användas för att analysera och ladda specifika ramar av startskärmsbilden eller animeringen. Delsystemet Screen hanterar inte detta. Istället Bildbibliotek är använd. Beroende på vilken typ av bildfil som kommer att användas för startskärmen, kommer olika codec Shared Object (.so)-filer att behövas. Dessa skulle inkluderas i OS-bildbyggnadsfilen och en lista över tillgängliga är här.. En sekvens av steg måste göras för att rendera en ram av en animation till en bifogad skärm.

Dessa steg är definierade här. med några varningar. En viktig varning är möjligheten att, beroende på vilken hårdvara som används, kommer hela uppsättningen av ramar i en animation inte att passa in i minnet. Om så är fallet skulle ramarna behöva laddas i farten och renderas när de laddas. Den andra varningen är att både img_load_file() och img_load() (båda refererade i länken ovan) bara kommer att ladda den första ramen. För en stillbild räcker detta, men inte för en animering. Att använda dessa funktioner i en slinga för att läsa i varje bildruta kommer inte heller att fungera eftersom det inte finns något sätt att ange ramnumret som ska hämtas. Den kommer alltid att returnera den första bilden.

Istället, för att ta itu med båda förbehållen, kommer koden att ladda och avkoda ramen, och sedan i avkodningsåteruppringningen skriver animeringsramen in i Skärmundersystemsbufferten. Img_decode_frame()-funktionen tillåter att återuppringningar definieras och den är specifikt i frame_f()-återuppringningen (se här.) att koden för att ladda bilden i bufferten ska läggas.

Stegen för att ladda data är som följer: Extrahera renderingsmålet (skärm i det här fallet) som skickas in som dataparameter (detta kommer att behöva typcast från en uintptr_t till en screen_window_t). Sedan buffertens SCREEN_PROPERTY_POINTER och SCREEN_PROPERTY_STRIDE (se här.) bör ställas in på bildens data respektive stride (img_t-parametern för återuppringningen). Det sista steget är att använda screen_post_window() (på grund av att renderingsmålet är ett fönster) för att rendera den nyligen laddade bilden till skärmen.

Arbeta med QNX Event System

Slutligen, eftersom startskärmen i huvudsak är en oändlig loop som kan visa en animation om och om igen, måste startskärmen veta när den ska avslutas. Det är här det är viktigt att ställa in kontexttypen till SCREEN_WINDOW_MANAGER_CONTEXT. QNX har en Eventsystem där händelser genereras om nya fönster skapas, förstörs, ges fokus, etc. En fullständig lista över händelser är här.. Genom att använda SCREEN_WINDOW_MANAGER_CONTEXT kan startskärmen lyssna efter fönsterskapande och fönsterfokushändelser som genereras av andra applikationer.

Två viktiga händelser för startskärmen är händelserna SCREEN_EVENT_CREATE och SCREEN_EVENT_PROPERTY. Händelsen SCREEN_EVENT_CREATE används för att lyssna efter när huvudapplikationen (som skulle visa enhetens huvudanvändargränssnitt) skapar fönstret och därför när startskärmen ska starta sin avstängningssekvens. Ytterligare egenskaper kan frågas om denna händelse genom att använda uppsättningen screen_get_event_property_X() funktioner. X används för att beteckna typen av den efterfrågade egenskapen. Om huvudapplikationen definierar SCREEN_PROPERTY_GROUP, kan den frågas för att ta reda på om den specifika applikationen aktiverade händelsen.

Händelsen SCREEN_EVENT_PROPERTY kan användas tillsammans med egenskapen SCREEN_PROPERTY_FOCUS som ställs in när ett annat fönster tar fokus (läs mer information här.). Att använda händelsesystemet istället för att använda en animation som är X sekunder lång (där X är längden på enhetens startprocess) innebär att animeringen kan loopas om huvudapplikationen inte har startats ännu. Detta möjliggör mycket bättre portabilitet mellan olika hårdvara eftersom tidpunkterna med största sannolikhet kommer att vara olika.

När det gäller timing, eftersom händelserna inte kan lyssnas på kontinuerligt (om de vore det skulle det låsa huvudtråden och göra att animeringen inte visar efterföljande bildrutor), måste en annan taktik användas. Om startskärmen är en stillbild kommer detta inte att vara ett problem. Men beroende på längden på animeringen kan dessa händelser behöva lyssnas ungefär var fjärde uppsättning bildrutor. Det vill säga, varje gång en fjärdedel av animationens ramar laddas, innan nästa fjärdedel börjar laddas, kontrollera om det finns eventuella händelser.

Slutsats

Sammanfattningsvis förklarar den här bloggen varför startskärmar är viktiga, ger detaljer om hur man ställer in en startskärm för medicinsk utrustning för QNX, och erbjuder varningar och designförslag som kan vara användbara. Men varje enhets startskärm har olika krav. Som ett resultat ger den här bloggen förslag istället för en steg-för-steg-process. Dessa förslag och detaljer bör dock göra det möjligt för utvecklare att konfigurera en QNX-startskärm för medicinsk utrustning som uppfyller deras specifika behov.

Dendy Addison är en Programvara ingenjör på Starfish Medical som hjälper kunder att utveckla säker, effektiv och effektiv programvara för medicinsk utrustning. Han har en passion för att göra skillnad i människors liv genom mjukvaran han utvecklar. Dendy tycker om att arbeta med alla aspekter av medicinsk utrustning från firmware till UI.

 

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
• PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
• Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
• PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
• Källa: https://starfishmedical.com/blog/creating-a-medical-device-bootscreen-for-qnx/