省フットプリントで安定かつ高速な「scmRTOS」からRTOSの基礎を学ぶ：リアルタイムOS列伝（23）（2/3 ページ）

IoT（モノのインターネット）市場が拡大する中で、エッジ側の機器制御で重要な役割を果たすことが期待されているリアルタイムOS（RTOS）について解説する本連載。第23回は、20年近い歴史を持ち、省フットプリントと高速を特徴とする古典的RTOS「scmRTOS」を紹介する。

[大原雄介，MONOist]

8／16ビットのサポートが継続されているのがうれしい

　ちなみに初期のscmRTOSは、開発環境というかコンパイラがIAR EC++に限られていた。恐らくテンプレートをIAR C++に依存する形で利用していたのだと思われるが、途中からgccにも対応を追加しており、現在もIAR C++とgccというかg++の両対応の形でリリースされている。プラットフォームとしても、先述したようにMSP430／AVR8の他に、Armv8M／ARM7／STM8が加わっている。8／16ビットのサポートが継続されているのがscmRTOSの特徴でもあり、昨今の32ビットサポートをメインにしているRTOSでは難しいケースで使えるのはちょっとうれしい部分だ。ちなみにライセンスはMIT Licenseである。ソースコードの著作権そのものはscmRTOS Team（実質Zhurov氏）が保有するが、商用を含む全ての用途で自由に利用ができる。

図1　GitHubの「scmRTOS」のブランチ。最新アップデートは2021年2月で1年以上更新されていない［クリックでWebサイトへ移動］

　さてscmRTOSの特徴をもう少し。scmRTOSは最大で16までのプロセスを管理できる。ただしこれらのうち1つはSystem idle processとして予約されているので、アプリケーションは最大15までである。また全てのプロセスは静的な構成になっており、動的なプロセスの生成／削除はできない。スレッドには未対応、というかスレッドの概念は導入されていない。プロセス制御はプライオリティベースになっており、プライオリティの値はuint8で設定されているので最大255レベルと思われる。また、ユーザーが独自のプロセス制御をフックして介入することも可能である。

　割り込みのハンドリングも独特である。一般に割り込みのハンドリング方法としては2種類ある。1つはDirect program control flow transferというもので、ごく一般的なISRの作法だ。割り込みが入ったら現在実行中のProcess Contextを保存してからISRルーティに制御を渡すというやり方で、ISRルーティンを起動するまでの処理時間は短いがProcess Contextの格納のために余分なRAMを消費する。もう1つがSoftware interrupt program flow transferというもので、割り込みをハンドリングする専用のプロセスを用意しておき、ここがまとめて割り込みを受けた上で、割り込みの内容に応じて対応するプロセスに通知するという仕組みである。

　scmRTOSはこの両方をサポートするが、特にSoftware interrupt program flow transferはアーキテクチャによって実装方法が変わるため、一部の機種ではHardware Interruptを利用してこれを実装している。例えばAVRの場合、コンパレータからの割り込みを利用してこれを実装しているそうだ。

　Process間通信としては以下の4つが用意されている。

• Event Flag
• Semaphore Mutex
• Channel
• Message

　Channelはあまり聞き慣れないが、キュー機能付きメッセージとでもいうべき仕組みで、read()／write()以外にpush()／push_front()／pop()／pop_back()といった、キューの順序を並び替える機能が付いたメッセージだと思えばよい。