目次
組み込みシステムにおけるリアルタイムOSとLinux
組み込みシステムの構成を考えていく上で、どのOSを採用するかは、開発初期段階においてとても重要です。
特に、時間的な制約を中心に考えるのか、使用するミドルウェアなどのソフトウェアを中心に考えるかで、大きく異なります。一般的には、時間的制約があるシステムの場合はリアルタイムOSが向いていると言われています。一方、ネットワークやファイルシステム、高度なグラフィカル表示が必要な場合はLinuxが向いていると言われています。もちろん、要件によってどこまで妥協できるかは、コストや開発期間など、一概に決められない要因もたくさんあり、正解もありません。
ただ、有償無償のソフトウェアの組み合わせを考えると、必ずしも上記の構成をとるとは限りませんし、混在することも増えてきています。リアルタイムOSの場合、CPUやCPU周りの性能向上により、ワンチップでできることがだいぶ増えてきました。Linuxの場合、当然大きなメモリやストレージに相当する記憶装置（フラッシュROMやeMMCなど）が必要ですが、今後の拡張や共通プラットフォームという考え方も普及しているので、コストメリットの享受も。
さらに、基板のサイズなども選択肢に入りますが、このあたりは製品の形状・デザイン・仕様により大きく異なると言えるでしょう。
リアルタイムOSとLinuxを選択する上での指針
高精度な計測をしながら、グラフ描画を行う
さて、ここからは、上記の条件で組み込みシステムの構成を考えていく場合、リアルタイムOSかLinuxかを決める簡単な指針を考えてみたいと思います。
①処理速度
計測は、1ms以内に10000サンプルデータを取る必要がある。
②デバイスドライバ
計測したデータは、100サンプルのデータを平均化して、ストレージに保存する。
③処理速度
ストレージに保存されたデータからグラフ表示を行う。
こういった場合、高速なマイコンを使った方がいいんじゃないかと、なんとなく思うのではないでしょうか？そう思わせるのは、「ある時間以内の処理」が明記されているからだと思います。これをリアルタイムOSで実装していく場合の考え方と、Linuxなどのシステムで実装していく場合の考え方を、それぞれの指針ごとに見ていきましょう。
①処理速度
まずこの条件に見合った処理を行うには、1サンプルデータあたり、100ns必要であると言うことが分かると思います。つまり、1つのプログラム実行サイクルが、100ns以上かかってしまうシステムでは、すぐに破たんしてしまうと言うことが分かります。ちなみに、100nsは、10MHzで動作することが最低限の条件になります。このあたりだと、まだマイコンでも十分です。Cortex-M0では40MHz近辺で動作するものも多いので、1クロック当たり25nsになるので、このあたりでもなんとか動かせるところですね。
ただ、これをLinuxのシステムで動かすとなると、40MHzでLinuxを動かすのは・・・現実的ではありません。少なくとも数100MHzの動作環境が必要で、最低でもCPU400MHz以上のシステムにしないとLinuxを動かすことが難しいことは、想像できそうです。MMUを搭載しないタイプのLinuxであればもっと遅いクロックでも何とか動くかもしれませんが・・・あまり現実的ではないですよね。
あくまでも最低条件での見積もりなので、実際には他に重なる条件などもあり、これだ！という断定はできませんが、あえて提示すると、下記のようになるかもしれません。
- データサンプリングして計算するなら、Cortex-M3/4で40MHz以上で動作するもの（いっぱいありそうですね）。
- Linux前提だと、Cortex-A系400MHz以上が前提。
- デュアルコアやヘテロコアで使うのもあり。
【補足】たくさん選択肢がありそうなら、次の選択基準は「省電力」やペリフェラルの数であると言うことは言うまでもありませんよね？上手に選んでいきましょう。
②デバイスドライバ
次に着目すべきは、デバイスドライバですね。最近では、Armマイコン系を中心にCMSISのドライバがほぼ標準で用意されています。ペリフェラルのドライバが重要であると言うことは、どのデバイスベンダーさんもわかっていますね。とても便利になったと思います。昔は、自分で作ったりしていましたが、今はあまり作っていないですね。
さて、なぜデバイスドライバが重要なのか？ということをわざわざ語る必要はありませんが、SoCに搭載されているDMAをうまく活用することが一つのシステム性能向上につながるからだと思っています。DMAを活用できれば、CPUの負荷を分散しながら、高いパフォーマンスを発揮することができるのです。さきほどの1サンプル100nsの時間でデータ処理を行う場合でも、DMAが指定したメモリにサンプルしたデータを転送してくれれば、CPUのクロックはもっと遅くても間に合います。
もし、Linuxのドライバがなかったら。デバイスベンダーさんが用意しているかどうかで変わってきます。ここ近年はドライバを用意していないことは少ないですが、すべてのシステムに対応できるかどうかは別の話です。特にメモリマップは、ボード構成によって変わってくることが考えられます。DMAを使いこなすうえでも、このあたりは理解しておく必要があり、レアケースかもしれませんが、デバイスドライバに手を加えなければいけない状況になることもあり得ます。
また、ほとんどのペリフェラルは、DMAに対応していることがほとんどなので、作りこむ必要はあまりないのかもしれませんが、完全に実装できているかどうかは別の話です。割り込みのタイミングとなるFIFOの制御も、アプリケーションで指定したりするはずなので、ドライバがあれば何でもOKというほど簡単ではありません。でも、1から作るよりは、ぐっと楽なはずです。APIをただ呼び出すだけではなく、そのソースコードを熟読した上で、提供されたドライバを使うようにしましょう。
リアルタイムOSで実装した場合、リアルタイムOS側でドライバを用意していることもありますが、特殊なペリフェラルほどドライバがないのが現状です。リアルタイムOSはカーネルが動作するための最低限のドライバは用意していますが、それ以外はユーザ実装となっています。自由に組める代わりに、その労力も必要になってくるわけです。そうすると、デバイスベンダーが用意したドライバを使うことになりますが、リアルタイムOSとの連携は考慮されていないので、手を加えながら実装することになると考えておいた方がいいでしょう。
デバイスドライバはペリフェラルによって、キャラクター型デバイスであったり、ブロック型デバイスだったりしますので、自分のシステムに合うかどうか、ソースコードを読み込む時間も設計時には考慮しておくといいですね。
③描画処理
描画処理だったらLinuxを選択した方が、楽だろうな？と誰もが思うことでしょう。Qtを使う方法や、Web系のリソース（HTMLとCSSやJavaScript）などを使う方法もありそうですね。もちろん、専用のGUIツールやミドルウェアも世の中には存在します。簡単な表示だけなら、ミドルウェアを使わない方法もたくさんあると思います。
一口に描画と言っても、いろいろな切り口がありますが、一番重要で描画に必要なリソースは、メモリです。フラッシュROMのメモリではありません。ワーキングエリアで使用するSRAMやDRAM（DDR）です。表示は見た目が大事なので、いかに早く描画するか？が重要になってきますし、商品価値を高めることに繋がります。そのため、通常は表示する画面サイズとほぼ同じ要領のメモリを最低でも2つ持ち合わせるなどの方法で、高速な描画を実現させることになります。その場合、それなりにメモリが必要です。
例えば、モノクロVGA表示の場合、640×480のサイズなので640×480÷8=38.4Kと計算できます。モノクロでも38.4KBytesが２つ分必要です。R,G,Bのカラー表示の場合、8ビット（256階調）として、640x480x3=460.8Kとなり、460.8KBytesになります。画面バッファだけでも、1MBytesになりそうです。最近では、大容量SRAMを搭載したマイコンが増えてきましたが、プロセッサと外部SPIフラッシュとDDRのBOM価格と、大容量SRAM搭載ワンチップマイコンと比べると、大きな差はなくなりつつあるようです。
ハードウェア的な差がなくなってくるとすれば、Cortex-A搭載のSoCが選択肢として優位です。メモリも、DDRなど高速なメモリを使えると、もっと大きな画角の表示も可能です（参考：画角別メモリサイズ一覧）。
| QVGA | 320x240x3(RGB)=230.4KBytes |
|---|---|
| VGA | 640x480x3(RGB)=460.8KBytes |
| XGA | 1024x768x3(RGB)=2.36MBytes |
| WXGA | 1280x768x3(RGB)=2.95MBytes |
| 1280x800x3(RGB)=3.07MBytes | |
| 1366x768x3(RGB)=3.15MBytes | |
| FullHD | 1920x1080x3(RGB)=6.22MBytes |
| 4K | 3840x2160x3(RGB)=24.88MBytes |
こうしてみると、表示するにもかなりのメモリが必要になることが分かりますね。システム上では、「フレームバッファ」という扱いでこれらのリソースが確保されているのではないかと思います。
さて、Cortex-A系を選択すると、リアルタイムOSのバリエーションが一気に少なくなるのが難点です。もちろん、対応しているソリューションはいくつかありますが、有償系が多くを占めてきます。Cortex-Aを無償のリアルタイムOSで使える例は、一部のTRON系カーネルに絞られていると考えていいと思います。
マイコンなどのCortex-M系を選択すると、リアルタイムOSは選択肢としてありえますが、描画処理およびライブラリが不十分であることが懸念されます。マイコンによっては、描画エンジンを搭載しているものもあります。ただ表示するだけであれば、LCDパネルのコントローラにデータを投げ続ければ表示はしてくれるので、上の表で示したようなメモリはなくても表示はできます。しかし、滑らかな表示や高速な描画を行うには、表示サイズと同じメモリサイズを使用し、DMAでデータを送り続ける処理を行うのが重要なので、これもデバイスドライバの性能によって変わってきます。最近では、LCDコントローラ内蔵タイプのマイコンも増えていますので、描画処理も点や線などの簡単なライブラリであれば、それほど実装は難しくはないと思います。
ちょっとハードよりの話になりすぎたのでソフトよりの話をすると、グラフ表示する場合は動かさない軸を描画して、表示すべきデータを一定間隔で更新することが重要です。この間隔が細かいほど滑らかの描画が実現できそうですが、もたついてしまうとがっかりな表示になってしまいます。このバランスが非常に難しいところだと思いますが、全体を再描画するよりは、負担はぐっと減りそうです。
描画すべき領域を指定して、その部分の更新データを定期的に書き換えていくことで、グラフ表示の実装ができるようになります。更新すべきメモリ領域を絞り、描画すべきデータを書き換えるというのが、一般的な手法です。グラフ表示する場合は、表示領域内でプロットする位置や座標を等間隔で動かしたり、線をつないでいくことになります。レイヤ機能があると、このあたりの描画も設計しやすいですね。
結局リアルタイムOSとLinuxのどちらを選択したら良いのか？
長々と書いてきましたが、もうどちらを選んでいいかわからなくなりました（笑）。APS的に簡潔にまとめると、こんな指針でどうでしょうか？
●マイコンでリアルタイムOSを使う場合は、クロックが速く、外部外付けメモリを増やす。
●プロセッサでLinuxを使う場合は、リアルタイム処理で必要となる部分をドライバのDMAと連携させることが可能かどうか？
●デバイスやソフトの習得までの時間と費用のコストに見合うか？
こちらも是非
“もっと見る” RTOS編
Toppers/ASP3の使い方
SOLID-OSによる割り込みは、Toppers/ASP3がベースになっており、カーネルの管理下で割り込みの処理を行いますので、「割り込みサービスルーチン（ISR）」または「管理内割り込み」と呼んだりします。それ以外のものは、「割り込みハンドラ」もしくは「カーネル管理外割り込み」と呼びます。
組み込みソフトウェア開発にRTOSを採用する場合の「4つの心得」
リアルタイムOSを使った組み込みソフトウェア開発を行う際、覚えておいたほうがよい「4つの心得」を紹介しましょう。
割り込み
割り込みは、タスクとは独立して実行される処理です。そこで、T-Kernelにおける割り込みの利用方法に加えて、実行時のコンテキストの違いから生じる動作の違い、割り込みハンドラの作成方法や動作の詳細を説明します。