楽しく使わせていただいているArm Mbed環境ですが、そろそろCLI(コマンド・ライン・インタフェース）の開発環境についても触れないわけにはいきません。まず技術的な面からは、クラウドベースのMbed環境はソースコードからオブジェクトへのコンパイル（ビルド）はできるのですが、デバッガを使うことができないためです。もう一つはルール的な問題です。ソースコードをクラウド上に置いておくような開発の方法は、伝統的な会社の多くでは制限されているという点です。ソースコードの社外あるいは部門を越えた持ち出しについては、厳しく管理されている会社多いですものね。クラウドにソースを上げておくなどトンデモない、と。そんな場合にMbed-OS使えないのは世界を狭めてしまうので、クラウドにソースを置かず、ローカルで開発する手段が提供されています。
※「鳥なき里のマイコン屋」投稿順Indexはこちら
まず、Mbed-OSをローカル環境（自分のPCのハードディスクの上にソースファイルを置いて）開発する場合に、とりえる手段をおさらいしておきましょう。
-
- Arm Keil μVisionなどのローカルインストールされたIDE環境を使う
- Mbed Studio ベータ版を使う
- Mbed-CLIを使う
１は、Mbed以外のIDE環境で開発をするのですが、その際にもMbed環境は役に立つのではないかと思っています。Keil(現在はArm傘下になっているので純正ツールになってしまった）でも、IARでもMbed環境からビルドツリーをイクスポートできるローカルなIDE環境は多いです。それらをイクスポート先に指定しMbed環境で多数提供されているExampleプロジェクトをイクスポートすれば、該当IDE環境で使用できるビルドツリーと設定ファイルなどを一発で得ることができる筈。Mbed-OSそのものはソースでダウンロード可能ですが、該当の環境毎にいろいろ設定したりする面倒な作業をMbedにお願いしてしまえる。即、本来開発に入れて嬉しい筈。しかし、「筈」「筈」と言っているだけでは、確信が持てないです。Mbed開発環境を調べた後、KeilとかIARにイクスポートして実際にやってみるつもりです。どこまでやるかは別にして、環境によってはドタバタするのもまた一興であります。
２は、Mbed用の立派なIDE環境としてリリースされるのであろう、Mbed Studioのベータ版を使うというものです。多分これが一番自然なのだろうけれど、今のところはベータ。ベータ版のお試しが嫌なわけではないのですが、手元のボードがMbed Studioのサポート対象ではない、というのが最大の問題です。というわけで、新しいボードでも手に入れたらまたそのうちテストしてみたいということで、今回はパスです。（しかし、Armは次々に開発ツールを出してくる。それだけ力があるのだろうけれど、闇に消えた古いツール、どうなったのか気になります。）
そして、３こそ、今の手持ちのボードでMbedの開発をMbedのツールでローカルに行い得る方法です。かっこいいGUIを捨て、コマンドラインで作業する、と。昔を思い出せば普通ですかね。
まずはインストールです。このMbed-CLIそのものはPythonベースのシステムで、Pythonの標準的なインストールツールであるpipでインストールが可能です。ただし、pipでのインストールでは以下は含まれません。
-
- コンパイラ・ツールチェーン
- git
- Mercurial
私の拙い理解では、Mercurial（コマンド名はhg)は、「分散構成管理ツール」ということですが、gitとかなり被る機能が多いような気がします。しかし、Mbed-CLIは両方を要求するので両方入れておかないとなりません。実際、Mercurialへのパスを切らずに、Mbed.orgのexamplesをimportしようとしたら、Mercurialが見つからんと怒られて終わりました。また、もう一つのソース元であるgitHubからダウンロードする際には当然gitいる筈。
Windowsの場合、便利な
mbed CLI Windows Installer
というものが存在するので、必要なものはこれで一揃いインストールできます。コンパイラ・ツールチェーンは、ARM純正のARMCCが同梱されているのかと思っていたらGCCでした。MbedのWeb上の環境はARMCC系ではないかと思われたのですが、ARMCCは基本有料だし（無料お試し版は容量制限あり）、その辺考えてインストーラには制限のないGCCが入っているのかもしれません。OS 5のオブジェクトのサイズを考えるとフリー版のARMCCで開発するのは現実的でないからでしょう。勿論、有償のコンパイラを持っていれば、それらをMbed-CLIから使用することはできる設定になっています。
なにせCLIです。お好みによりシェルプログラムや環境など皆さん千差万別だと思いますし、大抵の場合、既にいろいろツールが入っていて、そいつらとの折り合いもつけねばなりますまい。その辺の始末は、
各自適当にやってくれ
とは書いてないですが、CLI使うような人は皆やっている筈。プロンプトから
-
- mbed
- gcc (勿論ARMクロス環境の）
- git
- hg
が皆起動できれば、とりあえずOKですかね。そうしたら、まずは開発のひな形用に developer.mbed.org/teams/mbed-os-examplesの下にある何かプロジェクトをimportします。このMbed-CLIという環境は基本Mbed-OS 5（OS 2相当のプロジェクトも可能なような書き方だったので後で確かめてみますが）なので、サンプルは全てOS 5です。
$ mbed import URL
でダウンロードできるのですが、Lチカのblinkyでも結構時間かかります。Mbed-OSそのものを全て持ってくるので250Mバイトとか。さきほども言いましたが、developer.mbed.orgは、Marcurialでファイル管理しているようなので、これがないとうまく持ってこれません。ダウンロードしたディレクトリの中に
mbed_settings.py
という設定用のPythonスクリプトがあり、使用するツールチェーンへのパスはこの中に書き込むようになっていました。また、このディレクトリ内にいる状態で、USBでターゲットボードを繋げば
$ mbed detect
というコマンドで、ターゲットボードが認識され、使用可能（インストールされているという意味ではない）なツールチェーンが出力されます。
ターゲット・ボードの設定は以下でできますし、
$ mbed target ボード名
複数のツールチェーンが存在しても、使うツールチェーンは、
$ mbed toolchain ツールチェーン名(GCC_ARMなど）
で指定できます。サンプルのビルドも簡単で、
$ mbed compile
で一発です（デバッグ用にビルドするのは次回。）ただし、クラウド環境では一瞬で済んだコンパイルが、ここでは相当時間がかかります。クラウドではMbed-OSのオブジェクト群などは既にコンパイル済のものがあって、リンクすれば実行可能なオブジェクトができるのでしょうが、ローカル環境では、OS本体から全てコンパイルしないとならない為です。サンプルプロジェクトで数えたら816ファイルをコンパイルしていました。また、
出来たオブジェクト、デカくね？
クラウド環境でビルドしてダウンロードして実機で走らせたオブジェクトは32KBをわずかに超える程度だったと記憶しているのですが、今回のものは64KBに限りなく近い大きさ。実機上の動作そのものは同じように見えるのですが。なにかビルド設定の問題なのか、それとも、クラウドの「純正環境」と「GCCのクロス環境」の差なのか？？
次回はようやくGDB使ったリモートデバッグに入る予定。