前回は、Arm Mbedコンパイラ上で、BBC micro:bitのBluetoothサービスを起動するオブジェクトを生成し、スマホとペアリングさせてその動作を確認いたしました。しかし、例によってドキュメントもよく読まずにやっているのでペアリングにはテコずり、他にも不明な点がポロポロと。今回は一度立ち止まって文書を確認しましたです。
※「モダンOSのお砂場」投稿順Indexはこちら
使用させていただいております開発環境は、Arm社純正の「無料」Mbedオンラインコンパイラ環境であります。BBC micro:bitを「プラットフォーム」に選び、さらに英Lancaster大起源のライブラリを導入し、「MicroBitオブジェクト」をインスタンス化しての利用でした。さてMbedオンラインコンパイラには各プラットフォーム毎のドキュメンテーションが存在します。BBC micro:bitについては以下のページです。
しかし、上記を「読んで」ちょっと慌てました。上記にBBC micro:bit v2が含まれていないことは認識しておったのですが、よく読むと（以下引用させていただきます。）
Only the BBC micro:bit V1.3x is currently supported in the mbed online compiler. If you have the V1.5 or the V2.0 device, you will need to use the offline development tools provided for the micro:bit
オヒョヒョーい、V1.5とV2.0は「オフラインツール」でやれってか？前回は、v1.x系ならオンラインコンパイラ使えると早合点で V1.5 使っております。だいたい手元にはV1.5とV2しかありません。問題がでなかったのは僥倖と。まあ、V1.3とV1.5の差は搭載されている周辺チップの違いだと思います。SoCであるnRF51そのものには変わりないので、V1.3とV1.5のハードの差に気をつければ、V1.5で多分大丈夫に違いない、と勝手に解釈いたしました。
気を取り直すと、上の記述からはオフラインツールを使えばV1.5どころかV2.0でもMbed使えるような書きぶりです。Mbedについても今後オンラインコンパイラからオフライン環境への移行を考えないとなりませんな。しかし、上記の記述を頼りにWebを探ると、V1.5やV2対応については
micro:bit のディベロッパコミュニティーに丸投げ
であることに気づきました。まあね、後でね、調べてみるわね。
必見のページあり
前回ペアリングがうまく行かない、ということで関連のYouTubeビデオを拝見させていただきました。それを参考に MicroBitConfig.h を変更してペアリング成功いたしました。ただ、変更の内容については定数のお名前からオボロゲに想像するに留まっとりました。しかし、以下のページに行けば、ちゃんと各項目の説明があるのであります（ペアリングの件は書いてないですが。）
Advanced Features of the Runtime
このページを読みながら MicroBitConfig.h のチューニングに取り組むべきかと思いました。だいたいMbedコンパイラでビルドした結果をみると、本来16kBあるはずのRAMのうち、Mbed環境で使用できる容量は6kBくらいという表示です。残りはどこいったの？への一部回答が上記にありました。
Bluetoothが8kB使っている
みたいです。ほえほえ～、半分がBluetooth、重いとは思っていたけれども半分か。まあ、絶対量で言えば8kB、最近の大容量マイコンであれば大した容量ではないですが、16kBに対する8kBなので比率がでかいです。アプリが6kBなので、残り2kBを誰が使っているのか今のところ不明（Mbed OS本体使用か？）です。なお、同じ無線物理層の上ながら上位のプロトコルが超簡略化されている「Radio」はBluetooth8KBを捨てても使用可能みたいです。軽い！micro:bit同士で通信するだけならば、こちらの方がお得かも。
FiberとThread
またMicroBitオブジェクトを読んでいて気になったものが３つあります。
- Fiber
- Message Bus
- ManagedString
Fiberは一種のThread的な構造のようですが、Threadとは異なりプリエンプティブではないみたいです。説明を読む限りコルーチン、AsyncIO的な制御構造のようです。Fiberそのものは一般的な概念だと思いますが、Mbed OS上ではMicroBitオブジェクト使用時に使える特有の構造だと思います。以前にThreadとAsyncIOを比べた投稿しているので、ご参考まで以下に貼り付けておきます。
IoT何をいまさら(79) Python, theradingとasyncioなLチカ
以下、私の勝手な認識ですが、
- Mbed OS 5、Mbed OS 6の場合は、標準設定でRTOS機能含まれており、その場合、プリエンプティブなThead単位で並行処理を行なうことができる。
- Mbed OS 2の場合は、RTOSが別建て？になっており、RTOSを使用するようにプロジェクトを構成しないと（できるできないはプラットフォームによる？）とThread単位での実行はできない。
Mbed OS 2上で実行されている MicroBitオブジェクトの場合、RTOS機能そのものは内部に取り込まれていないと想像されます。独自にFiberというプリエンプティブでない並行処理的な構造を自身で作っておる、という理解です。各FiberはIO待ちになったら自ら制御権を手放し、実行できる他のFiberが制御権を獲得するという感じですかね。
なお、Mbed OS 6には「ベアメタル」というプロファイルがあります。標準設定で含まれるRTOSの全体は含まれず（一部のRTOSのAPIは使える)、Mbed OSのコア部分のみを使用することができるプロファイルみたいです。
どうもこれがMbed OS 2からMbed OS 6へのポーティングの受け皿みたい。
Porting a target from Mbed OS 2 to Mbed OS 6 bare metal
その次のMessage Busは、イベント発生とその待ち受けのための仕組み。ぶちゃけ On Receiverナンチャラとか書くときに必須の制御構造だと思います。BLEで受信をキッカケに何かやろうとしたら避けて通れませんな。
ManagedStringは、C#やJavaのString的なもの。null末端のCの文字列がいろいろヤバい事を起こすので、こちらの方が安心じゃろう、という親ごころかも。
ドキュメントを読んだおかげで、多少頭の中がスッキリしたです。ほんとか？