目次
Raspberry Pi、ArduinoとMbedとの違いは？
よく見るこれらの単語は、それぞれ異なる魅力があります。
Raspberry Piは、広く利用されているオープンソースのOS、Linuxが実行できるソフトウェア互換性が重宝され、Arduinoは、その長い歴史から来る豊富な情報量が重宝され、人気を集めています。
一方、Arm Mbedは、「IoTデバイスプラットフォーム」として、IoTにおけるソフトウェア互換性を含めた、ラピッドスタートな開発プラットフォームです。加えて、現在注目されている、クラウドへ接続するIoTデバイスの実現など、利用可能な多くのライブラリも含んでいます。
そして、Mbedは半導体のIP（Intellectual Property、知財）を持つArmが提供しており、多くの構成部分がオープンソースとなっていたり、無償で利用可能と魅力的な存在です。また「プラットフォーム」と冠するように、Mbedは、マイコンボードや開発ツール、ソフトウェア、互換性のみを定義したものではなく、これら全てを含む「開発環境」あるいは「開発基盤」です。さらには、Mbedの開発対象のマイコンボードのほとんどはArm Cortex-Mですので、そこには非常に高い互換性があります。
もちろん、Mbedの開発対象のマイコンボードに、Arduinoとのハードウェア互換性を持つボードを選択すれば、Arduinoのハードウェア互換性の恩恵も取り入れることができます。
Mbedの特徴
Mbedの特徴は次のとおりです。大事なところなので、大きめの文字で書きますので覚えておいてくださいね。
クラウド開発環境
ドラッグ・アンド・ドロップ・プログラミング
C/C++ハードウェア抽象化API
オープンソース
それぞれについて簡単に説明をしていきます。
クラウド開発環境
Mbedでは、「オンラインコンパイラ」と呼ばれる、ウェブブラウザで動作するIDEが提供されています。Keil MDK-ARMやIAR Embedded Workbenchなど商用のIDEやコンパイラは有償となり、無償のGCCで開発環境を構築するのは手間がかかります。対してMbedはオンラインコンパイラとして環境構築の必要がありません。Mbedのアカウントを作成し、ログインするだけで自分のワークスペースをクラウド上に持つことができます（もちろん、Mbedのアカウントは、登録や維持、利用に一切費用は発生しません）。
また、開発環境がクラウドにあることから、どのパソコンからでも、自分のアカウントでログインするだけで開発を継続することができます。また、開発機を変えても開発環境が一定のため、トレーニングなどを提供するときも、環境の差は発生せず、時間を浪費せずトレーニングに集中することができます。
さらには、開発したソースコードはクラウド上のオンライン環境に保管される特長を活かし、「コラボレーション」という名前で、他のユーザーとの共同作業を実現する、バージョン管理システムも統合されています。
Mbedのオンラインコンパイラに使われているコンパイラは、Keil MDK-ARMなどにも採用されているarmccです。armccは、一般的にはGCCよりも効率の良いバイナリが生成されると言われていますので、Mbedのオンラインコンパイラでビルドするだけで良いバイナリを入手できます。なお、生成されたバイナリはブラウザのダウンロード機能で自動的にダウンロードが開始され、ローカルに保存されます。
なお「開発はソースコードを規定の場所のみに保存すること（指定されたサーバ以外に保存してはいけない）」といったポリシーの会社組織もあると思います。Mbedはこういったポリシーにも対応可能で、オンラインコンパイラの替わりにMbed-cliというオフラインツールを利用することで、ローカルに閉じたIoTソフトウェア開発を進めることも可能です。
ドラッグ・アンド・ドロップ・プログラミング
さきほど、「オンラインコンパイラでビルドしたバイナリはダウンロードされる」と記しましたが、このバイナリを開発ターゲットに書き込む手軽な方法が提供されています。Mbed enabledと称される、Mbedに対応した開発ボードには、DAPLinkというソフトウェアの書き込まれたインターフェースチップというチップが付いており、Mbed enabledな開発ボードをパソコンに接続すると、USBフラッシュドライブとして認識されます。このドライブに、ダウンロードしたバイナリファイルをドラッグ・アンド・ドロップするなどしてコピーすると、開発ターゲットのマイコンボードに書き込みが行えます。
このインターフェースチップは、バイナリの書き込み（プログラム）機能のほかに、USB-UARTブリッジ機能と、CMSIS-DAPというプロトコルに対応したデバッグアダプタ機能も搭載されています。USB-UARTブリッジを使ってprintfデバッグを行うこともできますし、CMSIS-DAPに対応した開発ツールを使うことで開発ターゲットのマイコンのデバッグを行うこともできます（オンラインコンパイラでは、残念ながらデバッグを行うことはできません）。
C/C++ハードウェア抽象化API
これが、Mbedの最も便利な要素でしょう。Mbed OSではハードウェア抽象化APIが定義されています。このため、Mbed OSが移植されたマイコンで、Mbed OSを使って開発を行うと、抽象化APIを使った開発が行えます。抽象化APIを使うメリットは主に二つあり、一点目は簡単なコードで開発を行うことができるという点、もう一点はマイコンのベンダを問わず共通のAPIでアクセスを行うためにMbed enabledなマイコンどうしでのポータビリティ（移植性）がとても高いということです。
Mbed OSでLチカ
それでは、実際にMbed OSでGPIOを操作してLEDを点滅させるコードの例を見てみましょう。
#include "mbed.h"
DigitalOut led1(LED1);
// main() runs in its own thread in the OS
int main() {
while (true) {
led1 = !led1;
wait(0.5);
}
}
このようにとてもシンプルです。これをMbed OSを使わずに行うには、マイコンベンダ依存のライブラリを使うか、I/Oレジスタを操作しなければなりません。例えば、次のようなコードになるでしょう。
#include "LPC17xx.h"
void gpio_init(gpio_t *obj, PinName pin) {
if(pin == NC) return;
obj->pin = pin;
obj->mask = gpio_set(pin);
LPC_GPIO_TypeDef *port_reg = (LPC_GPIO_TypeDef *) ((int)pin & ~0x1F);
obj->reg_set = &port_reg->FIOSET;
obj->reg_clr = &port_reg->FIOCLR;
obj->reg_in = &port_reg->FIOPIN;
obj->reg_dir = &port_reg->FIODIR;
}
int main() {
PinName pin = 0;
gpio_t obj;
gpio_init(&obj, (PinName)(0x2009C000 + 31 + 8)); // P1_18
unsigned int mask_pin18 = 1 << 18;
volatile unsigned int *port1_set = (unsigned int *)0x2009C038;
volatile unsigned int *port1_clr = (unsigned int *)0x2009C03C;
while (1) {
*port1_set = (port1_set | mask_pin18);
wait(0.5);
*port1_clr = (port1_clr | mask_pin18);
wait(0.5);
}
}
ライブラリを使うにせよ、レジスタを操作するにせよ、データシートやユーザーマニュアルを読み、ベンダやマイコンに依存するコードを書かなければなりません。Mbed OSの抽象化APIを使えば、ターゲットに依存しないコードを記述することが可能です。
一方で、抽象化APIで既定されていないペリフェラルを使いたい場合には、Mbed OSのAPIを使わずに、直接にペリフェラルにアクセスするコードを書くこともできます。もちろん、インラインアセンブラを書くこともできます。
オープンソース
Mbedの面白いところは、その多くがオープンソースであることです。ソフトウェアのMbed OSもオープンソースですし、インターフェースチップのファームウェアであるDAPLinkもオープンソースです。
もちろん、オープンソースなのはソフトウェアだけではありません。Mbed enabledなボードは、ボードベンダ各社が開発とリリースをしているものですので公開状況はまちまちですが、Armが関わっているボードは、mbed-HDKとして公開されています。サードパーティーの開発ボードについても、筆者の知る限り、回路図は公開されています。
こういったオープンソースへの取り組みは、ArmはIPのサプライヤであって、Mbed OSや開発ボードそれ自体の販売による収益が目的ではないからでしょう。サードパーティーによる開発ボードも、サードパーティーの多くは半導体メーカーであるため、開発ボードの収益が目的ではないということだと筆者は受け止めています。
ちょっと難しいところ
このようなMbedですが、今から始めて使うには知っておいたほうが良いこと（ちょっと難しいところ）もあります。例えば、mbed LPC1768でLEDを点滅させるプロジェクトを試行してみるとき、プロジェクトのサンプルには「Blinky LED Hello World」と「mbed OS Blinky LED Hello World」の二種類があります。
LED点滅プログラムが二種類あるのは、mbed SDK（mbed 2.0とかClassicなどとも呼ばれます）で実装するものと、Mbed OS 5で実装するという違いがあるためです。
次に、mbed SDK（mbed 2.0/Classic）とMbed OS 5の違いについて、Mbedの歴史から紐解いてみましょう。
Mbedの歴史
Mbedは2005年に、Armの二人の社員である、Simon FordとChris Stylesが課外プロジェクトについてティーブレイクで話し合ったことから生まれました。彼らは大学生の学生プロジェクトや放課後のエレクトロニクスクラブの手伝いをしていましたが、結果が思わしくなかったのです。
アイデアは良いのですが、なかなか実現が伴わないという問題がありました。もう一つの問題は、学校のシステムはロックされていて、ソフトウェアをインストールすることが許されていないというものでした。こうして、ウェブブラウザで動くIDEと、手軽にマイコンの開発ができるAPI、パソコンからUSBフラッシュドライブに見えるプログラマ（書き込み機能）といったMbedの特徴が生まれたようです。
左からChris Styles氏、Simon Ford氏、筆者（2014年3月撮影）
【出典：mbed at Embedded World 2014】
この後、2009年にMbedは最初のリリースに至りました。この頃は「mbed」と全て小文字で呼ばれており、先述のように学生のプロジェクトを実現するような目的で作られたので「Rapid prototyping tool」（手早い試作を行う道具）と自称していました。対応ボードは、当時発表されたばかりのLPC1768を対象とした、mbed LPC1768のみでした（mbed LPC1768の日本での発売は翌2010年の2月）。この頃、筆者は8ビットのAVRを搭載したArduinoを使っていたのですが、Mbedを利用することで、ネットワークスタック（IPスタック）も手早くマイコンに積んで、イーサネットに接続できることから、Mbedに乗り換えました。
mbed LPC1768のピンアウト図【出典：mbed LPC1768】
リリース直後のMbedはオープンソースではありませんでしたが、2013年2月に「mbed 2.0」の発表とあわせてオープンソースになりました。mbed 2.0の登場から遡ること数ヶ月の2012年末には、mbed interfaceと呼ばれていたプログラマのチップに、CMSIS-DAPに対応したデバッグアダプタ機能も追加されます。mbed 2.0の登場後まもなく、初のNXP以外のマイコンを搭載したボード、当時フリースケールのFRDM-KL25Z（当時はNXPとフリースケールは別の会社でした）が登場し、ここからMbed対応（Mbed enabled）ボードが増えていきます。
2014年の10月になると、「mbed v3.0」が発表されました。ここから「mbed SDK」と呼ばれていたMbedのソフトウェアライブラリが「mbed OS」と呼ばれるようになり、2015年11月にリリースされた「mbed OS 15.11 Technology Preview」では、MINARというイベントドリブンなスケジューラーや、yottaというパッケージ管理システムなどが含まれていました。これらは、現在では「mbed OS 3」として扱われています。mbed OS 3は、先述のイベントドリブンの導入など意欲的な変更が行われたため、それまでのmbed SDKとの互換性に乏しいという問題がありました。このためか、現在ではほとんど使われていませんし、ウェブサイトの多くの記述がMbed OS 5に取って代わられ、今ではほとんど見かけません。
現在主流のmbed OS 5は、2016年8月に発表とリリースされました。リリースに掲載されていた上図からも見てとれるように、2013年にリリースされていたmbed 2.0と、2015年にリリースされたmbed OS 3を統合し、mbed 2.0からの移行がスムーズに行えるようになっています。
mbed OS 5の特徴は、mbed 2.0ではオプションであったRTOSが標準でサポートされるようになった点、mbed OS 3で導入されたパッケージ管理システムに相当するmbed-cliが導入されオフラインコンパイル（ウェブのオンラインコンパイラを使わないビルド手段）が容易になったことです。
2016年10月には、mbed Cloudがリリースされました。mbed Cloudは、ボードで閉じた開発ではなく、デバイスのクラウドへのコネクティビティを実現する手段としてDevice Connectorが提供されています。また、mbed Cloudは単なるクラウドコネクティビティの提供に留まらず、DLM（Device Lifecycle Management）など、より製品化のライフサイクルを意識した、IoTの実際の展開に沿った機能を持っています。結果として、当初Mbed立ち上げ時の目標を大きく超え、わたしたちが広く便利に使える実用的なIoTデバイスプラットフォームとして、商用利用を含む多数のユーザーが利用しています。
最後に、2017年の8月に「Arm」のロゴやテキスト表記が変わり、同時に「mbed」表記が「Mbed」に変更されました。今回歴史について説明する中は、あえて当時の表記も併用しています。
さいごに
今回は、「IoTデバイスプラットフォーム」であるMbedの概要として、クラウドへのコネクティビティや、魅力的な特長をざっくり説明してみました。また、Raspberry PiやArduinoと比較することで「マイコン開発プラットフォーム」としてのMbedの魅力も盛り込んでみました。今後の連載では、さらに人々の生活や産業に浸透するIoTデバイス開発に関連する内容を交えて、Mbedを紹介していきたいと思います。
こちらも是非
“もっと見る” Mbed編
Mbed TLSの概要と特徴
今回は、これまで何度か触れてきたMbed TLSについて説明をしていきたいと思います。TLS（Transport Layer Security）は、通信の暗号化を行うプロトコルとして、IoTのセキュリティを実現する手段の一つとして頻繁に利用されています。また、通信の暗号化だけでなくデバイスの認証手段としてもよく使われています。
どこが「IoTデバイス開発プラットフォーム」なのか
筆者がMbedを使い始めた理由は、インターネットにネイティブに接続できるマイコンボードが欲しかったからです。その頃の筆者は、中学生の頃にZ80を触って以来15年以上のブランクを経て、Arduinoを使い始めたところでした。その頃、ArduinoをIPネットワークに接続するには、IPスタックをハードウェアで実装したW5100というチップを使う事が一般的でした。
Mbed OSの概要と特徴
今回は、Arm Mbedの構成要素の一つであり、最も重要な部分であろうMbed OSについて記したいと思います。これまで書いてきたように、Mbedには大きく分けて、Mbed OS 2とMbed OS 5の二つが存在します。しかし、Classicと呼ばれるようにMbed OS 2はメンテナンスモードですので、今回はMbed OS 5についてのみ記したいと思います。
