embedded - 組み込みシステムのワーストプラクティスは?

Question

組み込みシステムを開発する際に従うべき「ワーストプラクティス」は何だと思いますか?

してはいけないことについての私の考えのいくつかは次のとおりです。

コード全体にハードウェアアクセスを分散させる代わりに、ハードウェアレイヤーを抽象化することは避けてください。

エミュレーション環境はなく、実行/実行する実際のハードウェアしかありません。

おそらく上記の2点が原因で、単体テストを回避する

階層構造でシステムを開発していないため、上位層は下位層の機能がデバッグおよび動作することに依存する可能性があります

それを使用するソフトウェアとツールを考慮せずにハードウェアを選択する

テストポイントなし、デバッグ LED なし、JTAG なしなど、簡単にデバッグできるように設計されたハードウェアを使用する。

何をしてはいけないかについては、たくさんの良いアイデアがあると思います。それらを聞いてみましょう!

score 58 · Accepted Answer

初期化されていない例外ベクトル (「決して到達しない」ものについては、ご存知のとおり)
私と一緒に言ってください：グローバル変数。特に、保護なしで ISR とタスク (またはフォアグラウンドループ) の間で共有されるもの。
必要に応じて「揮発性」を使用しない。
DisableInterrupts() と EnableInterrupts() を組み合わせたルーチンを持つ。わかった？RestoreInterrupts ()ではなく、ENABLEです。うん、入れ子。
テスト時にトグルする GPIO はありません。
ボード上にテストポイントはありません。
ランタイムシステムステータスを表示するための LED やシリアルポートはありません。
CPU のビジー/アイドル状態の測定はありません。
最も悲惨なケースを除くすべてのインラインアセンブリの使用。簡単な吹き出しを書きます。
for (i = 0; i < 1000; i++) { } を使用して「少し遅らせる」。ええ、それは百の異なる方法であなたを噛むつもりはありません....
RAM を保持し、起動時間を短縮するために可能な限り const を使用しない (変数のコピー/初期化なし)

他にもたくさんありますが、それで始めましょう....

score 30 · Accepted Answer

私が自分を傷つける前に、誰か私を止めてください。

ところで、これらのすべてが組み込み開発に厳密に固有のものであるとは限りませんが、組み込みの世界では少なくとも現実の世界と同じくらい重要であると私は信じています。

スケジュールを立てるときは、まずすべてがうまくいくと想定してください。
オシロスコープやロジックアナライザーを使用せずに、ボードの立ち上げに取り組みます。特に。スコープ、それは決して役に立ちません。
設計時に電源を考慮しないでください。熱、効率、ADC の読み取り値とシステム動作に対するリップルの影響、EMF 放射、起動時間などの問題は重要ではありません。
何をするにしても、リセットコントローラー (5 セントの IC タイプ) を使用しないでください。RC 回路を使用してください (できれば、多くの高周波 AC ノイズが結合された回路を使用してください)。
ビッグバンを受け入れる!!! 小さな部分を段階的に開発して頻繁に統合しないでください、愚かな愚か者!!! 同僚と一緒に何ヶ月もコードを書いて、大規模なトレードショーのデモの前夜にすべてをまとめてください!
デバッグ / トレースステートメントを使用してコードをインストルメント化しないでください。視認性が悪い。
ISR で多くのことを行います。バブルソート、データベースクエリなど...ねえ、誰もあなたの邪魔をしない可能性があります。
設計でボードレイアウトを無視します。これらの整合インピーダンストレースと高電流、高周波数電源でオートルーターを街に出しましょう。ねえ、パートナー、心配するもっと重要なことがある!!!
真新しい、ベータ版、未リリース、アーリーアダプターシリコンを使用してください。特に、安全性が重要 (航空、医療) または大量生産 (100 万ユニットを思い出すのは楽しい) の場合は注意が必要です。4 コア、300 MHz、7 ステージのパイプラインチップで新しいシリコンサンプリングがあるのに、なぜベガスに行くのでしょうか?

score 25 · Accepted Answer

OKラウンド2....あと少し：

ウォッチドッグタイマーを使用しないでください (特に組み込みのタイマー!)。
スケーリングされた整数演算で十分な場合は、浮動小数点型とルーチンを使用します
保証されていない場合は RTOS を使用する
本当に理にかなっている場合は RTOS を使用しないでください
内部で何が起こっているのかを理解するために、生成されたアセンブリコードを見ないでください。
フィールドで更新できないようにファームウェアを書き込む
あなたが行っている仮定を文書化しないでください
テスト/デバッグ中に何かおかしなことが発生した場合は、それが再び発生するまで無視してください。おそらく、電圧低下、割り込みの失敗、スタック破損の兆候、またはその他の一時的かつ断続的な問題のような重要なものではありませんでした
スタックのサイズを決めるときの最善の哲学は、「小さく始めて、プログラムがクラッシュしなくなるまで増やし続ければ、おそらく大丈夫だろう」ということです。
Micrium の uC/Probe のようなランタイムプロファイリングツールを利用しないでください (他にもあるはずです)。
メインアプリを実行する前に、ハードウェアのパワーオンセルフテストを含めないでください。ブートコードが実行されています。何が機能していない可能性がありますか?
実装しない RAM テストを POST (上記) に含めないでください。
ターゲットプロセッサに MMU が搭載されている場合は、念のため、その恐ろしい MMU を使用しないでください!!! 特に、コード空間への書き込み、データ空間からの実行などから保護させないでください....
テスト、デバッグ、および特定のコンパイラオプションセットとの統合 (最適化なし/低最適化など) を行っている場合は、最終リリースビルドの前に完全な最適化を有効にしてください!!! ただし、テストしない場合にのみ最適化をオンにしてください。つまり、あなたはすでに何ヶ月もテストを行ってきました - 何がうまくいかないのでしょうか?!??!

score 14 · Accepted Answer

初期化後の動的メモリ割り当て。システムが稼働した後も、メモリプールは静的なままである必要があります。

score 12 · Accepted Answer

ロギング施設を軽視します。組み込みシステムはデバッグが難しく、大量のログが必要です。
ロギングのレベルを許可する機能がない。多くのシステムのうちの 1 つが奇妙な動作を示すため、そのシステムのログ記録のデバッグレベルをより詳細なものに設定する必要があります。
コンソールなどへのロギングを許可するある種の出力ポートを許可しない。
コードを「ステップスルー」する機能がない。
コードをプロファイルする機能がないため、アセンブラーなどで最適化する必要があるビットを確認できます。
ある種の「健全性テスト」を開発していないため、デバイスがロードされて出荷される前に動作することをすばやく確認できます。
いくつかの「自家製」OS に基づいた設計

score 8 · Accepted Answer

開発している実際のハードウェアにアクセスせずに開発しようとしています。

score 4 · Accepted Answer

ソリューションで複数のプロセッサを使用し、エンディアンが反対であることを確認してください。次に、それらの間のインターフェイスが、他のメモリに直接アクセスできるいずれかであることを確認します。

はい、以前にそのアーキテクチャをプログラムしたことがあります。

score 3 · Accepted Answer

エンディアンは永遠に同じであると仮定します。

（レジスターのサイズやハードウェア仕様に関するものに拡張してください）

（コメントのケース説明）。

score 3 · Accepted Answer

ここにいくつかあります：

開発者、マネージャー、および顧客の両方が理解できる、簡単に説明できるアーキテクチャを設計しないでください。
組み込みシステムは、ほとんどの場合、コストに敏感なプラットフォームです。ハードウェアが遅くなる (安くなる) ことを計画したり、重要なデータパスに新しい機能を追加したりすることを計画しないでください。
ほとんどの組み込みシステムは「ヘッドレス」です (キーボードやマウス、その他の HID はありません)。デバッグツールを作成するスケジュールを立てないでください。また、それらを維持するために少なくとも 1 人の開発者にリソースを提供しないでください。
プロンプトが表示されるまでにかかる時間を過小評価してください。これは、コア CPU がユーザーと通信できるようになるまでにかかる時間です。
ハードウェアサブシステムは、メモリ、クロック、電源など、すぐに使用できると常に想定してください。

score 3 · Accepted Answer

「組み込みプログラミング」をもう少し定義しないと、何が良い習慣か悪い習慣かを言うことは不可能です。

たとえば、「C」の危険な非標準方言で 8 ビットマイクロをプログラムするために使用する可能性のある手法の多くは、CE や XPe プラットフォームでは完全に不適切です。

多くの場合、抽象化は (過度に) 高価なぜいたく品です。

score 1 · Accepted Answer

マイクロは、データシートが言うことを実行する/データシートが約束しないことを実行しないと仮定します。
ウォッチドッグサービスルーチンを優先度の高い時限割り込みに入れて、他に何が起こってもウォッチドッグが失敗しないようにします。
特にArduino/Picサイトからのものである場合は、インターネット上で見られるコードを使用してください。
たとえば、Tx / Rxなど、あるコンポーネントから次のコンポーネントへの標準的な定義があると仮定します（ここには、2つの通信ポートを備えたSonyユニットがあり、一方は他方に対してTx / Rxが逆になっています）。
少なくとも100ユニットを販売するまで、顧客はわざわざ何かをチェック/テストするだろうと考えてください。
この分野の他のプレーヤーが実際に彼らが何をしているのかを知っていると仮定します（「これは私たちの古いプロトコルが行ったことだと思いますが、誰も本当に覚えていません」という標準文書があります）

score 0 · Accepted Answer

これはおそらくハードウェアの答えですが、新しいプロジェクトを最初から開始する場合、リソース要件を過小評価することは大きな問題です。特に、コード/ストレージサイズを簡単に拡張する方法がない小型の自己完結型マイクロコントローラーで作業する場合はそうです。

score 0 · Accepted Answer

これは組み込みシステムだけでなく、コードレビューなどのクールなものでバグを回避するのではなく、バグの発見（デバッグ）にすべての時間を費やすことは、間違いなく一般的に適用される最悪のプラクティスの1つです。

もう1つは、問題を小さな問題に分割するのではなく、1つの巨大なプロセッサにすべての作業を任せることです。COCOMOを覚えていますか？

score 0 · Accepted Answer

組み込みシステムで重要なことは、アプリケーションとは別に、ソフトウェア（コンパイラ、ライブラリ、OS）とハードウェア（チップセット）の両方のテクノロジを評価することです。これらにテストベッドを使用しないことは危険です。評価キットを購入するか、独自のテストベッドを構築する必要があります。

score 0 · Accepted Answer

FWモジュールを完全に汎用的に記述して、すべての可能なパラメーターを変数として受け入れます。ただし、上のレイヤーは常に同じパラメーターで呼び出します。
システムにDMAエンジンがある場合でも、コードのどこでもmemcpyを使用します（なぜHWを気にするのか）。
複雑な階層化されたFWアーキテクチャを設計し、モジュールが上位レベルのモジュールが所有するグローバル変数に直接アクセスできるようにします。
RTOSを選択しますが、実際のパフォーマンスをわざわざテストしないでください（ベンダーから提供された数値を信頼できませんか？）

score 0 · Accepted Answer

ソフトウェアの観点から言えば、ハードウェアの学習に時間をかけません。

score 0 · Accepted Answer

プログラミングするコントローラのタイプに大きく依存します。時にはコストが最も重要なことであり、できるだけ少ないコストでやり遂げようとします。それが私が通常乗っている船です。私が使用したいくつかの最悪の慣行は次のとおりです。

プロセスの改善に集中しないでください。次回はもう少しだけ頑張ってください。後で、現場でこれらすべてのバグをサポートしながら新製品を急いでリリースするのに忙しくないときは、そのことについて心配することができます。
生活を楽にするエンジニアリングツールを設計することは避け、作成する場合は、デバイスに無効な入力を送信できるようにしないでください。
最適化に疑問を抱かないでください。魔法です。コンパイラは、自分が何をしているかを知っています。特に顧客の 7 ビット PIC サブマイクロコントローラでは、コンパイラのバグは発生しません。気づく人多すぎない？
物理エンジンを実行しているように、除算と乗算を行います。オーバーフロー、精度の低下、ゼロへの切り捨てについて心配する必要はありません。
タイミングがうまくいっているように見える場合は、1 ずれているかどうか、時間の経過とともにずれているかどうかを確認しないでください。高校で打楽器を演奏したことがあるなら、7200000 クロックサイクルと 7200001 クロックサイクルの違いに気付くでしょう。
ファームウェアについて何も知らないグループによるシステムレベルのテストに頼る
できるだけ多くの異なるデバイスで作業してください。さまざまな開発環境で複数のデバッガーセッションを実行します。ある製品の開発に取り組みながら、別の製品のベンチテストを行い、3 つ目の製品でフィールドの問題を再現しようとします。
1 つのことを変更しただけで、おそらくそれを壊していないため、新しいバージョンのコードを急いでリリースします。生産ラインがダウンしています。時間を無駄にするわけにはいきません!
最適化がオフになっている場合に警告するようなテストはありません。それはおそらく正しくないでしょうか？インストールしたばかりの新しい IDE バージョンでは、その設定が壊れている可能性はありません。
動作するのに十分なだけコードを記述します。途中までの時間の 75% を費やします。
機能の設計には何も入力しないでください。どの機能でも状態情報の日数を収集できるようにします。テストのためにこの状態情報を注入する方法はありません。これにより、人々が現場で見たバグを再現しようとする自由な時間が得られ、生産担当者も彼らの休暇に感謝します.

score 0 · Accepted Answer

Printf.

トレース機能でコンテキストの切り替えや割り込みが必要な場合、漠然とタイミングに関連するものであっても、デバッグすることはできません。

メモリバッファに書き込み (s(n)printf の代わりに memcpy'ing 列挙型のボーナスポイント)、別のときにそれを読み取ります。

score 0 · Accepted Answer

いくつかの追加の禁止事項:

ハードウェアに依存する部分の開発とテストを最後まで放置して、ハードウェアが機能しない、期待どおりに機能しない、またはソフトウェアで修正できない欠陥があることを発見するだけです (たとえば、不要な非線形歪み以降のすべての信号処理を中断します)。
デジタル部分で起こっていることがアナログ部分にどのように影響する可能性があるか (たとえば、ADC からの不良データ読み取りにつながるクロストーク) を考えずに、単純な考え方でアナログ/デジタル回路を設計します。

score 0 · Accepted Answer

組み込みシステムで 8 年以上働き、組み込みシステムを教えてきた私の経験からのワーストプラクティスのいくつか:

データ型の選択- 組み込みシステムはリソースが不足しています。データの範囲が 5 ～ 200 の場合、それを int として宣言しても意味がありません。必要なのはわずか 8 ビットですが、使用されるのは 32 ビットです。24ビットの無駄。

間違ったデータ型も悲惨な結果になる可能性があります。

ISR で多くの作業を行う- ISR はできるだけ短くする必要があります。ISR にロジック全体を実装している人を見たことがありますが、これは非常に悪いことです。それは犯罪としてリストされるべきであるほど悪い。代わりにフラグを使用する
整数をフラグとして使用する- これはポイント 1 の拡張です。必要なのは 1 ビットだけです。そのために16ビットまたは32ビットを使用しないでください。
しかし、私が見た中で最悪なのは、最適で最も完璧なアプローチを得るためにアルゴリズムを何度も検討することです。止まる！！ベストプラクティスを念頭に置いて、システムを最初に機能させてください。

もっとたくさんあります。ここでそれらのいくつかを読むことができます

embedded - 組み込みシステムのワースト プラクティスは?

21 に答える 21

Related

Reference

embedded - 組み込みシステムのワーストプラクティスは?