組み込みソフトウェア市場でCが優位を占めるのはなぜですか？[閉まっている]

ほとんどすべての人が祝福を言うでしょう。

パフォーマンス！

さて、Cはアスレチックコードを書くことができます。しかし、そうすることができる他の言語があります、結局のところ！そして、最新のコンパイラの最適化能力は素晴らしいです。DOES Cは、他の言語が持っていないことをいくつかの利点がありますか？または、ドメイン内でより柔軟な機器を使用する必要はありませんか？

ほとんどすべての人が祝福を言うでしょう。

パフォーマンス！

それはその一部です。決定的なリソースの使用は、最初はリソースが限られているデバイスで重要ですが、他の理由もあります。

1. 低レベルのハードウェアAPIへの直接アクセス。
2. これらのデバイスの大部分に対応するCコンパイラを見つけることができます。私の経験では、これは高級言語には当てはまりません。
3. C（ランタイムおよび生成された実行可能ファイル）は「小さい」です。コードを実行するために、大量のものをシステムにロードする必要はありません。
4. ハードウェアAPI /ドライバーは、おそらくCまたはC ++で作成されます。

Cは、アセンブリ言語を記述するだけでなく、プラットフォーム間でUnixを移植できるように作成されたため、CPUをモデル化するように設計されました。

つまり、Cプログラムは、組み込みハードウェアの場合のように、実際のCPUに非常に近い抽象化レベルを必要とするプログラムのプログラミング言語として機能します。

注：Cは1970年頃に設計されたもので、CPUはそれより単純でした。

支配の理由の1つは、タスクに適切な種類のツールがあることです。JavaとC / C ++の両方の組み込みプラットフォームで開発した後、C ++の基本的なアプローチはより自然であることがわかります。言語が高すぎるために開発者がフープを飛び越えていると感じないようにすることは、非常に迷惑なことです。1つの良い例は、Javaに符号なし変数がないことです。

また、VM /解釈言語の便利な機能は通常実行不可能であり、ガーベッジコレクションなどの実装から除外されます。

C自体はランタイムサポートをほとんど必要としないため、オーバーヘッドははるかに低くなります。ランタイムサポートにメモリやストレージを費やしたり、そのサポートを最小限に抑えるために時間や労力を費やしたり、プロジェクトの設計でそれを許可したりする必要はありません。

他の回答で述べたように、Cは1970年代初期にミニコンピューターアーキテクチャのアセンブリ言語を置き換えるために開発されました。当時、これらのコンピューターは通常、メモリや周辺機器を含めて数万ドルかかりました。

今日では、内蔵RAMおよびI / Oコントローラーを含む単一の量で4ドル以下の価格の16ビット組み込みマイクロコントローラーを使用して、同等以上のコンピューター能力を得ることができます。32ビットのマイクロコントローラのコストは、おそらく1〜2ドルです。

私がこれらの小さな人をプログラミングしているとき、それは彼らが座っているボードを設計していないときの90％の時間です、私はプロセッサが何をしようとしているのかを視覚化するのが好きです。アセンブラで十分に高速にプログラムできれば、そうするでしょう。

あらゆる種類の抽象化レイヤーは必要ありません。私はしばしば、画面に表示されている逆アセンブラーをステップ実行してデバッグします。そもそもCでプログラムを作成した場合、それは非常に簡単です。

コンパイラーが改善され、ハードウェアのパフォーマンスが向上したため、C ++がますます使用されているため、完全に支配しているわけではありません。ただし、Cはまだいくつかの理由で非常に人気があります。

1. 幅広いサポート。ほとんどすべてのチップベンダーがACコンパイラを提供しており、サンプルコードとドライバーはすべてcで記述されています。C ++コンパイラはますます一般的になっていますが、特定のチップの死んだ証明書ではなく、バグが多いことがよくあります。また、組み込みエンジニアはcで作業できることも知っています。それは業界の共通語です。

2. パフォーマンス。うん、あなたはそれを言った。パフォーマンスは依然として重要であり、コアルーチンが依然としてアセンブラーで記述されているか、アセンブリ出力を参照してcで少なくとも最適化されている環境では、この重要性を過小評価しないでください。多くの場合、組み込みターゲットは非常に低コストで、非常に小さなメモリとわずかなmipsしかありません。

3. サイズ。C ++は大きくなる傾向があります。確かに、STLを使用するものはもっと大きくなります。一般に、プログラムサイズとメモリフットプリントの両方の面で。

4. 保守主義。非常に保守的な業界です。その理由の1つは、障害のコストが高くなることが多く、多くの場合デバッグを利用しにくいことです。1つには、変更する必要がないためです。小さな組み込みプロジェクトの場合、cはうまく機能します。

組み込みシステムの最大の特徴はパフォーマンスです。しかし、あなたが言ったように、なぜ他のパフォーマンス言語ではなくCなのでしょうか？

これまで多くの人がコンパイラの利用可能性について言及しましたが、開発者の利用可能性について誰も言及していません。OCamlよりも多くの開発者が既にCを知っています。

これらが3つの大きなポイントです。

組み込みソフトウェアは大きく異なります。

デスクトップアプリでは、抽象化とライブラリにより開発時間を大幅に節約できます。問題に別の数メガバイトまたはギガバイトのRAMまたは2 + GHz 64ビットCPUコアを追加する余裕があり、他の誰か（ユーザー）がそのハードウェアにお金を払っています。アプリが実行されるシステムがわからない場合があります。

組み込みプロジェクトでは、リソースが非常に限られていることがよくあります。私が取り組んだあるプロジェクト（PIC 17Xシリーズプロセッサ）では、ハードウェアに2Kワードのプログラムメモリ、8レベルの（ハードウェア内）スタック、192バイト（<0.2kB）のRAMがありました。異なるI / Oピンには異なる機能があり、必要に応じてハードウェアレジスタに書き込むことでハードウェアを構成しました。デバッグには、オシロスコープとロジックアナライザーが含まれます。

組み込みでは、抽象化が邪魔になることが多く、所有していないリソースを管理（およびコスト）します。たとえば、ほとんどの組み込みシステムにはファイルシステムがありません。電子レンジは組み込みシステムです。車のエンジンコントローラー。一部の電動歯ブラシ。一部のノイズキャンセリングヘッドフォン。

組み込みシステムの開発で私にとって非常に重要な要素の1つは、命令、リソース、メモリ、実行時間の観点からコードが何に変換されるかを把握し、制御することです。多くの場合、命令の正確なシーケンスは、ハードウェアインターフェイスの波形のタイミングなどを制御します。

抽象化と舞台裏の「マジック」（ガベージコレクターなど）は、デスクトップアプリに最適です。ガベージコレクターを使用すると、メモリを動的に割り当てることができる場合に、メモリリークを追跡する時間を大幅に節約できます。

ただし、リアルタイムの組み込みの世界では、物事にかかる時間（場合によってはナノ秒まで）を把握し、制御する必要があります。また、問題でRAMを2メガバイトもCPUを高速化することもできません。1つの簡単な例：デューティサイクルを制御してLEDのソフトウェア調光を行う場合（CPUにはLEDのオン/オフ制御のみがあります）、プロセッサがオフになり、たとえば100ミリ秒のガベージコレクションが表示されるため、これは問題ありません明るいフラッシュまたは外出。

より仮説的な例は、スパークプラグを直接点火するエンジンコントローラーです。そのCPUがオフになり、50ミリ秒のガベージコレクションが行われると、エンジンが一時的に停止するか、間違ったクランクシャフト位置で発火し、エンジンを失速させる（通過中？）か、機械的に損傷する可能性があります。誰かを殺すことができます。