ちょい(Choi)のEmbedded Systems

__use_no_semihosting_swiエラー対策

2010-02-14T18:43:00.000-08:00

セミホスティングとはアプリケーションによるサービス要求を、デバッガを通してホストコンピュータで動作する機能です。サービス要求方法としては標準ライブラリ関数を呼び出すことによる間接的な方法もありますが、SWI命令語を直接呼び出す方法もあります。

例えば、ある関数で時間を得るためにtime関数を呼び出したとします。time関数は以下のようになっています。

time
    （省略）
    0x00008028: ef123456 V4.. SVC #0x123456 ; formerly SWI
    （省略）

標準ライブラリの大半は上記のようにSVCを呼び出してホストにサービス要求を依頼します。これは通常デバッグ環境で必要であり、出荷するバージョンだと困ります。スタンドーアロンで動作できるように、すなわちそれ自体の持っている機能だけで動作しなければなりません。

解決方法としてセミホスティング機能を使っている箇所を見つけ、直接実装する方法があります。
以下のように明示的にセミホスティングを使わないように指定できます。

C言語の場合
#pragma import(__use_no_semihosting_swi)

アセンブリの場合
IMPORT __use_no_semihosting_swi

再度ビルディングすると以下のようなエラーが発生します。

Error: L6915E: Library reports error: __use_no_semihosting_swi was requested, but time was referenced

エラーは“セミホスティングを使用しないと宣言したのにどこかでtimeを参照している”という意味です。
さて、どこで参照しているでしょうか？希望が大きいプロジェクトだとソースコードが多くて見つけるのも大変です。またサードーパーティー会社から提供して頂いたライブラリが参照しているかも知れません。

以下のようにリンカーオプションを追加しますと参照している箇所を教えてくれます。

armlink (オプション省略) --list info.map --verbose

そして生成されたinfo.mapファイルから「__I_use_semihosting」を検索します。

Loading member sys_time.o from c_4.l.
    definition: time
    reference : __I_use_semihosting

すなわち、time関数でセミホスティングの機能を使っていました。
セミホスティング機能を使わないようにtime関数を直接実装して解決できます。

コンテキストスイッチング速度の測定方法

2010-02-12T03:10:00.000-08:00

リアルタイムOSをターゲットに移植（ポーティング）するためにはいくつかのプロセッサ依存コードが必要です。例えば、タスク間に切り替えを行うためには現在動作している最中のタスクのコンテキストを保存します。この後、何らかの理由（例。セマフォに待つ）でディスパッチャはレディー状態になったより優先順位が低いタスクのコンテキストを復帰させます。このようになタスク間の切り替えを“タスクレベルのコンテキストスイッチング”といいます。

一般的にC言語ではプロセッサのレジスタを自由自在にシステムスタックに保存したり、復帰することは不可能です。こういう制限を解決するためには直接プロセッサに依存するアセンブリコードを書くしかありません。プロセッサに依存する部分を“ポート”といいます。ポートを開発するためにはプロセッサの知識とリアルタイムOSに関する知識が必要であり、単純な作業ではありません。

ここではポートの一部であるタスクレベルのコンテキストスイッチングを測定する方法について説明します。外部から観察するためには特定GPIOとオシロスコープが必要です。まず次のように優先度が高いタスクと低いタスクを用意します。

void HPT_Task(void)
{
    LED_ClrLED0();
    for(;;) {
        OS_Suspend();
        LED_ClrLED0(); // D
    }
}

void LPT_Task(void)
{
    for(;;) {
        LED_SetLED0(); // A
        LED_ClrLED0(); // B

        LED_SetLED0(); // C
        OS_Resume( &HPTaskTcb );
    }
}

１．リアルタイムOSが起動すると優先順位が高いHPT_Taskを動作させます。
２．HPT_TaskはOS_Suspend関数を呼び出して待機状態になります。
３．カネルのディスパッチャにより次の優先度を持つLPT_Taskを動作させます。
４．LPT_TaskはLED_SetLED0関数を呼び出して特定GPIOをハイレベルにしておき、 HPT_TaskのTCBを引数としてOS_Resume関数を呼び出します。再びディスパッチャによりHPT_Taskが動作されます。
５．HPT_TaskはOS_Suspend関数の続きから実行し、今度は特定GPIOをローレベルにします。

オシロスコープで各空間を測定しますと(A-B)はGPIO出力関数にかかる時間になり、(C-D)はタスクレベルのスイッチングにかかる時間になります。(C-D)－(A-B)を計算したら、タスクレベルのコンテキストスイッチングにかかる正確な時間を確認できます。

Introducing to uC/OS-III

2009-10-29T18:01:00.000-07:00

얼마 전 RTOS 구현을 명쾌하게 해설한 uC/OS-II의 후속작인 uC/OS-III – The Real Time Kernel이 발간되었습니다. 800페이지에 달하는 엄청난 분량의 서적과 타겟에서 uC/OS-III를 평가해 볼 수 있는 평가보드로 구성되어 있습니다. 전작을 보신 분들은 아시겠지만 Jean J. Labrosse의 저술 스타일이 워낙 간결하고 자세하게 설명되어 있어 원서로 봐도 무리가 없습니다. 평가보드에는 STM32 프로세서가 탑재되어 있는데 Segger사의 J-Link가 빌트인 되어 있는 것이 특징입니다.

다음은 uC/OS-II와 uC/OS-III를 비교한 자료입니다. Micrium에서 제공하는 Data Sheet에서 인용했습니다.

위 표에서도 알 수 있듯이 uC/OS-II와의 큰 차이점은 생성할 수 있는 태스크 수에 제한이 없어졌다는 것입니다. 또한 전작은 태스크에 부여할 수 있는 우선 순위가 유일해야 하나 uC/OS-III는 동일한 우선 순위의 태스크를 생성할 수 있으며 라운드 로빈 방식으로 스케쥴링 됩니다.

서적을 탐독하다 감탄한 몇 가지 내용들을 소개하고자 합니다.

우선 순위 검색 최적화

MCU가 CLZ (Count Leading Zeros)와 같은 명령어를 지원한다면 최상위 우선 순위의 태스크 검색을 최적화 할 수 있다고 합니다. CLZ 명령어 셋은 MSB로부터 비트가 설정되어 있는 카운트 값을 반환하는 명령어입니다. MSB가 높은 우선순위를 나타낼 때 메모리에 상주한 프로그램 코드로 비트 설정 유무를 확인하는 것보다 명령어 셋을 이용하는 것이 나을 것입니다. 아시겠지만 메모리가 외부 버스에 있던 내부 버스에 있던 MCU 명령어 셋보다 빠르진 않을 것입니다. 최적화를 위해 많은 고민을 한 저자의 노력이 돋보입니다.

인터럽트 지연 최소화

커널 코드 조차도 ISR과 커널 자료구조를 공유하고 있으므로 크리티컬 섹션을 보호하기 위해서는 인터럽트를 disable 해야 합니다. 이는 인터럽트 응답 지연으로 이어져서 응답 시간이 크리티컬한 애플리케이션에서는 문제가 있다는 것입니다. 커널 코드가 최소한의 인터럽트만 지연시키도록 구현했을 것임에도 불구하고 이것도 용납할 수 없다는 (?!) 저자의 세심하고 꼼꼼한 성격을 알 수 있습니다.
uC/OS-III는 커널 코드로 인한 인터럽트 지연을 최소화하기 위해 Deferred Post Method라는 방법을 제공합니다. 틱이 발생할 때 Interrupt Queue라는 자료 구조로 Interrupt Queue Task에 시그널을 보냅니다. (아주 짧은 인터럽트만 지연 시킨다고 했는데 소스 코드가 공개되어 있지 않은 관계로 확인은 못했습니다.) Interrupt Queue Task는 우선 순위가 가장 높은 태스크로 예약되어 있어 ISR 종료와 함께 반드시 실행됩니다. Interrupt Queue Task에서는 Tick 서비스나 라운드 로빈 스케쥴링과 같은 커널 서비스 수행합니다.
이 때 중요한 것은 크리티컬 섹션을 보호하기 위해 인터럽트를 disable하는 것이 아니라 스케쥴러를 잠궈 uC/OS-III 커널 코드 자체가 태스크 수준에서 동작한다는 것입니다.

커널 오브젝트 타입

uC/OS-II에서는 세마포어나 뮤텍스와 같은 커널 오브젝트를 모두 OS_EVENT 타입으로 정의했는데 어떤 용도로 사용할 것인지에 따라 쓰임이 달랐습니다. (물론 이벤트 플래그는 예외입니다.) uC/OS-III에서는 커널 오브젝트에 대기 중인 태스크 리스트나 Name 필드와 같은 커널 자료 구조의 공통적인 필드들을 동일한 오프셋에 위치 시키고 새로운 타입으로 정의하고 있습니다.

소스 코드를 확인하지 못했지만 공통적인 필드들을 동일한 오프셋에 위치 시킨 이유는 커널이 커널 오브젝트를 다루는 방법이 거의 비슷하기 때문일 것입니다. 커널 오브젝트에 대기중인 태스크 리스트를 얻어 오거나 대기할 태스크를 등록하는 코드 등이 예일 것입니다. 커널 코드 자체도 공용으로 사용하여 줄이자 라는 심보(?!)인 것 같습니다.

커널 오브젝트 대기 시간 측정

커널 오브젝트에 공통으로 TS (Timestamp) 필드가 선언되어 있습니다. 예를 들어 세마포어 대기 함수의 시그너처는 다음과 같습니다.

OS_SEM_CTR OSSemPend( OS_SEM * p_sem, OS_TICK timeout, OS_OPT opt, CPU_TS * p_ts, OS_ERR * p_err);

p_ts라는 인자에 CPU_TS 타입의 변수를 넣고 호출하면 OSSemPend가 깨어나는 시점에 Timestamp 값이 저장됩니다. (깨어나는 시점에는 시간 경과, 세마포어 획득, 세마포어가 삭제 등 다양한 경우가 있을 것입니다.) Timestamp 값은 시그널 용도로 세마포어를 사용할 때 의미가 있다고 합니다. OSSemPost로 시그널을 보내면 OSSemPend()에서 대기 중이던 태스크가 깨어나게 되고 이 때 Timestamp 값을 얻습니다. 현재 Timestamp 값과의 차를 이용하면 시그널을 받는데 얼마나 경과되었는지 알 수 있습니다. 시간에 예민한 애플리케이션에는 아주 유용할 것 같습니다. 물론 바이너리 세마포어로 공유 자원을 보호하는 목적이라면 Timestamp 값은 큰 의미가 없을 것입니다.

Timestamp 값으로 Tick 카운트를 저장하면 충분할 것이라 생각했는데, Free-running counter를 사용하라고 권고합니다. Tick 카운트가 대략 100 hz ~ 1000 hz 정도로 발생하는 것을 감안하면 ms 단위이나 하드웨어 타이머 컨트롤러를 사용하면 us 혹은 ns 단위의 Resolution을 얻을 수 있겠습니다.

‘uC/OS-III – The Real Time Kernel’은 많은 영감과 깨달음을 주는 훌륭한 지침서임에는 틀림 없습니다.