私の問題はとても一般的に見えますが、私は本当にあなたの助けが必要です。私は初心者のエンベデッドソフトウェアエンジニアで、TI DSCとSTMマイクロコントローラC++プログラミング言語。今は大きなプロジェクトのファームウェアを書くつもりです。ファームウェアを実装する前にモデル化する方法を探しています。実際には2つの質問があります。大きなプロジェクト用のファームウェアを書く際に考慮する必要がある考慮事項
1.私はプロのエンベデッドソフトウェアエンジニア（ファームウェアをモデリングするために、ファームウェアに適した合理的なバラやエンタープライズアーキテクチャを使用しています。私はこれらの2つがITやソフトウェアアプリケーションに適していると思います）
2.重要なルール私はファームウェアを書いている間観察する必要がありますか？ 例えば私は約考えた：
a.Neverこれまで割り込みサービスルーチン
Bへのコードの多くを置きます。ワイルドループで待っているうちに忙しくしないでください 他に何を考慮する必要がありますか？
このような種類の質問はあまり話題にはなりませんが、とにかくこれらの非常に重要な考慮事項があるフォーラムがないので、私はとにかく答えるつもりです。通常は次のようになります。
仕様と要件を書きます。これに少し時間を費やし、技術的な詳細ではなく、製品に集中してください。 UMLの "ユースケース"は便利ですが、一般的な意味でもうまく機能します。仕様が必要なときに改訂できる生きた文書であることを確認してください。
次に、OOモデル（クラス/コードモジュール/翻訳単位と呼んでいます）を使用してプログラムデザインを行います。プログラムが必要とするコードモジュールを書き留め、これらが仕様に対応していることを確認します。理想的には、それぞれの要件によって特定のコードが導かれることが理想的です（後でそのコードの特定のテストにつながります）。次に、異なるモジュール間の依存関係に焦点を当てます。これは、ドライバがHALに依存せず、呼び出し元などに依存しない、「上から下へ」の依存関係ツリーでなければなりません。この木をペンと紙で描く。ファンシーなUMLは大丈夫だが必須ではない。
早い段階で移植性を考慮する必要があります。プロジェクト間でコードを移植する必要がありますか？ （非常に一般的）コンパイラ間？ （かなり共通）プラットフォーム間？必要とされる移植性のレベルに応じて、設計を打ち負かすことができ、いくつかのHALをスキップすることができます。ただし、ほとんどの場合、ドライバーをアプリケーションから分離することをお勧めします。
「重要なルール」に関しては、これらはプログラムの設計段階とは関係ありません。むしろ、これらはあなたのコーディング標準文書にあるはずです。好ましくは、すべてのプロジェクトに使用される会社標準。それはすべての悪い習慣を禁止することに焦点を当てるべきであり、さらにスタイルガイドを含んでいます。組み込みシステムの場合は、このドキュメントをMISRA-Cに基づいて作成し、必要に応じてカスタムルールを追加してから、その上にスタイルガイドを追加することを強くお勧めします。このコーディング標準を作成することは、それ自身のプロジェクトであることに注意してください。
この回答では、モジュール性についてのポイントが最も重要なポイントだと私は感じています。移植性と悪いスタイルの欠如など、他の間違いは、コードベースがすべての場所に依存する恐ろしいスパゲッティではないときには、修正するのが簡単です（最初は無視してはいけません）。 – user694733
@ user694733確かに。プログラム設計がほとんどない、あるいはまったくない小規模なプロジェクトから来ている組込みプログラマーは、なぜこれが必要なのかを理解していないことがよくあります。だから、モジュール化せずにすべてを書いて、信じられないほど緊密な結合に終わります。何百ものブール値の「フラグ」と、グローバルスコープの不明な状態変数と、スパゲッティのグローバルデータ。クリティカルマスにぶつかって恒久的にバグが出るまで、それはますます維持できなくなります。このようなプログラムを復元する方法は実際にはありません。最初から書き直す必要があります。 – Lundin
@ Lundin非常に良い点。しかし、この金属のもう一つの側面があります。モジュラー性と抽象性に注目すると、コーダーが完全に気にしない場合とまったく同じ効果が得られることがあります。 MISRA-Cは、この標準が実際のファームウェアの問題で開発され、進化したため、良い出発点です。私はここで非常に頻繁に批判されています。なぜなら、オーバーヘッドがなくても最小限で、コードをクリアして人間にとってより読みやすくするので、関数内で1つのリターンポイントを好むからです。 –
ファームウェアの他端にあるという個人的な経験から、他の誰かがやりとりするAPIがある場合は、書き込む前に必要なものを尋ねてください。 – Robinson
最初のもの：要件を集める！ユースケーススタディを行う！必要なものを見つけてください！次に、あなたが持っている情報から分析を行います。分析から設計を続ける。その後、テストケースを作成し続けます。次に、設計を実装し、テストケースを通過することを確認します。必要に応じて、任意のステップまたは複数のステップにわたって繰り返します。 –
答えていただきありがとうございます。あなたの仕事でUMLに基づいたモデリングデザインツールを使用しましたか、ファームウェアには必要ありませんか？（エンタープライズアーキテクトのような） –