今では、Linux と Windows デスクトップの相対的なメリットがよくわかっていると思います。しかし、組み込み開発の世界についてはほとんど聞いたことがありません。私は主に業界向けのソリューションに関心があるため、iPhone や Android には関心がなく、これら 2 つの OS に関心があります。
組み込みの世界における 2 つのプラットフォーム間の相対的なトレードオフは何ですか? カスタム ハードウェア、部分的にカスタマイズされた OS、およびカスタム アプリを使用して特定のプロジェクト用のボックスを構築することを検討している場合、どれを選択しますか?またその理由は何ですか?
Windows CE はツールで勝ち、Linux はコストとおそらくパフォーマンスの両方で勝つと思います。ただし、これはまったくの憶測です。誰かが2つの事実や経験を持っていますか?
私は、すべてのハードウェアに CE と Linux の両方を提供する会社で数年間働いていたので、この方程式の両側にかなり精通しています。
これはCEが毎回勝つということですか？いいえ、まったくお勧めしません。あなたが Linux ショップであり、Linux の経験とコード資産が豊富にある場合、それを使い果たして CE に行くのはばかげているでしょう。ただし、ゼロから始めた場合、通常、CE の TCO は低くなります。Win32/C# の経験を持つ開発者はより一般的であり、その結果、より安価になります。また、CE を使用すると、他のほとんどのディストリビューションよりも多くの "in the box" を取得できます。つまり、これらのことをまだ社内で行っていない場合は、市場投入までの時間が短縮されます。
少なくとも、私がよく知っているソフトウェアのカテゴリ (RF データ収集機器) については、Linux 側について話します。または、産業用アプリと消費者向けアプリ。
Windows CE (およびその関連ツール) (IMH かなり最近の E) は、小さな画面で "Windows エクスペリエンス" を作成することに強く偏っています。ユーザー入力モードでは、マウスのようなアクションが強調されます。ログオン、アプリケーションの選択などはすべて、可能な限り標準の Windows と同じようにしようとします。
ユーザーがリフト トラックを運転している場合、ピッキング カートに荷物を入れている場合、またはある場所から別の場所に材料を移動している場合、問題が発生します。
そして、特に .NET 側では、それは動くターゲットです。Compact .NET ランタイムは深刻な障害を抱えており、重要なライブラリ (ネットワーク、データ処理、UI など) は不完全であり、バージョンが以前のバージョンを非推奨にすることが多すぎます。. CE は Windows ファミリーの継子のようです (おそらく、ハードウェア インテグレーターへの積極的な販売競争があまり行われていないためです)。
安定した行と列の Linux コンソールは、多くの (私の経験ではほとんどの) 使用頻度の高いアプリを小さな画面で使用する場合に非常に便利なコンテキストです。
ただし、携帯電話や Zune でのゲームにはあまり適していません。
ノート：
ctacke はおそらくハードウェア インテグレーター側の言い分を正確に表していると思います。私は、ソフトウェア インテグレーターやユーザーなど、パイプの下流にいるプレーヤーとより連携しています。
多くの場合、具体的なデータではなく、主に認識と文化に基づいて選択が行われます。また、最新の OS の複雑さ、カスタム ハードウェアへの移植に関連するすべての問題、未知の将来の要件を考慮すると、具体的なデータに基づいて選択することは困難です。アプリケーションの観点からでも、プロジェクトの存続期間中に状況は変化します。要件は行き来します。特にそれが可能である場合は、思いもよらなかったことをしていることに気づきます。ユビキタスな USB ポートとネットワーク ポートにより、多くの可能性が開かれます。たとえば、Cell モデム サポートやプリンター サポートの追加などです。フラッシュ ベースのストレージにより、現場でのソフトウェア アップデートが標準操作モードになります。最終的に、各ソリューションには長所と短所があります。すべての場合に最適な特効薬はありません。
組み込み Linux の開発を検討するとき、私はよく氷山の例えを使用します。プロジェクトに入っていくのは水の上の部分です。これらは、アプリケーションがやり取りする部分であり、カスタマイズする必要があるドライバーであり、理解している部分です。残りの 90% は水中にあり、ここには大きな変動性があります。ドライバーの品質の問題や、将来サポートしたい可能性のあるドライバーが見つからない場合、プロジェクトの既知の部分が簡単に埋まってしまう可能性があります。WinCE と Linux の両方のソリューションの経験が豊富な人はほとんどいないため、快適なもの (または管理者が快適なもの)、または私たちが経験したものを使用する傾向があります。以下は、考慮すべき多くの側面に関する考えです。
システムソフトウェア開発
この分野での質問には、CPU サポート、ドライバーの品質、現場でのソフトウェア更新、ファイルシステムのサポート、ドライバーの入手可能性などがあります。過去 2 年間に起こった変化の 1 つは、CPU ベンダーが Linux を自社の新しいチップに移植しているということです。最初のOS。以前は、OS の移植は、通常、MontaVista などの Linux ソフトウェア企業またはコミュニティの取り組みによって行われていました。その結果、Linux カーネルはほとんどの主流の組み込み CPU をサポートするようになりましたが、追加のパッチはほとんどありません。これは、5 年前の状況とは根本的に異なります。多くの人が同じソース コードを使用しているため、問題が修正され、多くの場合、メインストリーム ソースにコントリビュートされます。WinCE では、BSP/ドライバーのサポートは参照実装に近い傾向があり、OEM/ユーザーがそれを利用して問題を修正すると、そこに修正が留まる傾向があります。
システムの観点から、将来のニーズに対する柔軟性を考慮することは非常に重要です。現在必須ではないからといって、将来も必須でなくなるとは限りません。周辺機器のドライバー サポートを取得することは、ほぼ不可能であるか、実用化するには多大な労力が必要になる場合があります。
ほとんどの人は、ビルド システムについてほとんど考えません。または、「ツールに優れた GUI が組み込まれている場合、それは簡単に違いない」という考え以外には目を向けません。OpenEmbedded は組み込み Linux 製品を構築するための非常に一般的な方法であり、最近 MontaVista の Linux 6 製品のテクノロジ ベースとして承認され、一般に新規ユーザーからは「使いにくい」と見なされています。WinCE ビルド ツールは表面的にはシンプルに見えますが (水面より 10% 高い)、何かをカスタマイズしたり、ソフトウェアの更新などの複雑な機能を実装したりする必要がある場合にどうなるかという問題が依然としてあります。製品グレードの製品システムを構築するにはOS を理解し、オペレーティング システムとビルド システムの両方の詳細レベルで作業できる人がチームに必要です。WinCE または組み込み Linux のいずれかを使用すると、これは一般的に、企業が経験豊富な開発者を社内に配置するか、専門家を雇ってシステム ソフトウェア開発の一部を行う必要があることを意味します。システムソフトウェアの開発は、アプリケーションの開発とは異なり、時間に余裕がある場合を除き、未経験で取り組みたいものではありません。企業が最初のいくつかのプロジェクトで専門家の助けを借りて、その後のプロジェクトを社内で行うことは非常に一般的です。考慮すべきもう 1 つの機能は、並列ビルドのサポートです。クアッド コア ワークステーションが標準になりつつある中、フル ビルドが 8 時間ではなく 1.2 時間で完了できることは大きな問題ですか? さまざまなリビジョン管理システムなど、さまざまなソースからソース コードをプルしてビルドする際のビルド システムの柔軟性。または、専門家を雇ってシステム ソフトウェア開発の一部を行うこともできます。システムソフトウェアの開発は、アプリケーションの開発とは異なり、時間に余裕がある場合を除き、未経験で取り組みたいものではありません。企業が最初の 2 つのプロジェクトで専門家の助けを借りて、その後のプロジェクトを社内で行うことは非常に一般的です。考慮すべきもう 1 つの機能は、並列ビルドのサポートです。クアッド コア ワークステーションが標準になりつつある中、フル ビルドが 8 時間ではなく 1.2 時間で完了できることは大きな問題ですか? さまざまなリビジョン管理システムなど、さまざまなソースからソース コードをプルしてビルドする際のビルド システムの柔軟性。または、専門家を雇ってシステム ソフトウェア開発の一部を行うこともできます。システムソフトウェアの開発は、アプリケーションの開発とは異なり、時間に余裕がある場合を除き、未経験で取り組みたいものではありません。企業が最初の 2 つのプロジェクトで専門家の助けを借りて、その後のプロジェクトを社内で行うことは非常に一般的です。考慮すべきもう 1 つの機能は、並列ビルドのサポートです。クアッド コア ワークステーションが標準になりつつある中、フル ビルドが 8 時間ではなく 1.2 時間で完了できることは大きな問題ですか? さまざまなリビジョン管理システムなど、さまざまなソースからソース コードをプルしてビルドする際のビルド システムの柔軟性。そして、多くの時間がない限り、経験のない人が引き受けたいと思うものではありません。企業が最初の 2 つのプロジェクトで専門家の助けを借りて、その後のプロジェクトを社内で行うことは非常に一般的です。考慮すべきもう 1 つの機能は、並列ビルドのサポートです。クアッド コア ワークステーションが標準になりつつある中、フル ビルドが 8 時間ではなく 1.2 時間で完了できることは大きな問題ですか? さまざまなリビジョン管理システムなど、さまざまなソースからソース コードをプルしてビルドする際のビルド システムの柔軟性。そして、多くの時間がない限り、経験のない人が引き受けたいと思うものではありません。企業が最初の 2 つのプロジェクトで専門家の助けを借りて、その後のプロジェクトを社内で行うことは非常に一般的です。考慮すべきもう 1 つの機能は、並列ビルドのサポートです。クアッド コア ワークステーションが標準になりつつある中、フル ビルドが 8 時間ではなく 1.2 時間で完了できることは大きな問題ですか? さまざまなリビジョン管理システムなど、さまざまなソースからソース コードをプルしてビルドする際のビルド システムの柔軟性。完全なビルドが 8 時間ではなく 1.2 時間で完了できることは大きな問題ですか? さまざまなリビジョン管理システムなど、さまざまなソースからソース コードをプルしてビルドする際のビルド システムの柔軟性。完全なビルドが 8 時間ではなく 1.2 時間で完了できることは大きな問題ですか? さまざまなリビジョン管理システムなど、さまざまなソースからソース コードをプルしてビルドする際のビルド システムの柔軟性。
組み込みプロセッサはますます複雑になっています。CPUを稼働させているだけではもはや十分ではありません。TI の OMAP3 CPU ファミリを検討している場合は、次の質問をする必要があります。3D アクセラレーション エンジンで使用できるライブラリはありますか? また、年間数百万ユニットにコミットしなくてもライブラリを入手できますか? DSP ブリッジのサポートはありますか? このすべての費用はいくらですか？私が関わった最近のプロジェクトでは、Atmel AT91SAM9260 用の基本的な WinCE BSP の価格は 7000 ドルでした。開発者の時間に関しては、これは多くはありませんが、メンテナンス、オペレーティング システムの新しいバージョンへのアップグレードなどの継続的なコストも考慮する必要があります。
アプリケーション開発
Embedded Linux と WinCE はどちらも、さまざまなアプリケーション ライブラリとプログラミング言語をサポートしています。C および C++ は十分にサポートされています。WinCE の世界では、ほとんどのビジネス タイプのアプリケーションが C# に移行しています。Linux には Mono があり、これは .NET テクノロジを幅広くサポートし、組み込み Linux システムで非常にうまく動作します。Embedded Linux で使用できる Java 開発環境は多数あります。違いが生じる領域の 1 つは、グラフィックス ライブラリです。一般に、Microsoft のグラフィカル API は Linux では十分にサポートされていないため、大規模なアプリケーション チームが熱心な Windows GUI プログラマーである場合は、おそらく WinCE が理にかなっているでしょう。ただし、Windows PC と組み込み Linux デバイスの両方で実行される GUI ツールキットには多くのオプションがあります。例としては、GTK+、Qt、wxWidgets などがあります。Gimp は、Windows で実行される GTK+ アプリケーションの例ですが、他にも多くのアプリケーションがあります。GTK+ および Qt への C# バインディングです。WinCE 分野で強力になっていると思われるもう 1 つの機能は、Windows Communication Foundation (WCF) です。ただし、必要な部分に応じて、WCF を Mono に移行するプロジェクトがあります。Python などのスクリプト言語に対する組み込み Linux のサポートは非常に優れており、Python は 200MHz ARM プロセッサ上で非常にうまく動作します。
WinCE はリアルタイムで、Linux はリアルタイムではないという認識がよくあります。Linux のリアルタイム サポートは、PREEMPT オプションを使用したストック カーネルで適切であり、リアルタイム サポートは、比較的小さなリアルタイム パッチの追加により優れています。Linux ではミリ秒未満のタイミングを簡単に実現できます。これは、リアルタイム機能がストック カーネルに統合されたことで、ここ数年で変化したことです。
開発の流れ
生産的な環境では、ほとんどの高度な組み込みアプリケーションは、ターゲット ハードウェアではなく、PC 上で開発およびデバッグされます。ターゲット システムでのリモート デバッグが適切に機能する設定であっても、ワークステーションでのアプリケーションのデバッグはより適切に機能します。したがって、一方のソリューションには優れたオンターゲット デバッグ機能があり、もう一方のソリューションには機能がないという事実は、実際には関係ありません。データ中心のシステムでは、実際の I/O に接続せずにアプリケーションをテストできるシミュレーション モードを用意するのが一般的です。Linux と WinCE アプリケーションの両方で、組み込みデバイスのアプリケーション プログラミングは PC のプログラミングに似ています。組み込み Linux はこれをさらに一歩進めます。組み込み Linux テクノロジはデスクトップおよびサーバー Linux テクノロジと同じであるため、デスクトップ/サーバー用に開発されたほとんどすべて (システム ソフトウェアを含む) は組み込み用に無料で利用できます。これは、非常に完全なドライバー サポート (上記の USB セル モデムとプリンターの例を参照)、堅牢なファイル システム サポート、メモリ管理などを意味します。 Windows CE のような統合ソリューションで、すべてが 1 か所から提供されます。柔軟性が失われますが、場合によっては、トレードオフの価値があるかもしれません。Openembedded を使用して組み込み Linux システム用にビルドできるパッケージの数の例については、を参照してください。また、Windows CE のようにすべてが 1 か所から提供される、より統合されたソリューションを好むでしょう。柔軟性が失われますが、場合によっては、トレードオフの価値があるかもしれません。Openembedded を使用して組み込み Linux システム用にビルドできるパッケージの数の例については、を参照してください。また、Windows CE のようにすべてが 1 か所から提供される、より統合されたソリューションを好むでしょう。柔軟性が失われますが、場合によっては、トレードオフの価値があるかもしれません。Openembedded を使用して組み込み Linux システム用にビルドできるパッケージの数の例については、を参照してください。
GUI トレンド
携帯電話 (iPhone、Palm Pre など) によって駆動される小さなディスプレイを備えた組み込みデバイスの傾向を考慮することが重要です。デスクトップ システムで一般的な標準の GUI ウィジェット (ダイアログ ボックス、チェック ボックス、プルダウン リストなど) は、最新の組み込みシステムには適していません。そのため、3D 効果のサポートと、タッチ スクリーン デバイスで使用するように設計されたウィジェット ライブラリを検討することが重要です。Clutter ライブラリは、このタイプのサポートの例です。
リモートサポート
デバッグ ツールの問題に戻ると、ほとんどの人は、デバイスがラボのワークステーションの横に設置されているというシナリオに立ち止まります。しかし、世界中でベータ テストが行われているデバイスのトラブルシューティングが必要な場合はどうでしょうか。これが、Gdb のようなコマンドライン デバッガーが有利な点であり、不利な点ではありません。また、ニュージーランドでセル モデムがサポートされていない場合、またはシェル アクセスとファイル転送用の ssh のような効率的な接続メカニズムがない場合、どのようにデバイスに接続しますか?
まとめ
高度な技術を選択することは簡単なことではなく、経験を積んだとしてもかなり困難です。したがって、適切な質問をし、さまざまな角度から決定を検討することが重要です。この記事がその一助になれば幸いです。
OEM ボードのソフトウェアのカスタマイズを含むプロジェクトに携わったことがありますが、Linux の方が安いとは言えません。ボードを購入するときは、SDK も購入する必要があります。Linux 版でも料金を支払う必要があります。一部の製造元は、ボードに Windows CE と Linux の両方のソリューションを提供しており、価格の違いはありません。Windows CE の場合は、Platform Builder も必要で、ライセンス料を支払う必要がありますが、サポートがない方が簡単です。
もう 1 つの重要な問題は、ユーザー インターフェイスまたはヘッドレス デバイスを作成する場合です。LCD スクリーンと人間の対話を必要とするデバイスの場合、Windows CE を使用する方がはるかに簡単です。一方、ヘッドレス デバイスを構築している場合、特にネットワーク プロトコルが関係している場合は、Linux の方が適切なオプションになる可能性があります。Linux の実装はより信頼性が高く、微調整が容易であると私は信じています。
Linuxを使用すると、自分自身に依存することはなく、アクセス許可を提供するために1つのエンティティに依存することもありません。多くのサポートオプションがあり、多くの競合するソースを通じて、システムの任意の部分のサポートオプションを自由に選択できます。
Windows CEでは、同意する必要のある複雑なライセンス契約に記載されているライセンスと制限を順守する必要があります。弁護士を呼んで。Windows CEでは、OSをサポートするための独自のソースが1つだけあり、必要なものをサポートおよび提供するのに適していると思われる場合にのみ続行します。あなたは彼らの立場に同意しないかもしれませんが、彼らが規定することに屈する以外に頼ることはできません。インクリメンタルコンポーネント、モジュール、開発キット、ライセンス、およびサポートのコストは、独自のプラットフォームに積み重なる傾向があります。長期的には、ベンダーがプラットフォームのサポートを望まなくなり、プラットフォームを自分でサポートおよび配布する権利がない場合はどうなりますか？ベンダーが新しいテクノロジーに移行し、移行する準備ができていなくても、ベンダーと一緒に移行することを望んでいる場合はどうなりますか？$$$
一般的なWindowsソリューションの経験では、時間の経過とともにコストが高くなる傾向があります。当初は最低のTCOと見なされていたものが、維持とサポートに支障をきたし、コストがかかるソリューションにすぐに引き寄せられます。ライセンスは時間の経過とともに再交渉する必要があり、多くの場合不要な新しいテクノロジーは、ビジネスニーズのためにプロバイダーの気まぐれで強制されます。その上、ライセンス契約は継続的に変更されています-弁護士を雇ってください。
Linuxを使用すると、必要に応じてソリューションを配布することに煩わされることなく、社内のサポートと専門知識を自由に提供できます。また、元のプロバイダーがサポートしたくないテクノロジーを引き続き使用およびサポートする自由もあります。ソースコードとそれを必要なもの（GPL、LGPL）で処理する権利を持つことは、ビジネスの継続性とコストの抑制に関して強力な魅力であり、最新のテクノロジーやニーズに合ったテクノロジーへのアクセスを提供します。
RT Linux (具体的には、RT パッチを適用した Linux プリエンプティブ カーネル) と Windows CE の両方で動作するネットワーク ドライバーを開発しました。私の経験では、Windows CE はリアルタイム応答に関してより安定していました。フレーム タイミングも、Windows CE の方がジッタが少ないことを示しました。
RT Linux では、さまざまな問題がありました。たとえば、ユーザーがマウスを動かしたとき。私たちのフレームは遅れていました。x-windows の特定の亜種は割り込みを無効にします。また、コンソール画面のみの方が安全だと感じるかもしれません. VGA フレーム バッファを有効にしている場合は、再び失敗する運命にあります。ジッターに関して、Windows CE には 1 つだけ問題がありました。この問題は、BIOS で USB コントローラが正しくないモードに設定されていて、Windows CE がポーリングに多くの時間を費やしていたときに発生しました。
正直なところ、Windows CE の方がサポートが多かったです。Linux では、自分で作業します。どのような問題が発生する可能性があるかを理解するには、考えられるすべてのメーリング リストを読む必要があります。
部分的にカスタマイズされた OS
OS がオープン ソースである (そして専門知識がある) 場合は、はるかに簡単に実現できます。
Android は、一部の組み込みシステムに適したオプションです (Linux ベースです)。
このシステムで開発できる多くの専門家がいます。
Java または C の多くのライブラリにアクセスできます。
しかし、それは多くのメモリとエネルギーを消費します。
有料/ライセンス付きのソフトウェアについて忘れがちなことは、ライセンスに対処する必要があるということです。時間とエネルギーが必要です！次に、正しく支払ったかどうかを追跡する必要があります。さまざまなスキルを持つさまざまな人々が関与し、意思決定にコストがかかります。
このコストは、オープンソース/無料ソフトウェアが有料ソフトウェアよりも高価であることを示す調査に含まれていないことがよくあります。
「フリー ソフトウェア」を使用すると、ライセンスの処理がはるかに簡単になり、これらの問題の処理に費やす時間が短縮されます。個人的には、ソフトウェアの一部を変更するたびに、法務/財務チームとの不必要なコミュニケーションを避けることを好みます.