- Embedded Solution【HOME】
- エンジニアコラム
- 単純に"Windows"だからといってWindows CEを採用することは間違いです
エンジニアコラム
単純に"Windows"だからといってWindows CEを採用することは間違いです
エンジニア・コラム
伊藤 優 さん [ アキタ電子システムズ 所属・マイクロソフト認定MVP ]
第3回:アプリケーション開発者が知っておくべきこと
Windows CEをベースにした製品開発では、当然アプリケーションプログラムの開発をすることになります。マイクロソフトが提供したOSイメージと標準のコンポーネントだけで製品化することはまずありません。このアプリケーション開発では、Win32APIをサポートしていること、C#やVisual Basicによるマネージドコードをサポートしていることなどから、他の組み込みOSと比較しても、組み込み未経験のエンジニアでも取っ付き易いとは思います。
でも、ちょっと待ってください。そうは言ってもWindows CEは組み込み機器用OSだという事を忘れないでください。このWindows CEのアーキテクチャからくる特徴・制限の代表的なものとして以下のような項目があります。
・プログラムメモリを二次記憶装置にスワップアウトしない。
・WinCE5.0:プロセス空間(Max. 32MB)が不足しやすい。
・WinCE6.0:物理メモリが不足しやすい。
・高プライオリティのスレッドは、低プライオリティのスレッドをブロックする。
まずメモリの話ですが、Windows CEではすべてのプロセスは物理メモリ上に配置されます。すなわち物理メモリ以上のプロセス空間をロードすることはできません。たとえHDDやSSDを搭載されたからといって、二次記憶装置として利用することはできないのです。
またWindows CE 5.0やWindows Mobileで発生するメモリ不足は、32MBが上限のプロセス空間が不足することが発生する場合がほとんどです。ユーザープロセス空間が2GBに拡大されたWindows Embedded CE 6.0では物理メモリが不足します。前者の問題は物理メモリを増やしても解決しません。確保するメモリを節約するか、プロセスを分けることになります。後者の場合はメモリ節約か物理メモリの拡張が対策となります。どちらにしてもメモリには限りがあるという事を忘れないでください。
そしてスレッドプライオリティの設定は間違えやすい機能の一つです。あるバッチ処理を優先的に実行する目的でプライオリティを上げると、より低いプライオリティのスレッドは、バッチ処理が終了するまで動作することができません。優先的なバッチ処理ではCeSetThreadQuantum関数を使用して、スレッドのクオンタムを長くすることで、他のスレッドも動作できるように設定をしてください。
今回はちょっと面倒な話でしたが、簡単に言うとWindows CE用アプリケーションを記述する場合、リソースを切り詰めて設計しましょうということになります。改めてWindows CE機器のメタボ検診をしてはいかがでしょうか?
<< 第2回: OSイメージとアプリケーションの関係
第4回: デバイスドライバへの要求 >>







