背景
マイクロコントローラーとは？
マイクロコントローラーは、1つのチップ上のシステムです。一方、あなたのコンピューターは複数の独立した コンポーネント、つまりプロセッサー、RAMモジュール、ハードドライブ、イーサネットポートなどで構成されますが、 マイクロコントローラーでは、それらすべてのコンポーネントが単一の「チップ」またはパッケージに組み込まれています。これにより、 部品点数を最小限に抑えたシステムを構築できます。
マイクロコントローラーで何ができますか？
いろいろなことができます！ マイクロコントローラーは、組み込みシステムとして知られるシステムの中核です。 こうしたシステムは至る所にありますが、普段はあまり意識されません。これらのシステムは、自動車のブレーキを制御し、 洗濯を行い、文書を印刷し、あなたを暖かく保ち、涼しく保ち、 自動車の燃費を最適化するなどしています。
これらのシステムの主な特徴は、洗濯機のようにユーザーインターフェースを備えている場合でも、 ユーザーの介入なしに動作することです。その動作の大半は自律的に行われます。
もう1つの共通した特徴は、これらのシステムがプロセスを制御することです。そのため、これらのシステムには通常、 1つ以上のセンサーと1つ以上のアクチュエーターがあります。たとえば、HVACシステムには、いくつかの領域に配置された 複数のセンサー、温度計、湿度センサーがあり、さらに複数のアクチュエーターとして、 ダクトに接続された発熱体やファンもあります。
どのような場合にマイクロコントローラーを使うべきですか？
先ほど挙げたこれらの用途は、Linuxが動作するコンピューターであるRaspberry Piでもおそらく 実装できます。なぜわざわざ、OSなしで動作するマイクロコントローラーを使うべきなのでしょうか。なんだか プログラムの開発がより難しくなりそうです。
主な理由はコストです。マイクロコントローラーは、汎用コンピューターよりもはるかに安価です。マイクロコントローラー自体が 安いだけでなく、動作に必要な外付けの電気部品もずっと少なくて済みます。 そのため、プリント基板（PCB）はより小さくなり、設計や 製造のコストも下がります。
もう1つの大きな理由は消費電力です。マイクロコントローラーは、本格的なプロセッサーと比べて桁違いに少ない電力しか消費しません。 アプリケーションがバッテリーで動作するなら、この差は非常に大きなものになります。
そして最後になりますが、重要なのが（ハード）リアルタイム制約です。プロセスによっては、そのコントローラーが 一定時間内に何らかのイベントへ応答することを求められます（例: 突風を受けたクアッドコプター／ドローン）。 このデッドラインを守れなければ、そのプロセスは致命的な失敗に終わる可能性があります（例: ドローンが地面に 墜落する）。汎用OS上で動作する汎用コンピューターでは、多くのサービスが バックグラウンドで動いています。そのため、厳しい時間制約の下でプログラムの実行を保証するのは困難です。
どのような場合にマイクロコントローラーを使うべきではありませんか？
重い計算が必要な場合です。消費電力を低く抑えるため、マイクロコントローラーが利用できる計算資源は 非常に限られています。たとえば、浮動小数点演算をハードウェアでサポートしていないマイクロコントローラーも あります。そのようなデバイスでは、単精度数の単純な加算でさえ 数百CPUサイクルかかることがあります。
なぜ C ではなく Rust を使うのですか？
おそらく、ここで皆さんを説得する必要はないでしょう。RustとCの言語としての違いには、すでにおなじみだと思うからです。 ただし、1点取り上げておきたいのがパッケージ管理です。Cには公式で広く受け入れられている パッケージ管理ソリューションがありませんが、RustにはCargoがあります。これによって開発は はるかに 容易になります。また、私見では、パッケージ管理が容易だとコードの再利用が促進されます。なぜなら、 ライブラリをアプリケーションに簡単に統合できるようになり、ライブラリがより多くの「実戦での検証」を受けるのは良いことだからです。
なぜ Rust を使うべきではないのですか？
あるいは、なぜ Rust より C を選ぶべきなのでしょうか？
Cのエコシステムは、はるかに成熟しています。いくつかの問題については、既製のソリューションがすでに存在します。もし 時間に厳しいプロセスを制御する必要があるなら、既存の商用リアルタイムオペレーティングシステム （RTOS）のいずれかを使って問題を解決できます。Rustには、まだ商用で本番運用に耐えるRTOSが ないため、自分で作るか、現在開発中のもののいずれかを 試すしかありません。