大原雄介の半導体業界こぼれ話
Raspberry Piに取って代わられた「Mbed」の終焉と、「PIC64」によるRISC-Vの夜明け
2024年7月17日 06:14
今月も雑談を2つほど。
Mbedの終焉
7月11日、Armの「Mbed Support Forum」に「Important update on Mbed - End of Life」というお知らせが載り、Mbed platform及びMbed OSが2026年7月に終了(EoL)を迎えることが発表された。
Mbed(当時の名称はmbed)はもともと、Arm(当時だからARMか)がNXPと共同で開発した「Rapid Development Platform」という位置づけだった。どの辺がRapidか? というと、開発環境がオンラインで提供されており、インターネットにつながったPCにUSBでmbedボードを接続するだけで、開発→ロード→デバッグまでが全部Webブラウザ上で可能となっていた。
もっともデバッグといってもJTAGポートで接続されているわけでもないし、USB経由でJTAGポートに接続できる訳でもないので、製品としての組込みシステムを構築するにはいろいろ難しいというか、ホビー用の範疇を脱するものではない。
ちなみにNXPもこれはよく理解しており、きちんとビジネス向けの組み込み用にはLPCXpressoというシリーズを提供しており、こちらはLPC-Linkと呼ばれる独自Link経由でDebugポートにアクセスできるようになっている。
最初に提供されたボードは「mbed LPC1768」で、これはLPC1700シリーズに属するLPC1768というCortex-M3ベースのMCUを搭載している。
この当時は自作向けということで言えば「Arduino」(まだArduino Unoが出る前の、Arduino Duemilanoveの時代)が広く利用されていたが、こちらに比べてCPU性能が高く、周辺回路も豊富だった。なんせ8bit AVRの20MHz駆動とCortex-M3の100MHzでは性能的にも比較にならないし、32KB Flash/2KB SRAMと512KB Flash/32KB SRAMでは扱えるプログラムサイズやデータ量も全然違う。
個人的には、「Arduino Duemilanove」に搭載されていたATmega328のADCは解像度が10bitで、またArduino IDE上のSketchからだとサンプリング速度がどうしても遅くなるのが、mbedだと解像度も12bitと多少マシであり、かつサンプリング速度がずっと高速なのは結構嬉しかった記憶がある。
また、EthernetのMAC/PHYも内蔵されており、SPIが使えるので高速デバイスの接続に便利だった。なんというか、Arduinoをある程度使って、何かしらその限界にぶつかったユーザーにとっては、mbedは良いUpgrade Pathになったと思う。
余談ながら、mbedといえばLPC1768が圧倒的に有名ではあるのだが、NXPはもう1つ「mbed LPC2368」も用意していた。こちらは60MHz駆動のARM7TDMI-Sコアを内蔵するLPC2368を利用したもので、性能的にはもちろんATmega328よりは高速だが、LPC1768には性能という意味でも搭載メモリ量でも周辺回路の点でもおよばない。
言ってみればmbed LPC1768の廉価版という位置付けになるのだが、システムに組み込む場合はその価格差が重要になるものの、そもそもmbed LPC1768自体が安価(発表当初、国内では5,940円で販売されていた)なこともあり、LPC2368を選ぶユーザーはほとんどいなかったと記憶している。
まぁそれはともかくとして、mbedプラットフォームはその後も急速に、ではないもののそれなりに大きくなっていった。メンテナンスされていないためか多少リンク切れもあるが、こんなページがmbedコミュニティにまだ現存している。このページを見れば、結構多くのユーザーがmbedを使っていろいろやっていたことがお分かりではないかと思う。
ただArduinoは、その後32bitの方向に進んで性能面での遜色もあまりなくなる一方で、2012年にはRaspberry Piが登場し、結果mbedのアドバンテージであった「Arduinoより少し便利」というメリットが薄れる一方であった。
そんな中、Armは思いもよらない方向にmbedを導く。それはmbed OSの導入である。mbed OSは2014年にArmから発表された。
もともとはArmが2013年に買収したSensinode Oyが持っていたNanoStack/NanoService/NanoRouterという機能を組み合わせ、RTOSに仕立て上げたものがmbed OSである。
このmbed OSも紆余曲折あり、そのSensinode Oy由来のmbed OS 2と、そこからフォークする形で独自に開発されたmbed OS 5がマージされて、mbed OS 5になる(これが大体2017年頃の話である)……といった具合にいろいろと話が厄介なのだが、まず当初(つまり2012年頃)にArmはIoT向けの標準プラットフォームを確立することを目論んだ。そのためのソフトウェアのインフラがmbed OSである。
ここでmbedの名前を使ったのは、もともとのmbedが提供していたオンラインの統合開発環境がそのまま使えることを狙ったためと思われる。この結果、一夜にしてmbedプラットフォームは爆発的に拡大した。要するにMCUメーカー各社がmbed OSへの対応を発表し、いきなりmbed対応ボードが100枚近く(現状では178枚)になった。
ただ、このmbed OSの環境は従来のmbedと互換性がない。当たり前の話で、ベアメタルで動作していたmbedと、曲がりなりにもOSの体裁をとっているmbed OSで同じコードが動くわけもない。いやmbed OSがちゃんとしたOSであれば、仮想的に従来のmbed環境をコンテナ的に提供して、その中で従来のmbedのコードが動くなんて芸当も可能だったのかもしれないが、mbed OSはあくまでRTOSだったし、MCUの上でコンテナ環境を動作するというのも土台無理な話である。もちろん従来のmbedの開発環境はそのまま提供されたから、引き続き従来のmbed LPC1768を使って開発や実行は可能だが、コミュニティは事実上mbed OSに乗っ取られたような状況になってしまった。
そのmbed OSはその後も迷走が続く。2015年にはmbed Clientが、2018年にはMbed(この頃からmbed→Mbedになった) Linux OSが発表されるが、どちらも広く利用されたとは言いがたい。
そもそも2010年代初頭というのはIoTの覇権争いというか、「IoTの標準化をしたものが勝者になれる」的な思い込みで、さまざまな団体や組織がIoT規格を立ち上げていた時期であり、mbed OSもその1つであった。ただ誰一人として勝者になることなく終わった、というのがこのIoT規格争いの結末であり、2022年に紹介したMatterにしても、こうしたIoTの標準化争いの敗者たちが集まって作ったという感じで、これでIoTの覇権を握ろう的な野心を一切感じさせないあたりは、参加メンバーが一度痛い目に合っていることの裏返しかもしれない。
こうなってくると、実はmbed OSの存在価値も非常に微妙である。一応mbed OSは3カ月ごとにバージョンアップされ、また2020年6月にはMbed OS 6もリリースされる。このMbed OS 6はKernelがKeil RTXのものに変わったするなど、いろいろ変更が多いのだが、それでもまだメンテナンスはされている。
ただ昨今では組み込みのマーケット事情も変わってきており、これまでシングルコアのMCUで実装されていたものがデュアルコア(片方はアプリケーション向け、片方はネットワークやセキュリティ対応のヘテロ構成)とか、MPU+MCU(MPUがアプリケーション向け、MCUはI/O管理向け)になったり、といった方向に次第にリッチな構成にシフトしつつある。またArmだけでなくRISC-V+Armなんて変な構成の製品もだんだん出てき始めた。
OSの方も、シングルコアのMCUのものはAmazonの「FreeRTOS」で良いと割り切り、もう少し高性能なものはLinuxベースにシフトし始めている(もっと高機能なものはAndroidであるが、こちらは必要とするメモリがLinuxより格段に多くなる関係で、今のところローエンドには降りてきていない)。こうなってくるとArmのCortex-Mコア(というかCMSISベース)のみをサポートするMbed OSが活躍できるマーケットはどんどん減ってくることになる。
そしておそらくとどめは2021年の会社分割だろう。Mbed OSはArmの中でもISG(IoT Service Group)の中でメンテナンスされてきたものだが、そのISGがPerionとして分社化されてしまった格好だ。最初はIoTの標準プラットフォームを担っていたはずが、いつの間にかIoTの通信インフラとなり、最後はクラウドサービスのためのエントリポイント的なビジネスに転換していたのが、そのクラウドサービスが分社化されてしまったことで、Mbed OSの存在価値が大きく薄れることになってしまった。いっそMbed OSもPerionに移行していればまた別のビジネスチャンスがあったのかもしれないが。
こうした状況を鑑みてか、2年後にMbed OSを含むすべてのMbedリソースのEOLを決断したのは、ビジネスの観点から妥当であるとは思う。一応既存のMbedをベースとしたデザインのために、たとえばオフラインでの開発環境はまだ提供されているし、Mbed OSからフォークしたMbed CEというCommunication EditionのMbed OSの開発は引き続き行なわれているとする。
また、先のリリースによれば、Mbedのハードウェアの乗り換え先としてArduinoやmicro:bit、Raspberry Pi Picoなどが、RTOSの乗り換え先としてはCMSIS RTX/Free RTOS/Zephyrがそれぞれ挙げられている(LinuxベースではYocto Linuxが推薦されている)。まだNXPはmbed LPC1768ボード(OM11043)を発売中だし、これに搭載されるLPC1768そのものも販売中であるが、NXP自身がもともとのNXPの提供していたLPCシリーズのMCUに加え、旧Freescaleの提供していたMCUも扱うことになり、この2つの流れを統合する形で新しいMCXシリーズのMCUに今後は切り替えていくことを表明し、その第1弾の製品が既にラインナップされている現状では、遠からずしてLPCシリーズが「新規設計には不適」になっても不思議ではない。そう考えると、mbedはその使命をほぼ終えた、と考えても良いのかもしれない。
PIC64
Microchip Technologyは7月9日にリリースを2つ(その1、その2)出し、民生用及び航空宇宙向けにPIC64という名称で64bit RISC-VコアのMPUを投入することを明らかにした。
このPIC64、図2を見ると分かる通り、SiFiveの「U54」をベースにした製品である。
同社はSiFiveと昔から関係が深く、もともと2016年に同社が「Mi-V」という名称でRISC-Vのソフトコアの提供を始めた時の中身はSiFiveのEF310」だったし、2017年に同社がデモしたPolarFire SoC(PolarFire FPGAにCPUをハードコアで搭載した製品)にはU54×4+E51が搭載されていた。今回のPIC64は、このPolarFire SoCからFPGAを抜いたもの、と理解すれば分かりやすい。
そんなわけで製品そのものには別に驚きはないのだが、これをPIC64と定義したことが大きなニュースである。
もともとMicrochipはPICシリーズのアーキテクチャを整理せずに山ほど投入している。「PIC10/12/14/16/18」が8bit、「PIC24」と「dsPIC」が16bitでここまでは独自アーキテクチャ。「PIC32」はもともとはMIPSのMIPS32 M4Kがベースで、その後「PIC32MZ」というMIPS32 M14Kコアの製品も投入されたが、2022年にPIC32CMシリーズがCortex-M0+ベースで発表され、現在MIPS32ベースの新製品はなくなっており、Cortex-Mシリーズに転換されていくと思われる。そして今回PIC64がRISC-Vベースで投入されたわけだ。
ちなみにほかにも旧Atmelの「AVR」シリーズ(8bit)と「SAM」シリーズ(Cortex-Mベース)も併売されており、加えると8051ベースのMCUも(Atmelの過去製品のサポートとして)扱っているから、3大8bit MCUアーキテクチャを扱う唯一の企業になっているわけだ。
まぁこれは余談だが、そんなMicrochipがPIC64の名前を冠したというのは、アプリケーションプロセッサの市場にRISC-Vを本格的に投入する、という決意表明でもある。
もともとアプリケーションプロセッサのマーケットではMicrochipは最後発にあたる格好であり、既にこのマーケットはCortex-Aが支配的になりつつあるわけだが、果たしてRISC-Vベースでシェアを獲得できるか、それとも(PIC32のように)途中でCortex-Aベースの製品も追加してゆくのか、今後の動向が楽しみである。