.Net Micro Frameworkについて初めて耳にしたのは、約1年前の組み込み技術に関する会議でした。 当時、同僚と私は組み込み開発用の新しいプラットフォームについて考えていたため、.Net Micro Frameworkを詳しく調べることにしました。 それ以来、私たちはこのプラットフォームをかなり深く研究してきました。 そこではすべてがそれほどスムーズではありませんが、それでも.Net Micro Frameworkは非常に便利で便利であることがわかりました。 この記事では、その理由を説明します。
私たちの以前の開発は、uPSD3234マイクロコントローラーに基づいていました。 組み込みデバイスの多くの開発者に馴染みのある問題に遭遇するまで、原則としてすべてが順調でした。 マイクロコントローラーのメーカーであるST Microelectronicsは、uPSD3234を含むシリーズ全体が6ヶ月以内に製造中止になると予想外に発表しました。 私たちは1年間の仕事を無駄にしていたことが判明しました。 新しいプラットフォームを探す必要がありました。 uPSD3234アーキテクチャはすでに古く、多くのコードが記述されているため、異なるアーキテクチャの新しいプロセッサへの移植は困難で無意味でした。 最終的に、新しいデバイスをゼロから作成することにしました。 21世紀は庭にあるので、私はすぐにOOPや例外処理などの「魅力」を手に入れたかったのです。 そして最も重要なこと-新しい問題を回避するために、ハードウェア実装への可能な限り少ないバインディング。
そして、ここで.Net Micro Frameworkが登場しました。 このプラットフォームの一般的な目的は、オペレーティングシステムなしで32ビットマイクロコントローラーで.Netコードを実行することです。 2010年以来、Microsoftは.Net Micro Frameworkを無料のオープンソースプロジェクトにしています。 その前に、彼らは使用のために控除を取りました。 現在、開発はインターネットコミュニティに基づいていますが、Microsoftのリーダーシップの下です。
Visual StudioのC＃でマイクロコントローラー用のコードを書くというアイデアが本当に気に入りました。 便利で強力なIDEとマネージコードには、ガベージコレクター、マルチスレッド、例外処理、OOPなど、多くの利点があります。 XMLが必要な場合は、TCP / IPを使用したイーサネットが必要です。それは、タッチパネルとジェスチャー認識を備えたLCDが必要です。 そして最も重要なことは、.Net Micro Framework用に記述されたコードがどのハードウェアプラットフォームにも結び付けられていないことです。
しかし、すべての魅力のためにあなたは支払う必要があります。 もちろん、マネージコードの実行は通常より少し遅くなります。 もちろん、メタデータのため、コードの量は増えます。 これはすべて、ハードウェアのコストの上昇につながります。 もちろん、ハードウェアプラットフォームを使用したい場合、.Net Micro Frameworkは移植を必要としますが、それほど高速ではありません。 既製のボードがありますが、大量生産には高価であり、海外から輸入する必要があります。
私たちは次のような仕事を始めました：
この記事のヘッダーにある写真は、Embedded Artistsのデバッグボードです。 このボードの.Net Micro FrameworkポートはMicrosoftから無料で提供されていますが、起動するのはそれほど簡単ではありませんでした。 しかし、アプリケーションのデプロイでポートが正常に起動された後、問題はありませんでした。 写真では、たとえば、サンプルアプリケーション「パズル」。
移植に関する主な問題は、ドキュメントが非常に少ないことです。 何とどのように言っているように見えますが、読んだ後でもまだほとんど理解されていません。
.Net Micro Framework全体は、いくつかのレイヤーに分割されています。
上位2層（ユーザーアプリケーションとシステムライブラリ）はマネージコードで記述されています。 これがVisual Studioで見られるものです。 ハードウェア層はハードウェアそのものです。 さて、TinyCLRレイヤーはコード実行環境そのものです。
TinyCLRは3つの部分に分かれています。
1）CLR-ここでは、すべてがマネージコードの実行、入力、ガベージコレクションなどに関連しています。
2）PAL（Platform Abstraction Layer）-カウンター、タイマー、入出力などの一般的な抽象化を操作するためのクラスと関数。 これらのクラスは、すべてのハードウェアプラットフォームで同じです。
3）HAL（ハードウェアアブストラクションレイヤー）-「ハードウェア」と直接連携する当日のクラスと機能。
移植は、特定のハードウェアプラットフォーム用のHALを作成するプロセスです。 コードは段階的に記述され、徐々に機能が増加します。 主な目標は、CLRを実行するための基本的な機能セットを実装することです。 残りのコードは必要に応じて記述されます。 どのように、そして何が機能するかを理解すると、このプロセスはルーチンに変わります。
Embedded Artistsボードポートについては、2つの問題が発生しました。
1）配信されたコードは、何らかの理由でエラーが発生しました。 たとえば、UARTのボーレートが正しく計算されませんでした。
2）メモリ割り当て。 何をどこでフラッシュするかを理解するために多くの時間を費やしました。 ただし、この情報は他のポートに適用されます。
一般的に、結局のところ、すべてはそれほど怖くありませんでした。 ゼロから始めて、数か月のうちにARM7ベースのボードにポートを作成することができました。 新しいボードのコストは、uPSD3234に基づくボードと比較してわずか5ドル増加しました。 また、パフォーマンスの問題に気付きませんでした。 もちろん、まだいくつかの小さな問題がありましたが、コミュニティフォーラムでの.Net Micro Framework開発者とのコミュニケーションのおかげで、すぐに解決されました。
これで、開発を.Net Micro Frameworkに完全に移行しました。 私たちの経験が誰かに役立つことを願っています。 興味のある方は、さらに詳細な記事をいくつか書くことができます。
更新：
続き： .NET Micro Framework：移植の概要