.NET Micro Framework：移植の概要

前の記事は興味をそそりました。 さまざまな質問が寄せられましたが、それらのほとんどは移植に関するものでした。 このトピックは別の本格的な本に値するものであり、簡単に説明するのは容易ではありません。 しかし、私はしようとします。

1.はじめに

移植を行うことにした人のために、Microsoftは特別なツールを提供しています： .Net Micro Framework Porting Kit 。 これは、CLRをコンパイルできるソースコードと構成ファイルのコレクションです。 ビルドシステムはMSBuildに基づいています。 現在、コンパイルはコマンドラインからのみ開始されます。 グラフィカルツールはほとんど提供されていません。 唯一の例外は、SolutionWizardユーティリティです。このユーティリティを使用すると、ポートプロジェクトを構成できます。 開発環境のサポートもありません。 大まかに言うと、ポートはほとんどノートブックに書かれています。 しかし、近い将来、状況は良くなるはずです。

2. .NET Micro Frameworkアーキテクチャ

移植について話す前に、.Net Micro Frameworkが内部でどのように機能するかを理解することが非常に重要です。 前回の記事で、 .Net Micro Frameworkのアーキテクチャについて簡単に説明した後、それをさらに詳しく検討します。 .Net Micro Framework Porting Kitのドキュメントには次の図があります。







これは4層の.Net Micro Frameworkアーキテクチャです。 同じドキュメントには（私の無料翻訳では）次のように書かれています：

ハードウェア層

この層には、ハードウェアプラットフォームを構成するマイクロプロセッサとその他のコンポーネントが含まれています。 現在、.NET Micro Frameworkは、ARM7、ARM9、Cortex、XScale、ARC、ADI Blackfinなどのアーキテクチャのプロセッサで実行できます。



さらに、オペレーティングシステム上で.Net Micro Frameworkを実行することもできます。 もちろん、この場合、「鉄」はどこにも消えません。 ハードウェアとの対話は、オペレーティングシステムのAPIを介して行われます。 これは、 .NET Micro Framework Platform SDKに含まれているエミュレーターの動作方法です。 Windows用の.NET Micro Frameworkポートにすぎません。

ランタイムコンポーネントベース

この層は3つのコンポーネントで構成されます。



•.NET Micro Framework共通言語ランタイム（CLR）。

•ハードウェアアブストラクションレイヤー（HAL）。

•プラットフォーム抽象化レイヤー（PAL）。

CLR

.NET Micro Framework CLR（TinyCLR）ランタイムは、.NET Framework CLRのサブセットです。 TinyCLRは、小型の組み込みデバイスで使用するために特別に再設計されているという点で、「大型」CLRとは異なります。



.Net Micro Framework Porting KitにはTinyCLRソースコードが付属しています。 これらのコードはハードウェアに依存しないライブラリであり、アーキテクチャごとに異なるコンパイラでコンパイルできます。

HALおよびPAL

TinyCLRは、HALおよびPALを介して基盤となるハードウェアと通信します。 HALとPALの両方は、TinyCLRから呼び出される一連の関数で構成されています。 これらの関数はC ++で記述されています。 HALの機能がハードウェアと非常に密接に関連していることは明らかです。 それどころか、PALに含まれる機能は、ハードウェアの実装に依存しないように設計されています。



多くのHALおよびPAL関数はペアを形成します。 これらは、特定のタスクを実行するために一緒に使用されます。 TinyCLRはPAL関数を呼び出し、PAL関数はHAL関数を使用してハードウェアにアクセスします。



さらに、いわゆるブートストラップコードがHALに含まれています。 電源投入後、このコードはハードウェアを初期化し、TinyCLRを起動します。

TinyCLRは引き続きダウンロードを行い、高レベルの初期化を行っています。 ブートストラップコードは、HALの関数と特別なアセンブラーの挿入を使用してタスクを実行します。

クラスライブラリ層

.NET Micro Class Class Libraryは、開発者が組み込みアプリケーションを作成するときに使用するオブジェクト指向型のコレクションです。 これには、サードパーティのタイプが含まれる場合があります。 たとえば、デバッグボードの開発者は、これらのボードにある周辺機器を操作するためのクラスを追加します。

アプリケーション層

このレベルには、デバイス用に作成したアプリケーションが含まれます。 これまで、このようなアプリケーションの唯一の開発言語はC＃です。



したがって、移植の主なタスクは、HALレベルの機能と構成を記述することです。 次に、これがどのように行われるかを見てみましょう。

3. .NET Micro Frameworkポーティングキットのソリューション

.Net Micro Framework Porting Kit内の各ポートは、ソリューションを表します。 ソリューションは、いくつかのプロジェクトで構成されています。 合計で5種類のプロジェクトがあります。



•NativeSample

•PortBooter

•TinyBooter

•TinyBooterDecompressor

•TinyCLR



NativeSampleは、シンプルな「Hello、World」プロジェクトです。 実装の主なタスクは、デバッグコンソールに文字列「Hello、World」を表示するのに十分なHAL関数を作成することです。



PortBooter-ポートローダー。 これにより、ポートの開発およびデバッグのプロセスでTinyCLRの新しいバージョンをフラッシュできます。 このプロジェクトを実装するには、NativeSample用にすでに記述されているものに新しいHAL関数を追加する必要があります。 これは、以下のプロジェクトの実装に備えた移行プロジェクトです。



TinyBooterは、.NET Micro Frameworkブートローダーです。 電源投入時に、必要なすべての初期化を実行し、TinyCLRを起動します。 さらに、新しいバージョンのTinyCLRをフラッシュできます。 このプロジェクトを実装する過程で、HALにいくつかの新しい機能が追加されます。



TinyBooterDecompressorは、 TinyBooterの物理サイズを最小化するように設計された特別なアドインです。 TinyBooterはアーカイブされ、オンになっているときにTinyBooterDecompressorを使用して展開およびロードされます。



実際、 TinyCLRはランタイムそのものです。 機能するTinyCLRを取得することが移植の目標です。 このプロジェクトに取り組む過程で、残りのHAL機能が追加されます。 TinyCLRにはTinyBooterが含まれています。



したがって、これらのプロジェクトを順番に実装することにより、HALレイヤーを作成します。

4.ソリューションウィザードとプロジェクトコンポーネント

新しいソリューションの作成は、SolutionWizardから始まります。 このユーティリティを使用すると、ソリューションを最初から作成し、既存の（クローン）に基づいて新しいソリューションを作成し、既存のソリューションを編集できます。

このプロセスでは、SolutionWizardを使用して、ソリューションに含まれるいわゆる機能を選択できます。 機能は、.Net Micro Frameworkの機能プロパティです。 たとえば、I2C、UART、SDなどの機能があります 。 したがって、.Net Micro Frameworkの一部の機能が必要ない場合は、それらをプロジェクトに単純に含めることはできません。これにより、TinyCLRの物理サイズが削減されます。



各機能は、一連のライブラリによって実装され、 ライブラリカテゴリに結合されます 。 ライブラリは、タスクを実装する別個のMSBuildプロジェクトです。 実際には、ソースコードをライブラリに含めます。 同じタスクのさまざまな実装（たとえば、異なるプロセッサ向け）がある可能性があるため、多くのLibraryもあります。 そのため、それらはライブラリカテゴリに結合されます 。 Library Categoryのデフォルトの実装はスタブLibraryです。 これは、すべての関数がスタブであるライブラリです。 機能を持たず、通常の実装が1つもない場合でも、リンカの動作を保証するためにのみ必要です。 これらのコンポーネントはすべて相互に参照できます。



したがって、次の束が得られます。

機能 -> ライブラリカテゴリのセット->各カテゴリを実装するライブラリの 1つ。

この「混乱」を理解するのは簡単ではありません。 少なくともなんとかしてそれを明確にするために、この写真を見てください：







一見すると、それはより明確になりません。 それを理解してみましょう。



機能 I2Cの実装は次のとおりです。 機能は黄色、 ライブラリカテゴリは緑、 ライブラリは青、 スタブライブラリは黒です。 また、ダイアグラムには次のタイプの関係があります。



•依存-依存します。

•アソシエート-に関連付けられます。

•実現-実装します。

•スタブ-スタブ付きのライブラリ 。



この図から、 Feature I2Cが3つのライブラリカテゴリI2C_CLR、I2C_PAL、I2C_HALによって実装されていることがわかります。 また、別の機能ハードウェアにも依存しています。 各ライブラリカテゴリは、 ランタイムコンポーネントレイヤーのレベルの1つに対応します。



カテゴリーI2C_CLRは、 ライブラリー I2CおよびI2C_Stubによって実装されます。 カテゴリーI2C_PALは、 ライブラリー I2C_palおよびI2C_pal_stubsによって実装されます。 I2C_HALの実装で見られる最も興味深いもの。 ここでは、 スタブライブラリに加えて、異なるプロセッサ用にさらに5つのライブラリがあります。



したがって、前に選択した機能に関連付けられている各ライブラリカテゴリに対して、SolutionWizardでは1つのライブラリを選択できます。 既存のいずれかを選択するか、現時点で不要な場合はスタブを選択するか、新しいライブラリのテンプレートを生成できます。



ライブラリカテゴリの数は数百のオーダーであるため、SolutionWizardはほとんどの選択肢を取ります。 ただし、この選択を調整できます。 さらに、ソリューションに含めるプロジェクトを選択できます。



SolutionWizardの結果は、新しいソリューション、または既存のソリューションへの変更のいずれかです。



次に、コードの作成とコンパイルが直接開始されます。

5.結論

.Net Micro Frameworkポートを作成するための最も一般的な概念と原則を確認しました。 次に、この記事の範囲外の詳細を開始します。 たとえば、MSBuild、メモリ割り当て、特定の機能の実装機能などの使用。 これについては、次の記事ですべての人に書きます。