Большинство, если не все основные устройства (включая медицинские устройства) во всем мире имеют ту или иную форму загрузочного экрана. Эта часто яркая, но иногда простая анимация преследует две цели. Во-первых, он просто хорошо выглядит, плюс компании могут персонализировать его и добавить к нему свой бренд. Но вторая причина, возможно, более важна; это позволяет пользователю узнать, что устройство работает и в настоящее время все еще находится на этапе запуска.

Этот блог будет очень техническим, поскольку в нем описывается, как спроектировать и создать загрузочный экран.

В частности, в блоге делятся советами по устранению ловушек и сложностей, возникающих при разработке загрузочного экрана для POSIX-совместимой операционной системы (ОС) QNX. QNX — это микроядерная операционная система, предназначенная для работы на встроенных системах и, в частности, на критически важном для безопасности оборудовании. Для облегчения понимания технических деталей повсюду включены ссылки на документацию QNX для дальнейшего пояснения.

Определение QNX файла сборки ОС

Первым шагом в разработке загрузочного экрана является настройка QNX так, чтобы загрузочный экран отображался как можно раньше в последовательности загрузки. Чтобы использовать QNX, разработчику необходимо определить файл сборки ОС по сути, это будет описывать, какие драйверы, приложения и другие посторонние файлы необходимо включить в образ ОС. Этот образ ОС затем будет перенесен в целевую систему и будет контролировать, какие приложения и драйверы будут запускаться при загрузке. QNX имеет графическую систему, известную как Экранная подсистема. Он будет использоваться для рендеринга изображения на конкретный дисплей, подключенный к оборудованию. Это следует запустить как можно скорее во время загрузки. Последовательность загрузки определяется в файле сборки как тег сценария, который будет выглядеть следующим образом:

[+скрипт] .script={}

любые определенные строки внутри фигурных скобок действуют как сценарий оболочки. Здесь следует запустить подсистему Screen.

Команда запуска подсистемы Screen будет выглядеть так:

экран -c {путь_к_файлу_конфигурации}.

Дополнительная информация может быть найдена здесь. После запуска подсистемы Screen можно запустить двоичный файл загрузочного экрана.

Работа с системой экрана

Следующий шаг — разработка самого загрузочного экрана. В QNX нет встроенного способа отображения изображения или анимации как части последовательности загрузки. Это необходимо будет разработать для каждого устройства. Поскольку API экрана написан на C, загрузочный экран также должен быть написан на C. Кроме того, использование C обеспечит гораздо более быстрый запуск загрузочного экрана и, таким образом, сократит время информирования пользователя о работе устройства. Загрузочному экрану необходимо настроить некоторый шаблонный код для взаимодействия с Screen API. Подробности можно узнать здесь но чтобы перечислить их, загрузочному экрану потребуется создать объект контекста, целевой объект рендеринга (в данном случае необходимая цель рендеринга — это целевой объект окна) и, наконец, объект экранного буфера. Технически, поскольку C не является объектно-ориентированным, в языке не существует понятия объектов. Но для простоты объяснения для описания типов используемых структур будет использоваться термин «объекты».

Ниже приведены пояснения и указания относительно некоторых конкретных параметров только что определенных объектов. При создании объекта контекста экрана для загрузочного экрана тип SCREEN_APPLICATION_CONTEXT недостаточен. Вместо этого загрузочному экрану требуется SCREEN_WINDOW_MANAGER_CONTEXT. Причина будет полностью объяснена позже, но по сути она связана с пониманием того, когда необходимо завершить загрузочный экран. Дополнительная информация здесь.

Далее, при определении свойства использования цели рендеринга, в данном случае окна, для него должно быть установлено как минимум значение SCREEN_USAGE_WRITE, поскольку загрузочный экран намеревается записывать в буфер рендеринга, но не обязательно должен читать из него. По умолчанию используется комбинация флагов записи и чтения. Дополнительная информация здесь.

Наконец, идеальное количество буферов, используемых целью рендеринга, может быть установлено равным одному или двум, в зависимости от типа используемого загрузочного экрана. Если устройство будет иметь статический загрузочный экран, который будет представлять собой одно изображение, то достаточно одного буфера. Однако, если будет отображаться анимация, рекомендуется использовать два. Использование двух в сочетании с целью рендеринга окна позволит использовать двойную буферизацию загрузочного экрана. Другими словами, пока один кадр анимации загружается в один буфер, подсистема Screen может показывать другой буфер. Затем, когда загрузка буфера закончится, подсистема Screen заменит активный буфер на новый.

Работа с библиотекой изображений

Теперь необходимо использовать вторую библиотеку QNX для анализа и загрузки определенных кадров изображения или анимации загрузочного экрана. Подсистема Screen не справляется с этим. Вместо этого Библиотека изображений используется. В зависимости от типа файла изображения, который будет использоваться для загрузочного экрана, потребуются разные файлы общего объекта кодека (.so). Они будут включены в файл сборки образа ОС, а список доступных приведен ниже. здесь. Чтобы отобразить кадр анимации на прикрепленном экране, необходимо выполнить последовательность шагов.

Эти шаги определены здесь с некоторыми оговорками. Одним из важных предостережений является возможность того, что в зависимости от используемого оборудования весь набор кадров анимации не поместится в память. В этом случае кадры необходимо будет загружать «на лету» и визуализировать по мере их загрузки. Второе предостережение заключается в том, что и img_load_file(), и img_load() (оба упомянуты в ссылке выше) будут загружать только первый кадр. Для неподвижного изображения этого достаточно, но не для анимации. Использование этих функций в цикле для чтения каждого кадра также не будет работать, поскольку невозможно указать номер кадра для извлечения. Он всегда будет возвращать первый кадр.

Вместо этого, чтобы устранить оба недостатка, код загружает и декодирует кадр, а затем в обратном вызове декодирования записывает кадр анимации в буфер подсистемы Screen. Функция img_decode_frame() позволяет определять обратные вызовы, и она находится, в частности, в обратном вызовеframe_f() (см. здесь), что следует поместить код для загрузки изображения в буфер.

Шаги для загрузки данных следующие: Извлеките цель рендеринга (в данном случае экран), которая передается в качестве параметра данных (это необходимо будет привести к типу uintptr_t к screen_window_t). Затем SCREEN_PROPERTY_POINTER и SCREEN_PROPERTY_STRIDE буфера (см. здесь) должно быть установлено в данные изображения и шаг соответственно (параметр img_t обратного вызова). Последний шаг — использовать screen_post_window() (поскольку целью рендеринга является окно) для рендеринга только что загруженного изображения на экран.

Работа с системой событий QNX

Наконец, поскольку загрузочный экран по сути представляет собой бесконечный цикл, который может отображать анимацию снова и снова, загрузочный экран должен знать, когда завершить работу. Именно здесь становится важным установить тип контекста SCREEN_WINDOW_MANAGER_CONTEXT. У QNX есть Система событий где события генерируются, если новые окна создаются, уничтожаются, получают фокус и т. д. Полный список событий см. здесь. Использование SCREEN_WINDOW_MANAGER_CONTEXT позволяет загрузочному экрану прослушивать события создания окна и фокусировки окна, которые генерируются другими приложениями.

Двумя важными событиями для загрузочного экрана являются события SCREEN_EVENT_CREATE и SCREEN_EVENT_PROPERTY. Событие SCREEN_EVENT_CREATE используется для прослушивания того, когда основное приложение (которое отображает основной пользовательский интерфейс устройства) создает окно и, следовательно, когда загрузочный экран должен начать последовательность завершения работы. Дополнительные свойства можно запросить об этом событии с помощью набора функций screen_get_event_property_X(). X используется для обозначения типа запрашиваемого свойства. Если основное приложение определяет SCREEN_PROPERTY_GROUP, его можно запросить, чтобы узнать, инициировало ли конкретное приложение событие.

Событие SCREEN_EVENT_PROPERTY можно использовать вместе со свойством SCREEN_PROPERTY_FOCUS, которое устанавливается, когда другое окно получает фокус (подробнее см. здесь). Использование системы событий вместо анимации длительностью X секунд (где X — продолжительность процесса загрузки устройства) означает, что анимацию можно зациклить, если основное приложение еще не запущено. Это обеспечивает гораздо лучшую переносимость между различным оборудованием, поскольку тайминги, скорее всего, будут разными.

Что касается времени, поскольку события нельзя прослушивать непрерывно (если бы они были, это привело бы к блокировке основного потока, из-за чего анимация не отображала последующие кадры), необходимо использовать другую тактику. Если загрузочный экран представляет собой неподвижный кадр, это не будет проблемой. Однако, в зависимости от продолжительности анимации, эти события может потребоваться прослушивать примерно для каждой четверти набора кадров. То есть каждый раз, когда загружается четверть кадров анимации, прежде чем начнется загрузка следующей четверти, проверяйте возможные события.

Заключение

В заключение в этом блоге объясняется, почему важны загрузочные экраны, приводятся подробности о том, как настроить загрузочный экран медицинского устройства для QNX, а также предлагаются предостережения и предложения по дизайну, которые могут быть полезны. Однако к загрузочному экрану каждого устройства предъявляются разные требования. В результате в этом блоге представлены предложения, а не пошаговый процесс. Однако эти предложения и подробности должны позволить разработчикам настроить загрузочный экран QNX медицинского устройства, отвечающий их конкретным потребностям.

Денди Эддисон Инженер-программист в Starfish Medical, который помогает клиентам разрабатывать безопасное, эффективное и действенное программное обеспечение для медицинского оборудования. У него есть страсть к изменению жизни людей с помощью программного обеспечения, которое он разрабатывает. Dendy любит работать над всеми аспектами медицинских устройств, от прошивки до пользовательского интерфейса.

 

• SEO-контент и PR-распределение. Получите усиление сегодня.
• PlatoData.Network Вертикальный генеративный ИИ. Расширьте возможности себя. Доступ здесь.
• ПлатонАйСтрим. Интеллект Web3. Расширение знаний. Доступ здесь.
• ПлатонЭСГ. Углерод, чистые технологии, Энергия, Окружающая среда, Солнечная, Управление отходами. Доступ здесь.
• ПлатонЗдоровье. Биотехнологии и клинические исследования. Доступ здесь.
• Источник: https://starfishmedical.com/blog/creating-a-medical-device-bootscreen-for-qnx/