Frameworkに関するハンズオンセミナーを実施してます。そこで話している内容をちょっぴり紹介。Gadgeteerなどでプロトタイプを作っていろいろ試した後、実デバイス開発の流れは、以下の様になります。Gadgeteerボードで実行ロジック確認をしながら進めていくことができます。Layer)という層があるので、アプリケーション開発とハードウェア開発は基本、並行して進められます。Frameworkをポーティングします。この作業も、アプリケーション開発とは並行して進められます。アプリはアプリで、ハードウェアはハードウェアで、徹底的にモジュールテストが行えます。TFSのリモートテスト機能を使えば(実はここまだ検証していないので、多分出来るはずというレベルです。ごめんなさい)、自動テストに小型組込み機器のソフトウェアテストを組み込むことも可能です。Studioで実行ターゲットを変えるだけでF5実行すれば(MFDeployを使ってアプリを配置するのが正当ですが)、実機で動き出すはず。後はシステムテストをすれば、OK。Studioのエディターで、ハードウェアの構成を定義できることはご存知ですよね。Electronics社の専売特許と思っていませんか?独自に開発したCPUボード、モジュールも、この環境に組み込むことが出来るんです。Studioにインストールされます。Kitこれを使うと、上から順番に、自前のCPUボード、自前の周辺ボード、ツールボックスの部品群とライブラリ一式、を作れます。Electronics社が公開しているSDKのようなものを、各自のハードウェア構成でも作成可能ということです。SDKが出来上がる訳です。組込み機器は、大枠のアーキテクチャは決まっていて、製品構成オプションによるバリエーション開発というのが一般的?なので、規律ある製品開発活動を進めるのにこの仕組みはとても便利です。Frameworkを適用するのに具合の良い組込み機器の種類の一つとして、クラウド等ネットワークサービスと連携する機器があります。ネットワーク上のサービスへのアクセスは、プロトコルやセキュリティなどアクセスの仕方が規定されていて、組込み機器もその規定に従わないといけません。組込み機器側に、その規定に従うためのロジックが必要になる訳です。APIの上に構築されたソフトウェアは、HWが変わっても、同じように動きますね。Frameworkで動作するライブラリを公開して、組込み機器側のアプリケーションがそのライブラリを使ってサービスにアクセスするようにしてもらえば、サービスベンダーは、組込み機器の内部事情をほとんど考慮せずに、組込み機器側に対する要件を提供することができるわけです。サービスベンダーが提供しなければならないのは、ライブラリと、Emulator上で動作するサンプルコードだけで十分です。図にすると以下の様になります。この構成、実は、スマートフォンアプリや、PC、タブレット向けには既によく見られる仕組みですよね。組込み機器も含めた仕組みが実現できます。Frameworkベースでなくても、PICや16BitのCPUでない限り、この仕組みを活用することができるわけです。Frameworkを活用したSDKを公開しても構いません。皆さん、是非トライしてみてくださいね。FeedbackTrademarks。