多くの知識、多くの悲しみ
ファームウェア開発者に、使用しているリアルタイムオペレーティングシステムのソースコードへのアクセスを希望するかどうかを尋ねると、ほぼ間違いなく答えは-もちろんです。 購入したソフトウェアでも同じです。 そのような答えはすべての場合に合理的であり、なぜソースコードが必要な場合があり、時にはその存在が予想よりも有用ではないのですか？
リアルタイムオペレーティングシステム（RTOS）を選択する際にエンジニアが適用する重要な基準がいくつかあります。 それらの多く-コスト、機能、ライセンス、サポート-は間違いなく非常に重要です（特にコスト-これらは私たちの現実です）。 ただし、別の基準-ソースコードの可用性-はそれほど重要ではないかもしれませんが、常に強力な要因として評価されます。
ソースコードが利用できるからといって、自動的に無料で提供されるわけではありません。 このアプローチはオープンソース製品にのみ有効であり、他のケースでは、メーカーはソースコードに課金したり、要求に応じて利用可能にしたりする場合があります。
鉄の開発。 ここにはソースコードもあります。これは、特にVHDLとVerlogを使用した開発に当てはまります。 ここでどうですか？ 従来、集積回路を選択してそのアプリケーションを開発する際、エンジニアは機能、ピンレイアウト、電力要件などを示す仕様に依存していました。 ICの内部構造の完全な図を見ることは誰も期待していませんでしたが、多くの場合、ブロック図（主に動作原理の理解を促進する例示的な資料として）、および時には回路図（OSなどのアナログIC）を見ることができましたが、宗派なし。
現在、ASICまたはFPGAファームウェアを開発しているエンジニアは、事前定義されたIPブロック（機能を提供するパッケージ済みのブロック）を使用する可能性があります。 同時に、選択は仕様に基づいて行われ、元のHDL for IPがパッケージに含まれることはまったく明らかではありません。 このブラックボックスアプローチは、ハードウェアの世界ではよく知られています。
安全性 製品に含まれる技術は、将来の技術サポートの可能性を考慮して選択する必要があります。 たとえば、IPを選択するときは、あるメーカーのユニークな製品の使用を避ける必要があります。これにより、供給が中断した場合の問題を軽減できます。
IPを使用する場合、ハードウェア側であるか、提供されているソフトウェアであるかを問わず、電源障害自体は発生しそうにありませんが（ワンタイムライセンスの場合を除く）、継続的なサポートが必要です。 したがって、特定の実装を選択する前に、サプライヤが製品のライフサイクル全体にわたってビジネスを展開するかどうかの質問をするのが最適です。
IPのソースコードが利用可能な場合、これにより、プロバイダーがサポートを提供できなくなった場合でも、ソフトウェアの問題（ほとんどすべて）を解決できます。 このため、RTOSなどの多くのバイヤーがいます。 念のため、ソースコードを棚に置いておきたいと思っています。
ソフトウェアのセットアップ：組み込みシステムとデスクトップの主な違いは、前者のばらつきです。 ほとんどのPCは他の多くのPCと類似しており、選択できるのはランタイム環境（Windows、Mac、またはLinux）のみです。 組み込みシステムは、非常に揮発性が高く、さまざまなプロセッサ、メモリ構成、周辺機器があります。 その結果、IPソフトウェアは、さまざまなシステムに展開できるように柔軟でなければなりません。 RTOSなどの多くの製品はバイナリで出荷されますが、通常は特定のアーキテクチャ向けに構成されたライブラリですが、ソースコードの要件により、ベンダーはIPをこれらの問題の多くに対処するため、複数のバリエーションを保持およびサポートする必要性を排除できます。 ユーザーは、特定のプロセッサ用のコードを作成し、デバイスのメモリカードに適合させ、必要なデバイス拡張機能を追加できます。 場合によっては、条件付きコンパイルを使用してIPブロックを構成できます。原則として、構成を決定するためにヘッダーファイルが編集されます。
認証 軍事/航空および医療などの特定のタイプのアプリケーションでは、ファームウェアは安全性とさまざまな規格への準拠について認定されている必要があります。 このプロセスは複雑で費用がかかり、通常はコードの各行をチェックする必要があります。 したがって、アプリケーション全体がレビューの対象になるため、「事前認証済み」ソフトウェアブロックを購入することは通常不可能です。 したがって、重要なアプリケーションの開発者は、完全なチェックを実行できるように、ソースコードとともに使用可能なIPを探す可能性が高くなります。
ソースコードとは何ですか？
質問は奇妙に思えるかもしれませんが、それに対する答えがなければ、その存在（または不在）のあらゆる側面の議論はやや奇妙なレッスンに変わります。 答えは明白に思えるかもしれません。一部のプログラムのソースコードは、高レベル言語またはアセンブラーの命令を含む一連のファイルであり、コンパイルして機能するバイナリ命令にアセンブルできます。 すぐに質問です-変換プロセスとそれらのランタイムに必要なプログラムは、ソースコードの一部ですか（バイナリ形式）？ それにもかかわらず、この定義は、品質の劣化の順に「ソースコード」を配信できる少なくとも3つの形式（たとえば、C言語について話しましょう）を満たしています。
1）実際、ソースコードは、適切なレイアウトで、変数の命名規則を明確にし、コメントが十分に付いています（開発者がこのIPを持っている場合、これは完全にオプションです）。
2）正常にコンパイルされるコード行。ただし、コメントや特に意味のある識別子名はありません。
3）obfrusion後のコード行。これにより、コードは人には読めなくなりますが、同時にコンパイラーには受け入れられます。 これは、識別子の名前を意味のないものに置き換え、すべてのコメントと構文的に不要なスペースを削除することによって行われます。 逆のプロセスがありますが、その結果はほとんど受け入れられません。
これらのフォームはすべて、ソフトウェアプロバイダーによって次の目的で使用されます。
1）ほとんどのバイヤーが受け取ることを期待するものであり、多くのメーカーが実際に提供するものです。 ただし、購入を決定する際にソースコードが必要な場合は、これがまさにオプションであることを確認することが重要です。疑わしい場合は、サンプルを要求してください。
2）通常、売り手が必要な最低額を納品したい場合に使用されます。これは、認定に十分な（のみ）ものです。
3）IP索好きな目からIIPのコンテンツを保護するために使用されます。つまり、ソフトウェアは構成可能性を利用しますが、それ以上は利用できません。
ソースコードの欠点。
最大の欠点は、ソースコードが利用できることです。これは強い誘惑です。 すべての開発者は、ソフトウェアを可能な限り改善したいと考えています（そういう視点があります）。 そのため、たとえば、RTOS APIがアプリケーションに最適となるように正確に機能しない場合、ソースコードの可用性はそれを変更する機会を提供します。
アプリケーションを最適化することは素晴らしいように思えるかもしれませんが、長期的なサポートには問題があります。 RTOS機能に問題がある場合はどうなりますか？ サプライヤーは、変更された製品をサポートしません。 RTOSの新しいバージョンがリリースされたらどうしますか？ 再作成にそれを含めるには、特にその著者があなたのために働いていない場合、繰り返しの修正にかなりの時間を必要とするかもしれません（まあ、あなたはこれらの修正を3年前に自然に行った、またはもちろん彼らが言うように、対応するドキュメントを書こうとはしませんでした）。
ソースコードが望ましい、有用、または必要となる状況を考慮した上で、無条件に常に必要とされるわけではないと結論付けられるべきです。 長期的なサポートを提供できる、有名で安定した大規模プロバイダーからIPを購入する場合、ソースコードの可用性は関係なく、欠点に含まれることさえあります。