明らかに、.NETFrameworkは立ち入り禁止になります
必ずしも真実ではありません。十分なROMおよびRAMリソース(それぞれ256K / 64K)があれば、.NETMicroFrameworkはデバイス上で実行されます。ただし、それが必ずしもそれを使用する正当な理由ではありません。組み込みターゲットとWindowsの両方で使用できる他の2つの一般的に使用されるポータブル言語、CとC++がすでにあります。CとC++の両方に必要なターゲットリソースは最小限です。C/C++ランタイム起動コードは1K未満のコードであり、実行時環境ではなく、アプリケーションコードで利用可能なリソースのほとんどすべてを利用できます。
両方のプラットフォームで共通のコードを利用する秘訣は、抽象化です。ターゲットがRTOSやスレッドライブラリなどのカーネルまたはスケジューラを使用している場合、これには少なくともハードウェアの抽象化と、場合によってはOSの抽象化が含まれます。
組み込みターゲットをレイヤーアーキテクチャで設計することをお勧めします。少なくともデバイスレイヤーとアプリケーションレイヤーがあり、すでに述べたように、IPC、同期、スケジューリングを使用する場合は、システムレイヤーを使用することもできます。抽象化の恩恵を受けるネットワークやファイルシステムなど、他の上位層のインターフェースがある場合があります。BSDソケットやstdioなどの標準APIはすでに抽象化としてカウントされているため、ターゲットがこれらを使用している場合、Windowsで行う作業は少なくなります(BSDソケットとWinsockのわずかな違いでも作業が必要になる場合があります)
アプリケーション層には、デバイス層とシステム層を介してアクセスできるもの以外に、OSまたはハードウェアの依存関係はありません。次に、Windowsで利用可能なサービスまたはデバイスへのシミュレーションまたは再マッピングとして、デバイスおよびシステムレイヤーをWindowsに実装する必要があります。一部のRTOSには、テストと開発用のWindowsシミュレーターがすでに含まれていますが、多数のネイティブRTOSとGPOSの間で移植できる独自のOS APIレイヤーを定義すると、シミュレーションとリアルタイム実行の両方でアプリケーションコードをさまざまなターゲットに移植できます。早く。
プラットフォームの違いがわずかでローカライズされており、抽象化レイヤーを正当化できない場合は、ターゲット固有の条件付きコンパイルが適切な場合があります。コンパイラーは、アーキテクチャー、OS、またはコンパイラー固有のコード用に事前定義されたマクロをサポートします。これらのマクロは、このローカライズされたコードと、重要な類似性がある場合に抽象化レイヤーコード自体を共通にするために使用できます。