La mayoría, si no todos, los dispositivos principales (incluidos los dispositivos médicos) en todo el mundo tienen algún tipo de pantalla de inicio. Esta animación, a menudo llamativa pero a veces sencilla, tiene dos propósitos. Una es simplemente que se ve bien y, además, las empresas pueden personalizarlo y agregarle su marca. Pero podría decirse que la segunda razón es más importante; le permite al usuario saber que el dispositivo está funcionando y que actualmente aún se encuentra en la fase de inicio.

Este blog será muy técnico ya que describe cómo diseñar y crear una pantalla de inicio.

En particular, el blog comparte consejos para abordar los obstáculos y complicaciones que conlleva el diseño de una pantalla de inicio para el sistema operativo (SO) compatible con POSIX, QNX. QNX es un sistema operativo de micronúcleo diseñado para ejecutarse en sistemas integrados y, más específicamente, en hardware crítico para la seguridad. Para ayudar con los detalles técnicos, se incluyen referencias a la documentación de QNX para mayor aclaración.

Definición de QNX como archivo de compilación del sistema operativo

El primer paso para diseñar una pantalla de inicio es configurar QNX para garantizar que la pantalla de inicio se muestre lo antes posible en la secuencia de inicio. Para utilizar QNX, un desarrollador deberá definir un archivo de compilación del sistema operativo eso esencialmente describirá qué controladores, aplicaciones y otros archivos extraños deben incluirse en la imagen del sistema operativo. Esta imagen del sistema operativo luego se mostrará en el sistema de destino y controlará qué aplicaciones y controladores se inician en el arranque. QNX tiene un sistema de gráficos conocido como Subsistema de pantalla. Se utilizará para representar la imagen en una pantalla específica adjunta al hardware. Esto debe iniciarse lo antes posible durante la secuencia de inicio. La secuencia de inicio se define en el archivo de compilación como una etiqueta de secuencia de comandos que se verá así:

[+guión] .script={}

con cualquier línea definida dentro de las llaves actuando como un script de shell. Aquí es donde se debe iniciar el subsistema Screen.

El comando para iniciar el subsistema de pantalla se verá así:

pantalla -c {ruta_al_archivo_config}.

Encuentre más información esta página. Una vez que se ha iniciado el subsistema Screen, se puede iniciar posteriormente el binario de la pantalla de arranque.

Trabajar con el sistema de pantalla

El siguiente paso es desarrollar la propia pantalla de arranque. QNX no tiene una forma nativa de mostrar una imagen o animación como parte de la secuencia de inicio. Esto deberá desarrollarse por dispositivo. Dado que Screen API está escrita en C, la pantalla de inicio también debe estar escrita en C. Además, el uso de C garantizará que la pantalla de inicio se pueda iniciar mucho más rápido y, por lo tanto, reducirá el tiempo para informar al usuario sobre el funcionamiento del dispositivo. La pantalla de inicio necesita configurar algún código repetitivo para comunicarse con Screen API. Se pueden encontrar detalles esta página pero para enumerarlos, la pantalla de inicio deberá crear un objeto de contexto, un objeto de destino de renderizado (en este caso, el destino de renderizado necesario es un destino de ventana) y, finalmente, un objeto de búfer de pantalla. Técnicamente, dado que C no está orientado a objetos, el concepto de objetos no existe en el lenguaje. Pero para facilitar la explicación, se utilizará el término objetos para describir los tipos de estructuras utilizadas.

A continuación se ofrecen aclaraciones y sugerencias sobre algunos parámetros específicos para los objetos que se acaban de definir. Al crear el objeto de contexto de pantalla para la pantalla de inicio, el tipo SCREEN_APPLICATION_CONTEXT es insuficiente. En cambio, la pantalla de inicio necesita SCREEN_WINDOW_MANAGER_CONTEXT. El motivo se explicará completamente más adelante, pero esencialmente tiene que ver con saber cuándo debe finalizar la pantalla de inicio. Más información es esta página.

A continuación, al definir la propiedad de uso del destino de renderizado, en este caso la ventana, esto debe al menos establecerse en SCREEN_USAGE_WRITE ya que la pantalla de inicio intenta escribir en el búfer de renderizado pero no necesariamente necesita leer desde él. El valor predeterminado es una combinación de los indicadores de escritura y lectura. Más información es esta página.

Finalmente, la cantidad ideal de buffers que usará el objetivo de renderizado se puede establecer en uno o dos dependiendo del tipo de pantalla de inicio utilizada. Si el dispositivo va a tener una pantalla de inicio estática, que constituirá una sola imagen, entonces todo lo que se necesita es 1 búfer. Sin embargo, si va a mostrar una animación, se recomiendan dos. El uso de dos en combinación con un destino de renderizado de una ventana permitirá que la pantalla de inicio tenga doble buffer. En otras palabras, mientras se carga un fotograma de la animación en un búfer, el subsistema de pantalla puede mostrar el otro búfer. Luego, cuando se termine de cargar el búfer, el subsistema de pantalla cambiará el búfer activo por uno nuevo.

Trabajar con la biblioteca de imágenes

Ahora, es necesario utilizar una segunda biblioteca QNX para analizar y cargar fotogramas específicos de la imagen o animación de la pantalla de inicio. El subsistema Screen no maneja esto. En cambio, el Biblioteca de imágenes se utiliza. Dependiendo del tipo de archivo de imagen que se utilizará para la pantalla de inicio, se necesitarán diferentes archivos de objetos compartidos (.so) de códec. Estos se incluirían en el archivo de compilación de la imagen del sistema operativo y se incluye una lista de los disponibles. esta página. Es necesario realizar una secuencia de pasos para representar un fotograma de una animación en una pantalla adjunta.

Estos pasos están definidos esta página con algunas advertencias. Una advertencia importante es la posibilidad de que, dependiendo del hardware que se utilice, todo el conjunto de fotogramas de una animación no quepa en la memoria. Si este es el caso, los fotogramas deberán cargarse sobre la marcha y renderizarse a medida que se cargan. La segunda advertencia es que tanto img_load_file() como img_load() (ambos mencionados en el enlace anterior) solo cargarán el primer fotograma. Para una imagen fija esto es suficiente, pero no para una animación. El uso de estas funciones en un bucle para leer cada cuadro tampoco funcionará porque no hay forma de especificar el número de cuadro a recuperar. Siempre devolverá el primer fotograma.

En cambio, para abordar ambas advertencias, el código cargará y decodificará el fotograma y luego, en la devolución de llamada de decodificación, escribirá el fotograma de animación en el búfer del subsistema Pantalla. La función img_decode_frame() permite definir devoluciones de llamada y está específicamente en la devolución de llamada frame_f() (ver esta página) que se debe poner el código para cargar la imagen en el buffer.

Los pasos para cargar los datos son los siguientes: Extraiga el destino de renderizado (pantalla en este caso) que se pasa como parámetro de datos (esto deberá escribirse desde uintptr_t a screen_window_t). Luego, SCREEN_PROPERTY_POINTER y SCREEN_PROPERTY_STRIDE del búfer (consulte esta página) deben establecerse en los datos de la imagen y la zancada respectivamente (el parámetro img_t de la devolución de llamada). El último paso es usar screen_post_window() (debido a que el objetivo de renderizado es una ventana) para renderizar la imagen recién cargada en la pantalla.

Trabajar con el sistema de eventos QNX

Finalmente, debido a que la pantalla de inicio es esencialmente un bucle infinito que puede mostrar una animación una y otra vez, la pantalla de inicio necesita saber cuándo finalizar. Aquí es donde se vuelve importante establecer el tipo de contexto en SCREEN_WINDOW_MANAGER_CONTEXT. QNX tiene un Sistema de eventos donde se generan eventos si se crean, destruyen nuevas ventanas, se les da el foco, etc. Una lista completa de eventos es esta página. El uso de SCREEN_WINDOW_MANAGER_CONTEXT permite que la pantalla de inicio escuche los eventos de creación y enfoque de ventanas generados por otras aplicaciones.

Dos eventos importantes para la pantalla de inicio son los eventos SCREEN_EVENT_CREATE y SCREEN_EVENT_PROPERTY. El evento SCREEN_EVENT_CREATE se utiliza para escuchar cuándo la aplicación principal (que mostraría la interfaz de usuario principal del dispositivo) crea la ventana y, por lo tanto, cuándo la pantalla de inicio debe iniciar su secuencia de apagado. Se pueden consultar más propiedades sobre este evento mediante el uso del conjunto de funciones screen_get_event_property_X(). X se utiliza para indicar el tipo de propiedad consultada. Si la aplicación principal define SCREEN_PROPERTY_GROUP, se puede consultar para averiguar si la aplicación específica activó el evento.

El evento SCREEN_EVENT_PROPERTY se puede utilizar junto con la propiedad SCREEN_PROPERTY_FOCUS que se establece cuando se enfoca una ventana diferente (leer más información esta página). Usar el sistema de eventos en lugar de usar una animación que dura X segundos (donde X es la duración del proceso de inicio del dispositivo) significa que la animación se puede repetir si la aplicación principal aún no se ha iniciado. Esto permite una portabilidad mucho mejor entre diferentes hardware, ya que lo más probable es que los tiempos sean diferentes.

En cuanto al tema del tiempo, debido a que los eventos no se pueden escuchar continuamente (si lo hicieran, se bloquearía el hilo principal y la animación no mostraría fotogramas posteriores), es necesario emplear una táctica diferente. Si la pantalla de inicio es un cuadro fijo, esto no será un problema. Sin embargo, dependiendo de la duración de la animación, es posible que sea necesario escuchar estos eventos aproximadamente cada cuarto de fotograma. Es decir, cada vez que se carga una cuarta parte de los fotogramas de la animación, antes de que comience a cargarse el siguiente cuarto, se comprueba si hay posibles eventos.

Conclusión

En conclusión, este blog explica por qué las pantallas de inicio son importantes, proporciona detalles sobre cómo configurar una pantalla de inicio de dispositivo médico para QNX y ofrece advertencias y sugerencias de diseño que pueden resultar útiles. Sin embargo, la pantalla de inicio de cada dispositivo tiene requisitos diferentes. Como resultado, este blog ofrece sugerencias en lugar de un proceso paso a paso. Sin embargo, estas sugerencias y detalles deberían permitir a los desarrolladores configurar una pantalla de arranque QNX para dispositivos médicos que satisfaga sus necesidades específicas.

Dendy Addison es una Ingeniero de Software en Starfish Medical, que ayuda a los clientes a desarrollar software para dispositivos médicos seguro, eficiente y eficaz. Le apasiona marcar una diferencia en la vida de las personas a través del software que desarrolla. A Dendy le gusta trabajar en todas las facetas de los dispositivos médicos, desde el firmware hasta la interfaz de usuario.

 

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• PlatoData.Network Vertical Generativo Ai. Empodérate. Accede Aquí.
• PlatoAiStream. Inteligencia Web3. Conocimiento amplificado. Accede Aquí.
• PlatoESG. Carbón, tecnología limpia, Energía, Ambiente, Solar, Gestión de residuos. Accede Aquí.
• PlatoSalud. Inteligencia en Biotecnología y Ensayos Clínicos. Accede Aquí.
• Fuente: https://starfishmedical.com/blog/creating-a-medical-device-bootscreen-for-qnx/