私は20年以上の組み込みシステムを所有していますが、ほとんどは8および16マイクロです。あなたの質問に対する簡単な答えは他のソフトウェア開発と同じです-あなたが必要だとわかるまで最適化しないでください、そしてあなたが最適化する必要があるものを知るまで最適化しないでください。最初に信頼性が高く、読みやすく、保守しやすいようにコードを書きます。時期尚早な最適化は、組み込みシステムの問題ではありませんが、それ以上ではありません
「リソースを無駄にせずに」プログラムを作成するとき、あなたの時間をリソースと見なしますか？そうでない場合は、誰があなたの時間をあなたに支払っていますか？組み込みシステムの設計者が選択しなければならないのは、ハードウェアのコストとエンジニアリング時間のコストです。100ユニットを出荷する場合、100,000ユニットでより大きなマイクロを使用し、1ユニットあたり1.00ドルの節約は、1人年のソフトウェア開発（市場投入までの時間、機会費用などを無視）と同じで、100万ユニットで開始しますリソース使用量に執着しているためにROIを取得しますが、多くの組み込みプロジェクトは100万を販売するように設計されているため（製造コストが低く、初期投資が高い）、100万点を達成することはできず、到着する前に破綻しました。
そうは言っても、（小さな）組み込みシステムでは、遅くするだけでなく、予期しない方法で動作を停止するため、考慮し、注意する必要があるものがあります。
a）スタック-通常、スタックサイズは小さく、スタックフレームサイズは限られています。スタックの使用率を常に把握しておく必要があります。注意してください、スタックの問題は最も陰湿な欠陥のいくつかを引き起こします。
b）ヒープ-ヒープサイズが小さいため、不当なメモリ割り当てに注意してください。断片化が問題になります。これら2つを使用すると、実行時に何を行うかを知る必要があります。OSが提供するページングにより、大規模システムでは発生しません。すなわち、mallocがNULLを返す場合、それをチェックし、何をしますか。すべてのゼニアオイは、チェックとハンドラー、コードの肥大化が必要ですか？ガイドとして-代替手段がある場合は使用しないでください。ほとんどの小規模なシステムは、これらの理由でダイナミックメモリを使用しません。
c）ハードウェア割り込み-これらを安全かつタイムリーに処理する方法を知る必要があります。また、安全な再入可能コードを作成する方法を知る必要があります。たとえば、C標準ライブラリは一般的にリエントラントではないため、割り込みハンドラー内で使用しないでください。
d）アセンブリ-ほとんどの場合、時期尚早の最適化。Cができないことを実現するには、せいぜい少量（インライン）が必要です。練習として、手作りのアセンブリに小さなメソッドを（最初から）記述します。Cでも同じことを行います。パフォーマンスを測定します。Cはより高速になり、読みやすく、保守しやすく、拡張可能になると確信しています。演習のパート2では、アセンブリとCで有用なプログラムを作成します。
別の演習として、Linuxカーネルに関するアセンブラーの量を見てみましょう。
それを行う方法を知る価値はありますが、1つまたは2つの一般的なマイクロの言語に習熟する価値さえあります。
e）「register unsigned int variable_name」、「register」は、70年前半（40年前）に、命令ではなく、コンパイラへのヒントであり、常にヒントでした。2012年には、コンパイラが非常にスマートであり、micros命令セットが非常に複雑であるため、キーストロークの無駄です。
Linuxのコメントに戻ります-ここでの問題は、私たちが100万台だけでなく、何億もの話をしているということです。人間的に可能な限り最適化するためのエンジニアリング時間とコストは価値があります。非常に優れたエンジニアリングの実践の良い例ではありますが、ほとんどの組み込みシステム開発者にとっては、Linux kernalが要求するのと同じくらい慢になるのは商業的な自殺でしょう。