전 세계의 모든 주요 장치(의료 장치 포함)는 아니더라도 대부분 일종의 부팅 화면이 있습니다. 종종 화려하지만 때로는 단순한 애니메이션이 두 가지 목적을 수행합니다. 하나는 단순히 보기에 좋다는 점이며, 기업은 여기에 브랜드를 개인화하고 추가할 수 있다는 것입니다. 그러나 두 번째 이유는 틀림없이 더 중요합니다. 이를 통해 사용자는 장치가 작동 중이고 현재 아직 시작 단계에 있음을 알 수 있습니다.

이 블로그에서는 부팅 화면을 디자인하고 생성하는 방법을 설명하므로 매우 기술적입니다.

특히, 블로그에서는 POSIX 호환 운영 체제(OS)인 QNX용 부팅 화면을 설계할 때 발생하는 함정과 복잡성을 해결하기 위한 팁을 공유합니다. QNX 임베디드 시스템, 특히 안전이 중요한 하드웨어에서 실행되도록 설계된 마이크로 커널 OS입니다. 기술적 세부 사항을 돕기 위해 추가 설명을 위해 QNX 문서에 대한 참조가 전체에 포함되어 있습니다.

OS 빌드 파일 QNX 정의

부팅 화면을 디자인하는 첫 번째 단계는 부팅 화면이 부팅 순서에서 가능한 가장 빠른 시간에 표시되도록 QNX를 설정하는 것입니다. QNX를 사용하려면 개발자는 OS 빌드 파일 이는 기본적으로 OS 이미지에 포함되어야 하는 드라이버, 응용 프로그램 및 기타 관련 없는 파일을 설명합니다. 그러면 이 OS 이미지가 대상 시스템에 플래시되어 부팅 시 시작되는 애플리케이션과 드라이버를 제어합니다. QNX에는 다음과 같은 그래픽 시스템이 있습니다. 스크린 하위 시스템. 이는 하드웨어에 연결된 특정 디스플레이에 이미지를 렌더링하는 데 사용됩니다. 이는 부팅 순서 중에 가능한 한 빨리 시작되어야 합니다. 부팅 순서는 빌드 파일에 다음과 같은 스크립트 태그로 정의됩니다.

[+스크립트] .script={}

중괄호 안에 정의된 줄이 있으면 쉘 스크립트처럼 작동합니다. 여기에서 Screen 하위 시스템이 시작되어야 합니다.

Screen 하위 시스템을 시작하는 명령은 다음과 같습니다.

화면 -c {path_to_config_file}.

더 많은 정보를 찾을 수 있습니다. 여기에서 지금 확인해 보세요.. Screen 하위 시스템이 시작된 후에는 bootscreen 바이너리를 시작할 수 있습니다.

스크린 시스템 작업

다음 단계는 부팅 화면 자체를 개발하는 것입니다. QNX에는 부팅 시퀀스의 일부로 이미지나 애니메이션을 표시하는 기본 방법이 없습니다. 이는 장치별로 개발되어야 합니다. Screen API는 C로 작성되었으므로 부트스크린도 C로 작성해야 합니다. 또한 C를 사용하면 부팅 화면을 훨씬 빠르게 시작할 수 있으므로 사용자에게 장치 작동을 알리는 시간이 줄어듭니다. 부트스크린은 Screen API와 통신하기 위해 일부 상용구 코드를 설정해야 합니다. 구체적인 내용을 확인할 수 있습니다 여기에서 지금 확인해 보세요. 하지만 이를 나열하려면 부트스크린에서 컨텍스트 객체, 렌더 대상 객체(이 경우 필요한 렌더 대상은 창 대상), 마지막으로 화면 버퍼 객체를 생성해야 합니다. 기술적으로 C는 객체 지향이 아니기 때문에 언어에는 객체 개념이 존재하지 않습니다. 그러나 설명의 편의를 위해 사용되는 구조체 유형을 설명하는 데 객체라는 용어가 사용됩니다.

방금 정의한 개체의 일부 특정 매개 변수에 대한 설명과 지침은 다음과 같습니다. 부팅 화면에 대한 화면 컨텍스트 개체를 생성할 때 SCREEN_APPLICATION_CONTEXT 유형이 충분하지 않습니다. 대신, 부팅 화면에는 SCREEN_WINDOW_MANAGER_CONTEXT가 필요합니다. 그 이유는 나중에 자세히 설명하겠지만 본질적으로 부팅 화면을 언제 종료해야 하는지 아는 것과 관련이 있습니다. 더 많은 정보는 여기에서 지금 확인해 보세요..

다음으로 렌더 대상(이 경우 창)의 사용 속성을 정의할 때 부팅 화면이 렌더 버퍼에 쓰려고 하지만 반드시 읽을 필요는 없으므로 최소한 SCREEN_USAGE_WRITE로 설정해야 합니다. 기본값은 쓰기 및 읽기 플래그의 조합입니다. 더 많은 정보는 여기에서 지금 확인해 보세요..

마지막으로 렌더 타겟에서 사용할 이상적인 버퍼 수는 사용되는 부팅 화면 유형에 따라 1개 또는 XNUMX개로 설정할 수 있습니다. 장치에 단일 이미지를 구성하는 정적 부팅 화면이 있는 경우 버퍼 XNUMX개만 있으면 됩니다. 그러나 애니메이션을 표시하는 경우에는 두 개를 권장합니다. 두 개를 창의 렌더링 대상과 함께 사용하면 부팅 화면이 이중 버퍼링될 수 있습니다. 즉, 애니메이션의 한 프레임이 한 버퍼에 로드되는 동안 Screen 하위 시스템은 다른 버퍼를 표시할 수 있습니다. 그런 다음 버퍼 로드가 완료되면 Screen 하위 시스템은 활성 버퍼를 새 버퍼로 교체합니다.

이미지 라이브러리 작업

이제 두 번째 QNX 라이브러리를 사용하여 부팅 화면 이미지나 애니메이션의 특정 프레임을 구문 분석하고 로드해야 합니다. Screen 하위 시스템은 이를 처리하지 않습니다. 대신, 이미지 라이브러리 사용. 부팅 화면에 사용될 이미지 파일 유형에 따라 다른 코덱 공유 개체(.so) 파일이 필요합니다. 이는 OS 이미지 빌드 파일에 포함되며 사용 가능한 목록은 다음과 같습니다. 여기에서 지금 확인해 보세요.. 연결된 화면에 애니메이션 프레임을 렌더링하려면 일련의 단계를 수행해야 합니다.

이러한 단계는 정의됩니다 여기에서 지금 확인해 보세요. 몇 가지 주의사항이 있습니다. 한 가지 중요한 주의 사항은 사용 중인 하드웨어에 따라 애니메이션의 전체 프레임 세트가 메모리에 맞지 않을 가능성이 있다는 것입니다. 이 경우 프레임을 즉시 로드하고 로드되는 대로 렌더링해야 합니다. 두 번째 주의 사항은 img_load_file() 및 img_load()(둘 다 위 링크에서 참조) 모두 첫 번째 프레임만 로드한다는 것입니다. 정지 이미지의 경우 충분하지만 애니메이션의 경우에는 충분하지 않습니다. 각 프레임을 읽기 위해 루프에서 이러한 함수를 사용하면 검색할 프레임 번호를 지정할 방법이 없기 때문에 작동하지 않습니다. 항상 첫 번째 프레임을 반환합니다.

대신 두 가지 주의 사항을 모두 해결하기 위해 코드는 프레임을 로드하고 디코딩한 다음 디코드 콜백에서 애니메이션 프레임을 화면 하위 시스템 버퍼에 씁니다. 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는 장치의 부팅 프로세스 길이) 길이의 애니메이션을 사용하는 대신 이벤트 시스템을 사용한다는 것은 기본 애플리케이션이 아직 시작되지 않은 경우 애니메이션이 반복될 수 있음을 의미합니다. 이는 타이밍이 다를 가능성이 높기 때문에 서로 다른 하드웨어 간에 훨씬 더 나은 이식성을 허용합니다.

타이밍에 관해서는 이벤트를 지속적으로 수신할 수 없기 때문에(만약 이벤트가 발생하면 메인 스레드가 잠기므로 애니메이션이 후속 프레임을 표시하지 않게 됨) 다른 전술을 사용해야 합니다. 부팅 화면이 스틸 프레임인 경우 이는 문제가 되지 않습니다. 그러나 애니메이션 길이에 따라 이러한 이벤트는 대략 매 분기 프레임 세트마다 수신해야 할 수도 있습니다. 즉, 애니메이션 프레임의 4분의 1이 로드될 때마다 다음 4분의 1이 로드되기 전에 가능한 이벤트가 있는지 확인합니다.

결론

결론적으로, 이 블로그에서는 부팅 화면이 중요한 이유를 설명하고, QNX용 의료 기기 부팅 화면을 설정하는 방법에 대한 세부 정보를 제공하며, 유용할 수 있는 주의 사항과 디자인 제안을 제공합니다. 그러나 모든 장치의 부팅 화면에는 서로 다른 요구 사항이 있습니다. 따라서 이 블로그에서는 단계별 프로세스 대신 제안 사항을 제공합니다. 그러나 이러한 제안과 세부 사항을 통해 개발자는 특정 요구 사항을 충족하는 의료 기기 QNX 부팅 화면을 설정할 수 있습니다.

덴디 애디슨은 소프트웨어 엔지니어 고객이 안전하고 효율적이며 효과적인 의료 기기 소프트웨어를 개발하도록 돕는 Starfish Medical에서. 그는 자신이 개발한 소프트웨어를 통해 사람들의 삶을 변화시키려는 열정을 가지고 있습니다. Dendy는 펌웨어부터 UI까지 의료 기기의 모든 측면을 다루는 작업을 즐깁니다.

 

• SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
• PlatoData.Network 수직 생성 Ai. 자신에게 권한을 부여하십시오. 여기에서 액세스하십시오.
• PlatoAiStream. 웹3 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
• 플라톤ESG. 탄소, 클린테크, 에너지, 환경, 태양광, 폐기물 관리. 여기에서 액세스하십시오.
• PlatoHealth. 생명 공학 및 임상 시험 인텔리전스. 여기에서 액세스하십시오.
• 출처: https://starfishmedical.com/blog/creating-a-medical-device-bootscreen-for-qnx/