RTOS의 인터페이스 - CMSIS

 

0.

 

https://arm-software.github.io/CMSIS_5/RTOS/html/genRTOSIF.html

Generic RTOS Interface

 

1.

 

컴퓨터공학에서 모듈화, 분리, 캡슐화 등의 전략은

복잡한 시스템을 관리하기 쉽고 이해하기 쉬운 부분으로 나누는 설계방법으로

 

각각의 모듈들이 업무를 명확히 분담하고 자신의 기능에 집중하도록 만드는 방식이다.

자신이 맡은 일을 처리하고, 인터페이스를 통해서 다른 모듈들과 상호작용하는 식으로 말이다.

 

2.

 

OSI7계층, 혹은 네트워크 5계층 등도 비슷한 맥락이다.

물리적 신호와 비트를 전송하는 층,

그 위에 프레임을 전송하는 층

그 위에 패킷을 전송하고 라우팅을 관리하는 층...

패킷과 페이로드를 전송하는 층은 긴밀히 연결되어 있다든지, 계층들이 완벽하게 독립적이지 않고

때로는 서로 의존성을 가지게 되는 것도 어쩔 수 없지만,

 

거대한 시스템을 인식하려면 Divide and Conquer의 전략이 유효해진다.

 

3.

 

기존의 자영업자들이, 자신이 상가주인에게 임대료를 납부하고, 

인테리어를 하고, 도매상에게 재료를 구매하고, 그 재료로 음식을 만들고...

이러한 과정을 거의 원맨쇼로 진행했지만,

 

어느 순간부터 재료를 수급하고 지점에 재료를 전달하는 프랜차이즈와

상가 월세 계약을 하고 재료로 음식을 나누는 지점장이

역할을 분리하여 각각의 역할에 집중하고,

서로가 상호작용하는 식으로 작동하는게

결과적으로 더 강력한 시스템이 되어 주류를 차지한 것과 크게 다르지 않다.

 

4.

 

컴퓨터 시스템도 이러한 계층의 분리를 지향한다.

어플리케이션이 해야할 일과, 커널이 해야할 일, 하드웨어가 해야할 일을 엄격히 분리하고

어플리케이션-커널 간에는 System Call로 상호작용하고,

커널과 하드웨어 사이에는 드라이버나 펌웨어, 혹은 BSP와 HAL등으로 상호작용하는 식으로 말이다.

 

또 소프트웨어를 디자인 할 때에도,

어플리케이션과 어플리케이션 사이에 미들웨어 같은 중재자를 두고

상호작용하도록 설계하기도 하고 (Mediator 패턴)

SQLAlchemy 같이 데이터베이스 부분과 백엔드 부분을 분리하기도 하는 것을 볼 수 있다.

 

객체지향적으로 모듈화, 캡슐화를 수행하는 것도

이러한 역할의 분리를 통해 중복되는 코드를 줄이고 효율적으로 유지보수 등의 목적이 있는 것이다.

 

5.

 

 

서론이 길었는데

실제로 돌아가는 RTOS커널과 사용자가 작성한 Application Code 사이에서도

그 사이에 중간계층으로서 코드의 재사용성을 높이기 위한 Adaptation Layer가 존재한다.

 

ARM의 Cortex M시리즈를 지원하는 CMSIS-RTOS API이다.

발음은 캠시스? 쌤시스? 씨엠시스? 다들 자기 멋대로 부르네..

 

RTOS도 여러가지이고, 아직까지 여러가지 RTOS커널들이 양립하고 있는 상황에서,

한번 코드를 작성하여, 여러가지 RTOS에서 작동하는 재사용 가능한 코드를 만들기 위해서

ARM이 제공한 CMSIS-RTOS API를 호출하는 방식으로 코드를 작성하자는 것이다.

 

CMSIS를 사용한 Adaptation Layer를 채택함으로써

기존의 FreeRTOS말고도 다른 RTOS 커널들에서도 기존의 코드를 재사용할 수 있는 셈이다.

 

개발자가 직접 하드웨어와 커널의 세부적인 내용을 신경쓰지 않고도

작업을 수행할 수 있는 추상화 계층을 제공한다.

 

6.

 

 

 

Coding Rules
The CMSIS uses the following essential coding rules and conventions:

Compliant with ANSI C (C99) and C++ (C++03).
Uses ANSI C standard data types defined in <stdint.h>.
Variables and parameters have a complete data type.
Expressions for #define constants are enclosed in parenthesis.
Conforms to MISRA 2012 (but does not claim MISRA compliance). MISRA rule violations are documented.
In addition, the CMSIS recommends the following conventions for identifiers:

CAPITAL names to identify Core Registers, Peripheral Registers, and CPU Instructions.
CamelCase names to identify function names and interrupt functions.
Namespace_ prefixes avoid clashes with user identifiers and provide functional groups (i.e. for peripherals, RTOS, or DSP Library).
The CMSIS is documented within the source files with:

Comments that use the C or C++ style.
Doxygen compliant function comments that provide:
brief function overview.
detailed description of the function.
detailed parameter explanation.
detailed information about return values.

 

또한 공식문서를 찾아보면 해당 CMSIS를 코딩하는 Coding Rules를 찾아볼 수 있는데,

<stdint.h>에 명시된 ANSI C 표준을 따르고,

#define constants 형태의 표현은 괄호로 닫혀 있어야 하고..

Core Register, Peripheral Register, CPU instruction 등은 변수명이 모두 대문자,

함수명과 인터럽트 루틴등은 camelCase를 사용하며

Namespace_(GPIO_, UART_ ...)의 방식으로 변수명이 겹치지 않도록 한다 등의 규칙을 가지고 있다고 한다.