鳥なき里のマイコン屋(44) ARM Mbed その2, printf, OSのお陰

第42回で「開発時に使うけど実行時には使わないソフトウエアを主に」などと方針を述べたのですが、この Mbed というWebベース(クラウド)の開発環境については実行時に必要なソフトウエアを抜きに語ることはできません。

Mbed-OS

という ”RTOS” があること前提の開発環境だからです。また、ブラウザ画面の中で開発ができる、という便利さの反面、当然、制約事項もあります。しかし、そこも含めて結構良く考えられている環境ではないかと思います。

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

まずは、ブラウザ画面の中での開発の最大の制約事項だと思われること、をあげておきましょう。

デバッグ

です。ブラウザ画面の中でソースコードの編集などは通常のIDEを使っているのとほとんど遜色なくできます。コンパイルも簡単。ボタン一つで実機で実行可能なオブジェクトが出来、それを実機にコピーすれば直ぐ起動するのは前回すでに報告した通りです。しかし、デバッグ、どうしたら良いのでしょう?普通の開発環境であれば、デバッガ画面を開いて、ソースコードの頭をクリックしてやれば、所望のところにブレークポイントを張ることができます。実行ボタンを押して実行後、ブレークで止まれば、変数の値をチェックしたり、メモリをダンプしたりといろいろできるのが普通。しかし、さすがにWeb上の開発ツールが、ブラウザの先のローカルPCのハードの先のターゲットボードと通信してそんなデバッグをやるのはかなりキツそう(ボードの識別ではこれに近いことをやっている筈ですが、1回だけだし。)デバッグには3通りの方法が考えられます。

    1. 他のローカル環境”IDE”にプロジェクトをイクスポート
    2. Mbedのローカル環境である Mbed-CLIをインストール
    3. WebベースIDEにprintfデバッグ併用

ローカル環境というのは、ターゲットボードに接続している「目の前の」PCの事です。第1の方法は、他の本格的なIDE環境(勿論、インストール必要)を入れておき、Webベース環境からプロジェクトを「輸出」すればそれら環境のデバッガが使えるじゃん、というもの。Webベースの環境でやってきたのに何?という感じもしますが、Mbedは、実に幅広い各種開発環境をサポートしていて、Keil、IAR, Gnuなど皆さんお使いの「どれか」にプロジェクトをイクスポートできるので、もともとツールを持っていた人にはこれも正解でしょう。でもその時Mbed使う意味は、と聞かれれば、プロジェクトに

Mbed-OS

を含めてくれる、という点でしょうか。イクスポートされるプロジェクトにはOSのオブジェクト類やヘッダなどが含まれているので、そのままMbed-OSを使った開発が続行できることになります。なお、Mbed自体のローカルなIDE環境のベータ版を提供中です。しかし、残念なことに今回ターゲットにしている古いボードは対象外。残念。

第2の方法は、Mbed自体がローカル環境として現状サポート中のCLI環境を使うというもの。このCLI、Pythonベースです。これからインストールして使ってみる予定です。使った後でまたレポート予定ですが、ドキュメントによればCLIツールを使うと、ビルドできるだけでなく、シリアルデバッグ用のサーバを設定して、GDB使ったリモートデバッグも可能となる筈です。

何が無くてもGDBあれば

デバッグはまず何でもできるのでOKと。

第3の方法は、ソースの編集とコンパイルはWebツール使って、後は、

クラシックな printf デバッグ

でやるじゃん、という力技ですね。しかし、ターゲットボードには標準出力などを映し出す画面などついていないですから、どこにprintfするかといえば定石どおり

シリアルポートへ

です。使用するMCUによってシリアルポートもいろいろある筈ですが、その辺はHAL(Hardware Abstraction Layer)のお陰で非常に簡単に設定できます。しかし、実シリアルポートに出力するとなると、

ターゲットボードのシリアルポート端子Tx, Rxを取り出してパソコンのUSBシリアル変換アダプタに接続する

ことが必要ですね。幸いターゲットボードの端子の仕様など皆Web画面の上に表示されるので情報を探し回る必要はありませんが、USBシリアル変換アダプタ、どこかに持っていた筈なのだけれど出てこない。。。探し回るくらいなら、もともとターゲットボードがUSBにパソコンと接続されているのでその接続を「シリアルポート」として使える機能くらいきっとある筈、そう思って探してみると

Serial pc(USBTX, USBRX);

こんなSerialポートのクラスインスタンスを作れば、パソコンと接続されているUSBをシリアル入出力で使えることが分かりました(上記設定はMbed-OSのOS2の場合、OS5の場合はデフォルトでUSBシリアルに出力されてきました。)このインスタンスを使って

pc.printf(“あとは適当に…

とやって出力すればOK。パソコン側はというとデバイスマネージャを開けば

Windows10であれば、該当ボードの仮想シリアルポートが既に見えている

ので、そのCOMポートを対象にお好みのターミナルソフト(私は伝統的なTeraterm派ですが)を立ち上げればOK。getc()使えばターミナルに入力したものがターゲットに渡ります。ただし、Windows8以前は、どうも別途ドライバのインストールが必要であるようなことが書いてありました。Linux系も不要みたいですが。

それにしても、Mbedでプログラムを書くと

    • 組み込み用のマイコンで printf などできるなんて邪道だ
    • 組み込みなのになんでプログラムを main から始められるの?
    • ぜんぜん、I/Oアドレスとか、ポートのビット位置とか出てこないじゃん

など、「ベアメタル」なマイコンでプログラムを書くときとの巨大な落差(と言って楽な方への落差なのですが)に戸惑います。その全てが、Mbed-OSとMbed開発環境のお陰ですね。Mbed環境でプログラムを書けば、裏側に「もれなくOSがついてくる」ので、ブートコードどころか、デバイスドライバとかミドルウエア的なものもほとんどお任せで結構。そのうえHALが充実しているので、同じプログラムを異なる会社製の異なるマイコンに移植するなどボタン一つ(必要なリソースを積んでいれば)で可能な場合もあり。それどころか、Mbed-OS向けの「エコシステム」で誰かが作ったコードにアクセスするのも容易にできそうです。

鳥なき里のマイコン屋(43) Arm Mbed その1、お手軽すぎて? へ戻る

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