鳥なき里のマイコン屋(45) ARM Mbed その3、OS2種類、どっち?

昨日も書きましたが、Mbedという「開発環境」は、Mbed-OSという「実行環境」と不可分なようです。しかし、そのOSに2種類というか2バージョンあるのです。「彼ら」の呼び方で

OS 2 と OS 5

です。途中の3とか4はどこにあるの?とか、OS 2といわれると、その昔のIBM OS/2を思い出してしまうのですがね、とか閑話休題。そんな2種類あると言われると、どっち使ったらいいものか、まずは両方調べないとならないな、などと思うのです。ところが、Webベースの開発環境で、プログラムの新規作成を選ぶと、ひな形にするテンプレートを選んだ時点で勝手にどちらかに設定されています。特になんのお断りもなし。そんなOSのバージョン知らなくても無意識に使えてしまう?のがちょっと怖い。

※「鳥なき里のマイコン屋」投稿順Indexはこちら

まずは、MbedのホームページでOS 2とOS 5の違いを説明しているページへのリンクを張っておきます。こちら。それ読めば分かるじゃん、ということなのですが、面倒くさがりの人のためにこちらの拙い理解を書いておきます。

    • OS 2は、スレッドセーフでない。RTOSでもない。
    • OS 5は、スレッドセーフでRTOS。

さらに混乱するのですが、どうも Mbed-RTOSというものもあったようで、こちらの勝手な理解を重ねて書くと

Mbed-OS 5 > Mbed-OS 2 + Mbed-RTOS

といった関係であるようです。しかし、OS 5は OS 2に対する「上位互換性」はかなり高いようで、簡単なプログラムであれば、ほぼそのまま移行できる感じです。ただし、もともとスレッドセーフでもない、リアルタイム性もない OS 2上で「苦しんで」リアルタイム化したようなコードは、ネイティブでRTOSなOS 5に持ち上げるときにはそれなりな始末、多分、見通しよくなる方向だとは思うのですが、が必要そうです。

じゃ、新規開発なら全部 Mbed-OS 5にすればいいじゃん、と思うかもしれませんが、そうでもない、ということは確かめてあります。

プログラムサイズが違う

そこで、敢えて定番の「ループでLチカ」プログラムをMbed-OS 2 と Mbed-OS 5の両方でコンパイルしてみました。

Mbed-OS 2版、Flash使用量 18.3kB RAM使用量 1.3kB

Mbed-OS 5版、Flash使用量 38.6kB RAM使用量 7.9kB

どちらも ターゲットのNUCLEO-F072RBボードの上でLED2をチカチカと点灯しましたが、フットプリントは段違いですね。もちろん、コンフィグレーションを変えることはできるので上記の量はその辺いじれば多少変わってくる筈ですが、OSである以上ある程度の容量は必ず必要になると思います。「ループでLチカ」の本体プログラムなど実際のオブジェクトは数十バイトだと思うので(OSぬきにベアメタルなハードの上でアセンブラで書いてもそんなもの)、上記程度のフットプリントはほぼそのままOSを動かすためのものでしょう。すると

小容量のMCUでは、OS 5 が動かないケースもある

ことが予想されます。実際、Mbed対応の評価ボードを調べてみると、Flash搭載量32kB程度のMCUを使っている品種では、OS 2 のみ対応となっていました。ターゲットボードの説明ページに、このボードはどのバージョンのOSまで対応とちゃんと書いてある上、Web上のIDEはボードを認識してコード生成をするので、間違いようはありませんが、

RTOS機能使うなら大きめのメモリを積んだ機種にしとけ

ということですね。今回ターゲットに使った機種は、多少古い(その上もらいもの)とはいえ、Flash128kB、RAM 16kBで、Mbed-OS 5 対応であったのはラッキーでした。

使用する機能によって、実際のオブジェクトにリンクされるOSオブジェクトは異なる(つまり必要な機能を選んでリンクしてくれている)ようなので、プロジェクトをイクスポートしてどんなファイルが出てくるのかも見てみました。出力先は、一番何も無さそうな

GNUツールチェーン、ビルドにはMake

という選択にしてみました。OS2の場合は、OS機能は小さなバイナリのオブジェクトファイルが多数(90くらい)出力され、それに対応するヘッダファイル類も多数。オブジェクトファイルの総量は600kBくらいありました。全部リンクしたらとてもFlashに入りきらない機能テンコ盛りです。機種依存性を吸収するためのHALのレイヤのオブジェクトなども含まれます。この方法は、

直接ターゲットMCUべったりで書くよりはきっと大きめになる

に違いないですが、特定MCUのハードなど知らないでも開発できるのが最大の利点でしょう。さらに言えば、他社のMCU(当然同等の周辺そなえたArmコア)に移行しやすいことも利点(欠点)とも言えます。

    • 開発するユーザサイドはハッピー
    • マイコン売る半導体屋はユーザを囲い込みしにくいのでアンハッピー

てな感じでしょうか。でも、こんなに「お手軽環境」あるのに「乗らない」でいると

Mbedに対応していないマイコン屋はスタートラインにも立てない

かもです。

IoT向けにArm Cortex-M マイコン売るならMbedサポート必須

と書いておきます。マイコン屋各自の商売はその先で考えろということでしょう。

なお、OS5でイクスポートする場合は、バイナリは含まれないソースコード(さすがにブートのところとかはアセンブラ)類が出力されました。上記の機種の場合約24MBくらい。Web開発環境ではたった数行のC++のプログラム書くだけでも、その裏側では、それだけの分量のコードから「見繕って」コンパイル、リンクしてくれているわけです。通常だと、そういうビルド環境を作るところだけで結構疲れてしまって、なかなかアプリに行きつかない。。。

鳥なき里のマイコン屋(44) Arm Mbed その2 printf、OSのお陰 へ戻る

鳥なき里のマイコン屋 (46) Arm Mbed その4 Mbed-CLI へ進む