背景

あなたはこれから、マイクロコントローラ向けに「ベアメタル」Rustを書こうとしています。もしかすると、これまでにこのようなことをした ことは一度もないかもしれません。それは 素晴らしいこと です — すばらしい冒険へようこそ！

まずは、あなたが抱いているかもしれない基本的な疑問に答えることから始めましょう。

• マイクロコントローラとは何ですか？

  マイクロコントローラは、1つのチップ上に実装された システム です。あなたのコンピュータが、プロセッサ、RAM、 ストレージ、Ethernetポートなどの複数の個別のコンポーネントで構成されているのに対し、マイクロコントローラはそれら すべての種類のコンポーネントを単一の「チップ」またはパッケージに内蔵しています。これにより、より少ない部品で システムを構築できます。

• マイクロコントローラで何ができますか？

  たくさんあります！ マイクロコントローラは、「組み込みシステム」として知られるものの中核です。 組み込みシステムはいたるところにありますが、普段それと意識することはあまりありません。組み込みシステムは、 あなたの衣類を洗い、文書を印刷し、食べ物を調理する機械を制御しています。組み込みシステムは、あなたが暮らし、 働く建物を快適な温度に保ち、あなたが移動に使う車両を停止・走行させる部品も制御しています。

  ほとんどの組み込みシステムは、ユーザーの介入なしに動作します。洗濯機のようにユーザーインターフェースを 備えている場合であっても、その動作の大部分は自律的に行われます。

  組み込みシステムは、物理的なプロセスを 制御 するために使われることがよくあります。これを可能にするために、 外界の状態を知らせる1つ以上のデバイス（「センサー」）と、物事を変化させることを可能にする1つ以上の デバイス（「アクチュエータ」）を備えています。たとえば、建物の空調制御システムには次のようなものがあります:

  • さまざまな場所の温度と湿度を測定するセンサー。
  • ファンの速度を制御するアクチュエータ。
  • 建物に熱を加えたり取り除いたりするアクチュエータ。

• どのような場合にマイクロコントローラを使うべきですか？

  上に挙げた組み込みシステムの多くは、Linuxを実行するコンピュータ（たとえば「Raspberry Pi」）で 実装することもできます。それなのになぜ、代わりにマイクロコントローラを使うのでしょうか？ プログラムの 開発はむしろ難しそうに思えます。

  理由としては、次のようなものがあります:

  • コスト: マイクロコントローラは、汎用コンピュータよりもはるかに安価です。マイクロコントローラ 自体が安いだけでなく、動作に必要な外付けの電気部品もずっと少なくて済みます。 そのため、プリント基板（PCB）はより小さくなり、設計や製造のコストも下がります。

  • 消費電力: ほとんどのマイクロコントローラが消費する電力は、本格的なプロセッサのごく一部です。 バッテリーで動作するアプリケーションでは、これは非常に大きな違いになります。

  • 応答性: その目的を果たすために、一部の組み込みシステムは常に限られた時間内に反応しなければ なりません（たとえば、自動車の「アンチロック」ブレーキシステム）。システムがこの種の デッドライン に 間に合わないと、壊滅的な障害が発生する可能性があります。このようなデッドラインは「ハードリアル タイム」要件と呼ばれます。そのようなデッドラインに拘束される組み込みシステムは、「ハード リアルタイムシステム」と呼ばれます。汎用コンピュータとOSには通常、多数のソフトウェアコンポーネントがあり、 コンピュータの処理リソースを共有しています。そのため、厳しい時間制約の中でプログラムの実行を 保証することが難しくなります。

  • 信頼性: ハードウェアとソフトウェアの両方で構成要素が少ないシステムでは、問題が起きる要素も それだけ少なくなります！

• どのような場合にマイクロコントローラを使うべきではないですか？

  マイクロコントローラは、重い計算処理を行うのが得意でないことがよくあります。コストと消費電力を 低く抑えるために、マイクロコントローラで利用できる計算資源は限られています。

  マイクロコントローラは通常、「大きな」プロセッサよりも1秒あたりに実行できる命令数が少なくなります。最も低速 なものでは、1秒あたり「たった」数百万命令しか実行できない場合もあります。さらに、1命令あたりの 仕事量も一般に少なめです。マイクロコントローラは通常「32ビット」ですが、「16ビット」の ものも珍しくなく、これは典型的なRustのデータ型を扱うためにより多くの命令が必要になることを意味する場合があります。ほとんどの マイクロコントローラには「キャッシュ」がないか、あってもわずかであるため、命令は主記憶にアクセス できる速度でしか実行できません。

  一部のマイクロコントローラには、浮動小数点演算のためのハードウェアサポートがありません。そのような デバイスでは、単精度数の単純な加算ですら数百CPUサイクルかかることがあります。

  最後に、マイクロコントローラには通常、限られたメモリしかありません。メモリ容量は、プログラム命令用に16KB、 データ用に4KBしかないこともあり、この種のシステム向けプログラミングはかなり難しくなります。 単位コストおよび消費電力あたりの内部メモリ容量は絶えず増加していますが、これから扱う プロセッサでも、プログラム命令用が「わずか」512KB、データ用が256KBしかありません — それでも 「本物のコンピュータ」に比べればはるかに少ないのです。

• なぜCではなくRustを使うのですか？

  おそらくここで私があなたを説得する必要はないでしょう。RustとCの言語としての 違いには、すでによく馴染みがあるはずだからです。ただし、ぜひ触れておきたい点が1つあります。それはパッケージ管理です。Cには 公式で広く受け入れられたパッケージ管理ソリューションがありませんが、RustにはCargoがあります。これにより、開発は はるかに 容易になります。そして、IMO、簡単なパッケージ管理はコードの再利用を促進します。ライブラリを アプリケーションへ容易に統合できるからです。これは、ライブラリがより多くの「実運用での テスト」を受けることにもつながるため、良いことでもあります。

• なぜRustを使うべきではないのでしょうか？

  あるいは、なぜRustよりもCを選ぶべきなのでしょうか？

  Cのエコシステムはより成熟しています。いくつかの問題に対しては、既製のソリューションがすでに存在します。厳密な タイミングが求められるプロセスを制御する必要があるなら、既存の商用リアルタイム オペレーティングシステム（RTOS）のどれかを使って問題を解決できます。Rustには商用の本番運用レベルの RTOSは存在しないため（本稿執筆時点）、自分で1つ作るか、開発中のものを試すかのどちらかになります。 それらの一覧は Awesome Embedded Rust リポジトリにあります。