지난 시간에 이어 display - driver를 잇는 adapter 부분을 구현해 보도록 하겠습니다. 궁극적으로는 아래와 같은 구조가 될 것입니다. display → adapter → driver 결국 adapter 패턴이 있어 display도 다른 driver처럼 사용할 수 있게 됩니다. 먼저 adapter의 header(interface) 부터 살펴 보도록 하겠습니다. extern driver_t *setup_display_adapter(void); setup_display_adapter을 extern으로 선언해줍니다. setup_display_adapter를 호출하면 driver_t의 포인터를 전달해 주도록 되어있습니다. 헤더를 선언할 때 아래와 같은 코드가 많이 나오는데요, 혹시 모르시는 분들..
RTOS를 사용하지 않는 베어메탈 Firmware에서는 각각의 기능 프로세스의 처리 시간을 적당히 잘 분배 해야 합니다. 처리 시간이 긴 프로세스는 여러개로 쪼개야 하며, 특히 인터럽트 발생시 인터럽트 인터럽트 루틴에 긴 처리시간을 요구하는(지연이 발생하는)코드를 넣으면 절대 안됩니다. 더욱이 애매한 처리 시간을 요구하는 코드를 넣는 경우는 더욱 위험합니다. 왜냐하면 불규칙적으로 에러를 발생되며 디버깅을 위해 많은 시간이 소요될 수도 있습니다. 인터럽트 서비스 루틴에서는 입력된 데이터를 적당한 자료구조에 적재해놓던가, 특정 플래그를 set하는 수준 혹은 메시지 큐에 쌓는 수준의 처리가 가장 좋습니다. 만약 전체 시스템이 1초단위로 어떠한 처리가 끝나야 한다면, 각각의 프로세스들이 최대 처리되는 시간의 합..
먼저 우리가 구현해야 할 app controller의 extern 함수들을 확인하겠습니다. extern int app_init_app(app_t *app); extern void app_process(void); extern int app_set_msg(msg_t msg, uint32_t param1, uint32_t param2); extern int app_start_app(app_id_t id); extern int app_switch_app(app_id_t id); extern app_t *app_get_current_app(void); 각각의 역할은 지난 포스트에서 기록한 대로입니다. app_init_app - app 등록 app_process - 현재 active app의 loop 실행, 메시..
이전 포스트에서 설명한 state machine 은 현재 application의 상태를 상황에 맞게 active app state를 변경하여 해당 상태에 있을 경우 들어오는 이벤트, 메시지 처리, 이외 요청들을 처리하도록 만듭니다. 또한 원한다면 현재 상태(state)에서 다른 상태(state)로 전환을 할 수도 있습니다. C언어에서는 몇가지 코딩의 제약이 있지만 간단하게 state machine을 만들 수 있으며 우리는 이것을 app state(혹은 app)이라고 편하게 부르도록 하겠습니다. app state 들은 간략하게 다음의 필수 요건이 있습니다. app을 생성,삭제, 전환등을 할 controller 필요 app은 이벤트를 받을 수 있음 app끼리 전환 할 수 있음 app은 하나만 동작 가..
펌웨어를 처음 개발할 때 수많은 절차와 처리들을 어떻게 일목요연하고 보기 쉽게 코딩해야하는지 막막하게 느껴집니다. 이럴 때 보통 디자인 패턴이라는 프로그래밍의 오래된 습관 혹은 관습을 이용하여 해결할 수 있습니다. state machine은 이런 디자인 패턴중에 하나로 아주 사용하기 쉽고 유용하며 소프트웨어 개발자라면 꼭 알아야 할 디자인 패턴 기법입니다. single core 안에서 동작 중인 application은 반드시 하나의 상태(state)안에 있습니다. 각각의 이벤트나 어떠한 처리는 state 안에서 이루어 지며 여러개의 state 끼리 서로 전환하며 프로그램이 동작하게 됩니다. 아래 다이어그램에서 우리가 만들 app state machine 을 좀 더 구체적으로 알아보겠습니다. a..