A maioria, senão todos os principais dispositivos (incluindo dispositivos médicos) em todo o mundo têm algum tipo de tela de inicialização. Essa animação muitas vezes chamativa, mas às vezes simples, tem dois propósitos. Uma delas é simplesmente que tem uma boa aparência, e as empresas podem personalizar e adicionar sua marca a ele. Mas a segunda razão é indiscutivelmente mais importante; permite ao usuário saber que o dispositivo está funcionando e ainda em fase de inicialização.

Este blog será muito técnico, pois descreve como projetar e criar uma tela de inicialização.

Em particular, o blog compartilha dicas para resolver as armadilhas e complicações que surgem ao projetar uma tela de inicialização para o sistema operacional (SO) compatível com POSIX, QNX. QNX é um sistema operacional micro-kernel projetado para ser executado em sistemas embarcados e, mais especificamente, em hardware de segurança crítica. Para ajudar com os detalhes técnicos, referências à documentação do QNX estão incluídas para maiores esclarecimentos.

Definindo QNX o arquivo de construção do sistema operacional

A primeira etapa para projetar uma tela de inicialização é configurar o QNX para garantir que a tela de inicialização seja exibida o mais cedo possível na sequência de inicialização. Para usar o QNX, um desenvolvedor precisará definir um Arquivo de compilação do sistema operacional isso descreverá essencialmente quais drivers, aplicativos e outros arquivos estranhos precisam ser incluídos na imagem do sistema operacional. Esta imagem do sistema operacional será então exibida no sistema de destino e controlará quais aplicativos e drivers serão iniciados na inicialização. QNX possui um sistema gráfico conhecido como Subsistema de tela. Ele será usado para renderizar a imagem em um monitor específico conectado ao hardware. Isso deve ser iniciado o mais rápido possível durante a sequência de inicialização. A sequência de inicialização é definida no arquivo de construção como uma tag de script que será semelhante a:

[+script].script={}

com quaisquer linhas definidas dentro das chaves agindo como um script de shell. É aqui que o subsistema Screen deve ser iniciado.

O comando para iniciar o subsistema Screen será semelhante a:

tela -c {caminho_para_arquivo_config}.

Mais informações podem ser encontradas SUA PARTICIPAÇÃO FAZ A DIFERENÇA. Depois que o subsistema Screen for iniciado, o binário da tela de inicialização poderá ser iniciado posteriormente.

Trabalhando com o sistema de tela

O próximo passo é desenvolver a própria tela de inicialização. O QNX não possui uma maneira nativa de mostrar uma imagem ou animação como parte da sequência de inicialização. Isso precisará ser desenvolvido por dispositivo. Como a API Screen é escrita em C, a tela de inicialização também deve ser escrita em C. Além disso, o uso de C garantirá que a tela de inicialização possa ser iniciada com muito mais rapidez e, assim, reduzirá o tempo para informar o usuário sobre o funcionamento do dispositivo. A tela de inicialização precisa configurar algum código padrão para se comunicar com a API da tela. Detalhes podem ser encontrados SUA PARTICIPAÇÃO FAZ A DIFERENÇA mas para listá-los, a tela de inicialização precisará criar um objeto de contexto, um objeto de destino de renderização (neste caso, o destino de renderização necessário é um alvo de janela) e, finalmente, um objeto de buffer de tela. Tecnicamente, como C não é orientado a objetos, o conceito de objetos não existe na linguagem. Mas para facilitar a explicação, o termo objetos será usado para descrever os tipos de estruturas usadas.

Aqui estão esclarecimentos e dicas sobre alguns parâmetros específicos para os objetos que acabaram de ser definidos. Ao criar o objeto de contexto de tela para a tela de boot, o tipo SCREEN_APPLICATION_CONTEXT é insuficiente. Em vez disso, a tela de inicialização precisa do SCREEN_WINDOW_MANAGER_CONTEXT. O motivo será totalmente explicado mais adiante, mas basicamente tem a ver com saber quando a tela de inicialização precisa ser encerrada. Mais informações são SUA PARTICIPAÇÃO FAZ A DIFERENÇA.

A seguir, ao definir a propriedade de uso do destino de renderização, neste caso a janela, ela deve pelo menos ser definida como SCREEN_USAGE_WRITE, pois a tela de inicialização pretende gravar no buffer de renderização, mas não precisa necessariamente ler a partir dele. O padrão é uma combinação dos sinalizadores de gravação e leitura. Mais informações são SUA PARTICIPAÇÃO FAZ A DIFERENÇA.

Finalmente, o número ideal de buffers a serem usados ​​pelo alvo de renderização pode ser definido como um ou dois dependendo do tipo de tela de inicialização usada. Se o dispositivo tiver uma tela de inicialização estática, que constituirá uma única imagem, então 1 buffer é tudo o que é necessário. Porém, se for mostrar uma animação, duas são recomendadas. Usar dois em combinação com um alvo de renderização de uma janela permitirá que a tela de inicialização tenha buffer duplo. Em outras palavras, enquanto um quadro da animação está sendo carregado em um buffer, o subsistema Screen pode mostrar o outro buffer. Então, quando o buffer terminar de ser carregado, o subsistema Screen trocará o buffer ativo pelo novo.

Trabalhando com a biblioteca de imagens

Agora, uma segunda biblioteca QNX precisa ser usada para analisar e carregar quadros específicos da imagem ou animação da tela de inicialização. O subsistema Screen não lida com isso. Em vez disso, o Biblioteca de imagens é usado. Dependendo do tipo de arquivo de imagem que será usado para a tela de inicialização, serão necessários diferentes arquivos de codec Shared Object (.so). Eles seriam incluídos no arquivo de compilação da imagem do sistema operacional e uma lista dos disponíveis é SUA PARTICIPAÇÃO FAZ A DIFERENÇA. Uma sequência de etapas é necessária para renderizar um quadro de uma animação em uma tela anexada.

Essas etapas são definidas SUA PARTICIPAÇÃO FAZ A DIFERENÇA com algumas ressalvas. Uma ressalva importante é a possibilidade de que dependendo do hardware utilizado, todo o conjunto de quadros de uma animação não caiba na memória. Se for esse o caso, os quadros precisarão ser carregados dinamicamente e renderizados à medida que são carregados. A segunda ressalva é que img_load_file() e img_load() (ambos mencionados no link acima) carregarão apenas o primeiro quadro. Para uma imagem fixa, isto é suficiente, mas não para uma animação. Usar essas funções em um loop para ler cada quadro também não funcionará porque não há como especificar o número do quadro a ser recuperado. Sempre retornará o primeiro quadro.

Em vez disso, para resolver ambas as advertências, o código carregará e decodificará o quadro e, em seguida, no retorno de chamada de decodificação, gravará o quadro de animação no buffer do subsistema Screen. A função img_decode_frame() permite que callbacks sejam definidos e está especificamente no callback frame_f() (veja SUA PARTICIPAÇÃO FAZ A DIFERENÇA) que o código para carregar a imagem no buffer deve ser colocado.

As etapas para carregar os dados são as seguintes: Extraia o destino de renderização (tela neste caso) que é passado como parâmetro de dados (este precisará ser convertido do tipo de uintptr_t para screen_window_t). Em seguida, SCREEN_PROPERTY_POINTER e SCREEN_PROPERTY_STRIDE do buffer (consulte SUA PARTICIPAÇÃO FAZ A DIFERENÇA) deve ser definido para os dados e passos da imagem respectivamente (o parâmetro img_t do retorno de chamada). A etapa final é usar screen_post_window() (devido ao destino de renderização ser uma janela) para renderizar a imagem recém-carregada na tela.

Trabalhando com o sistema de eventos QNX

Finalmente, como a tela de inicialização é essencialmente um loop infinito que pode exibir uma animação continuamente, a tela de inicialização precisa saber quando terminar. É aqui que definir o tipo de contexto como SCREEN_WINDOW_MANAGER_CONTEXT se torna importante. QNX tem um Sistema de eventos onde os eventos são gerados se novas janelas forem criadas, destruídas, receberem foco, etc. SUA PARTICIPAÇÃO FAZ A DIFERENÇA. Usar SCREEN_WINDOW_MANAGER_CONTEXT permite que a tela de inicialização ouça a criação de janelas e eventos de foco de janela que são gerados por outros aplicativos.

Dois eventos importantes para a tela de inicialização são os eventos SCREEN_EVENT_CREATE e SCREEN_EVENT_PROPERTY. O evento SCREEN_EVENT_CREATE é usado para escutar quando o aplicativo principal (que mostraria a interface de usuário principal do dispositivo) cria a janela e, portanto, quando a tela de boot deve iniciar sua sequência de desligamento. Outras propriedades podem ser consultadas sobre este evento usando o conjunto de funções screen_get_event_property_X(). X é usado para denotar o tipo da propriedade consultada. Se a aplicação principal definir SCREEN_PROPERTY_GROUP, ela poderá ser consultada para descobrir se a aplicação específica disparou o evento.

O evento SCREEN_EVENT_PROPERTY pode ser usado em conjunto com a propriedade SCREEN_PROPERTY_FOCUS que é definida quando uma janela diferente fica em foco (leia mais informações SUA PARTICIPAÇÃO FAZ A DIFERENÇA). Usar o sistema de eventos em vez de usar uma animação com X segundos de duração (onde X é a duração do processo de inicialização do dispositivo) significa que a animação pode ser repetida se o aplicativo principal ainda não tiver sido iniciado. Isso permite uma portabilidade muito melhor entre diferentes hardwares, já que os tempos provavelmente serão diferentes.

No que diz respeito ao tempo, como os eventos não podem ser ouvidos continuamente (se fossem, bloquearia o thread principal, fazendo com que a animação não mostrasse os quadros subsequentes), uma tática diferente precisa ser empregada. Se a tela de inicialização for um quadro estático, isso não será um problema. No entanto, dependendo da duração da animação, esses eventos podem precisar ser ouvidos aproximadamente a cada quarto do conjunto de quadros. Ou seja, toda vez que um quarto dos frames da animação for carregado, antes que o próximo trimestre comece a ser carregado, verifique se há possíveis eventos.

Conclusão

Concluindo, este blog explica por que as telas de inicialização são importantes, fornece detalhes sobre como configurar uma tela de inicialização de dispositivo médico para QNX e oferece advertências e sugestões de design que podem ser úteis. No entanto, a tela de inicialização de cada dispositivo possui requisitos diferentes. Como resultado, este blog fornece sugestões em vez de um processo passo a passo. No entanto, essas sugestões e detalhes devem permitir que os desenvolvedores configurem uma tela de inicialização QNX para dispositivos médicos que atenda às suas necessidades específicas.

Dendy Addison é um Engenheiro de Software na Starfish Medical, que ajuda os clientes a desenvolver software de dispositivos médicos seguro, eficiente e eficaz. Ele tem paixão por fazer a diferença na vida das pessoas através dos softwares que desenvolve. Dendy gosta de trabalhar em todas as facetas dos dispositivos médicos, desde firmware até UI.

 

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• PlatoData.Network Gerativa Vertical Ai. Capacite-se. Acesse aqui.
• PlatoAiStream. Inteligência Web3. Conhecimento Amplificado. Acesse aqui.
• PlatãoESG. Carbono Tecnologia Limpa, Energia, Ambiente, Solar, Gestão de resíduos. Acesse aqui.
• PlatoHealth. Inteligência em Biotecnologia e Ensaios Clínicos. Acesse aqui.
• Fonte: https://starfishmedical.com/blog/creating-a-medical-device-bootscreen-for-qnx/