La plupart, sinon tous les principaux appareils (y compris les appareils médicaux) dans le monde disposent d’une forme d’écran de démarrage. Cette animation souvent flashy mais parfois simple remplit deux objectifs. La première est simplement que cela a une belle apparence et que les entreprises peuvent le personnaliser et y ajouter leur image de marque. Mais la deuxième raison est sans doute plus importante ; il permet à l'utilisateur de savoir que l'appareil fonctionne et qu'il est actuellement encore en phase de démarrage.

Ce blog deviendra très technique car il décrit comment concevoir et créer un écran de démarrage.

En particulier, le blog partage des conseils pour résoudre les pièges et les complications liés à la conception d'un écran de démarrage pour le système d'exploitation (OS) compatible POSIX, QNX. QNX est un système d'exploitation à micro-noyau conçu pour être exécuté sur des systèmes embarqués et plus particulièrement sur du matériel critique en matière de sécurité. Pour vous aider avec les détails techniques, des références à la documentation QNX sont incluses partout pour des éclaircissements supplémentaires.

Définir QNX comme fichier de build du système d'exploitation

La première étape pour concevoir un écran de démarrage consiste à configurer QNX pour garantir que l'écran de démarrage s'affichera le plus tôt possible dans la séquence de démarrage. Pour utiliser QNX, un développeur devra définir un Fichier de construction du système d'exploitation qui décrira essentiellement quels pilotes, applications et autres fichiers superflus doivent être inclus dans l'image du système d'exploitation. Cette image du système d'exploitation sera ensuite flashée sur le système cible et contrôlera les applications et les pilotes démarrés au démarrage. QNX dispose d'un système graphique connu sous le nom de Sous-système d'écran. Il sera utilisé pour restituer l'image sur un écran spécifique connecté au matériel. Cela doit être démarré dès que possible pendant la séquence de démarrage. La séquence de démarrage est définie dans le fichier de build sous la forme d'une balise de script qui ressemblera à :

[+script] .script={}

avec toutes les lignes définies à l'intérieur des accolades agissant comme un script shell. C'est ici que le sous-système Screen doit être démarré.

La commande pour démarrer le sous-système Screen ressemblera à :

screen -c {chemin_vers_fichier_config}.

Plus d'informations peuvent être trouvées ici. Une fois le sous-système Screen démarré, le binaire bootscreen peut ensuite être démarré.

Travailler avec le système d'écran

L'étape suivante consiste à développer l'écran de démarrage lui-même. QNX n'a ​​aucun moyen natif d'afficher une image ou une animation dans le cadre de la séquence de démarrage. Cela devra être développé par appareil. Étant donné que l'API Screen est écrite en C, l'écran de démarrage doit également être écrit en C. De plus, l'utilisation de C garantira que l'écran de démarrage pourra être démarré beaucoup plus rapidement et réduira ainsi le temps nécessaire pour informer l'utilisateur du fonctionnement de l'appareil. L'écran de démarrage doit configurer un code passe-partout pour communiquer avec l'API Screen. Des détails peuvent être trouvés ici mais pour les lister, l'écran de démarrage devra créer un objet de contexte, un objet cible de rendu (dans ce cas, la cible de rendu nécessaire est une cible de fenêtre) et enfin un objet tampon d'écran. Techniquement, puisque C n’est pas orienté objet, la notion d’objet n’existe pas dans le langage. Mais pour faciliter l’explication, le terme objets sera utilisé pour décrire les types de structures utilisées.

Voici des éclaircissements et des indications concernant certains paramètres spécifiques aux objets qui viennent d'être définis. Lors de la création de l'objet de contexte d'écran pour l'écran de démarrage, le type SCREEN_APPLICATION_CONTEXT est insuffisant. Au lieu de cela, l'écran de démarrage a besoin du SCREEN_WINDOW_MANAGER_CONTEXT. La raison sera expliquée en détail plus tard, mais elle concerne essentiellement le fait de savoir quand l'écran de démarrage doit se terminer. Plus d'informations sont ici.

Ensuite, lors de la définition de la propriété d'utilisation de la cible de rendu, dans ce cas la fenêtre, celle-ci doit au moins être définie sur SCREEN_USAGE_WRITE car l'écran de démarrage a l'intention d'écrire dans le tampon de rendu mais n'a pas nécessairement besoin d'y lire. La valeur par défaut est une combinaison des indicateurs d'écriture et de lecture. Plus d'informations sont ici.

Enfin, le nombre idéal de tampons à utiliser par la cible de rendu peut être défini sur un ou deux selon le type d'écran de démarrage utilisé. Si le périphérique doit avoir un écran de démarrage statique, qui constituera une seule image, alors 1 tampon suffit. Cependant, s’il doit afficher une animation, deux sont recommandées. En utiliser deux en combinaison avec une cible de rendu d'une fenêtre permettra à l'écran de démarrage d'être doublement tamponné. En d'autres termes, pendant qu'une image de l'animation est chargée dans un tampon, le sous-système Screen peut afficher l'autre tampon. Ensuite, lorsque le chargement du tampon est terminé, le sous-système Screen remplace le tampon actif par le nouveau.

Travailler avec la bibliothèque d'images

Désormais, une deuxième bibliothèque QNX doit être utilisée pour analyser et charger des images spécifiques de l'image ou de l'animation de l'écran de démarrage. Le sous-système Screen ne gère pas cela. Au lieu de cela, le Bibliothèque d'images est utilisé. Selon le type de fichier image qui sera utilisé pour l'écran de démarrage, différents fichiers codec Shared Object (.so) seront nécessaires. Ceux-ci seraient inclus dans le fichier de construction de l'image du système d'exploitation et une liste de ceux disponibles est ici. Une séquence d'étapes doit être effectuée afin de restituer une image d'une animation sur un écran attaché.

Ces étapes sont définies ici avec quelques mises en garde. Une mise en garde importante concerne la possibilité qu'en fonction du matériel utilisé, l'ensemble des images d'une animation ne rentre pas dans la mémoire. Si tel est le cas, les images devront être chargées à la volée et rendues au fur et à mesure de leur chargement. La deuxième mise en garde est que img_load_file() et img_load() (tous deux référencés dans le lien ci-dessus) ne chargeront que la première image. Pour une image fixe, cela suffit, mais pas pour une animation. Utiliser ces fonctions dans une boucle pour lire dans chaque image ne fonctionnera pas non plus car il n'y a aucun moyen de spécifier le numéro d'image à récupérer. Il renverra toujours la première image.

Au lieu de cela, pour répondre aux deux mises en garde, le code chargera et décodera l'image, puis, dans le rappel de décodage, écrira l'image d'animation dans le tampon du sous-système Screen. La fonction img_decode_frame() permet de définir des rappels et elle se trouve spécifiquement dans le rappel frame_f() (voir ici) que le code pour charger l'image dans le tampon doit être mis.

Les étapes pour charger les données sont les suivantes : Extrayez la cible de rendu (écran dans ce cas) qui est transmise en tant que paramètre de données (cela devra être converti d'un uintptr_t en un screen_window_t). Ensuite, les valeurs SCREEN_PROPERTY_POINTER et SCREEN_PROPERTY_STRIDE du tampon (voir ici) doit être défini respectivement sur les données et la foulée de l'image (le paramètre img_t du rappel). La dernière étape consiste à utiliser screen_post_window() (car la cible de rendu est une fenêtre) pour restituer l'image nouvellement chargée à l'écran.

Travailler avec le système d'événements QNX

Enfin, comme l'écran de démarrage est essentiellement une boucle infinie qui peut afficher une animation encore et encore, l'écran de démarrage doit savoir quand se terminer. C'est là que la définition du type de contexte sur SCREEN_WINDOW_MANAGER_CONTEXT devient importante. QNX a un Système d'événement où les événements sont générés si de nouvelles fenêtres sont créées, détruites, si le focus est donné, etc. Une liste complète des événements est ici. L'utilisation de SCREEN_WINDOW_MANAGER_CONTEXT permet à l'écran de démarrage d'écouter les événements de création de fenêtre et de focalisation de fenêtre générés par d'autres applications.

Deux événements importants pour l'écran de démarrage sont les événements SCREEN_EVENT_CREATE et SCREEN_EVENT_PROPERTY. L'événement SCREEN_EVENT_CREATE est utilisé pour écouter le moment où l'application principale (qui afficherait l'interface utilisateur principale du périphérique) crée la fenêtre et donc le moment où l'écran de démarrage doit démarrer sa séquence d'arrêt. D'autres propriétés peuvent être interrogées sur cet événement en utilisant l'ensemble de fonctions screen_get_event_property_X(). X est utilisé pour désigner le type de la propriété interrogée. Si l'application principale définit SCREEN_PROPERTY_GROUP, elle peut être interrogée pour savoir si l'application spécifique a déclenché l'événement.

L'événement SCREEN_EVENT_PROPERTY peut être utilisé conjointement avec la propriété SCREEN_PROPERTY_FOCUS qui est définie lorsqu'une fenêtre différente prend le focus (en savoir plus ici). Utiliser le système d'événements au lieu d'utiliser une animation d'une durée de X secondes (où X est la durée du processus de démarrage de l'appareil) signifie que l'animation peut être bouclée si l'application principale n'a pas encore été démarrée. Cela permet une bien meilleure portabilité entre différents matériels puisque les timings seront probablement différents.

En ce qui concerne le timing, étant donné que les événements ne peuvent pas être écoutés en continu (s'ils l'étaient, cela bloquerait le thread principal et empêcherait l'animation d'afficher les images suivantes), une tactique différente doit être utilisée. Si l'écran de démarrage est une image fixe, cela ne posera pas de problème. Cependant, en fonction de la durée de l'animation, ces événements peuvent devoir être écoutés environ tous les quarts d'images. Autrement dit, chaque fois qu'un quart des images de l'animation est chargé, avant que le quart suivant ne commence à être chargé, vérifiez les événements possibles.

Conclusion

En conclusion, ce blog explique pourquoi les écrans de démarrage sont importants, fournit des détails sur la façon de configurer un écran de démarrage de dispositif médical pour QNX et propose des mises en garde et des suggestions de conception qui peuvent être utiles. Cependant, l'écran de démarrage de chaque appareil a des exigences différentes. Par conséquent, ce blog propose des suggestions au lieu d’un processus étape par étape. Cependant, ces suggestions et détails devraient permettre aux développeurs de configurer un écran de démarrage QNX pour dispositif médical qui répond à leurs besoins spécifiques.

Dendy Addison est un Software Engineer chez Starfish Medical qui aide les clients à développer des logiciels de dispositifs médicaux sécurisés, efficaces et efficients. Il a la passion de faire une différence dans la vie des gens grâce aux logiciels qu'il développe. Dendy aime travailler sur toutes les facettes des dispositifs médicaux, du micrologiciel à l'interface utilisateur.

 

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
• La source: https://starfishmedical.com/blog/creating-a-medical-device-bootscreen-for-qnx/