アカウント名:
パスワード:
Microsoft を叩く発言が多いけれど、それでは実際にどこが適切なサプライヤーなのかを挙げてみて欲しいと思います。
素人がドライバーの過剰なまでに過酷な即時性を要求する操作に対して軽快に反応して他ユニットへ伝達するという点のみで考えると、Microsoft 製品では現行の Intel 製品を利用したハードウェア上に MS-DOS (with DOS-Extension) により制御させるというのはそれなりにいけるのではないかな、などと思ってしまいます。
Windows XP Embedded を RTOS として 利用する、という点でみると INtime を利用する [microsoft.com]ソリューションを提供する TenAsys 社 [tenasys.com]などがあるようですが、これらを利用したソリューションを提供したことがある方などに、Windows XP Embedded でも十分な信頼性を提供できる可能性なども話を聞いてみたいように思います。
# RTOS という点においては、BSD 系から Linux にシフトした WindRiver とかはどれだけ信頼できるかは不安なのですけど。Linux だとスケジューラを完全に実装しなおさないと RTOS として、確かな信頼性を得るのは難しいとしか思えないので。
はっきり言って、こうしたソフトウェアを提供する企業の中で、万が一何らかの事故が起きた場合でも対応しきれる体力を持った会社を選んだとしか思えません。
# なんでRTOSの話にBSDやLinuxが出てくる?
XP Embeddedが入ったPOSレジが横にあったりしますが、これは普通に落ちます。RTOSでもないし。
以前仕事で VxWorks を利用したときには、あまり RTOS としてのメリットが感じられなかった (要求に対する応答遅延が激しすぎ) 上に、ただの Unix 互換環境じゃん、としか感じられなかったというのが大きかったりします。
バージョンを上げられないという制約があったのも、原因にあるのかもしれません。
Web サーバとして使っていたので、遅延大きすぎというのは Web ブラウザ上からの応答が、という話です。遅延が激しすぎるのは、kernel に組み込んだ Web サーバモジュールの出来が悪いと言われたらその通りですが。(そこは某 FSI 社 に突っ込みたいところ)
Windows Embedded が落ちまくるのはドライバの問題じゃ? という気が激しくする訳ですが、その辺りはどうなのでしょうか。
そりゃ皆さんブルーバックがどうたらって言っているんだから考慮済みでしょう。
#実際はヘッドレスだろうけどね。
実績の有るサプライヤー(マネッティ・マレリなど)ではなく、マイクロソフトが選ばれた理由は、今のところ不明です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
MS 叩きが多いけれど (当然か) (スコア:2, 興味深い)
Microsoft を叩く発言が多いけれど、それでは実際にどこが適切なサプライヤーなのかを挙げてみて欲しいと思います。
素人がドライバーの過剰なまでに過酷な即時性を要求する操作に対して軽快に反応して他ユニットへ伝達するという点のみで考えると、Microsoft 製品では現行の Intel 製品を利用したハードウェア上に MS-DOS (with DOS-Extension) により制御させるというのはそれなりにいけるのではないかな、などと思ってしまいます。
Windows XP Embedded を RTOS として 利用する、という点でみると INtime を利用する [microsoft.com]ソリューションを提供する TenAsys 社 [tenasys.com]などがあるようですが、これらを利用したソリューションを提供したことがある方などに、Windows XP Embedded でも十分な信頼性を提供できる可能性なども話を聞いてみたいように思います。
# RTOS という点においては、BSD 系から Linux にシフトした WindRiver とかはどれだけ信頼できるかは不安なのですけど。Linux だとスケジューラを完全に実装しなおさないと RTOS として、確かな信頼性を得るのは難しいとしか思えないので。
はっきり言って、こうしたソフトウェアを提供する企業の中で、万が一何らかの事故が起きた場合でも対応しきれる体力を持った会社を選んだとしか思えません。
Re:MS 叩きが多いけれど (当然か) (スコア:2, 参考になる)
それ以前にGUIいらないなら、Windows無しでINtimeだけ起動できるんだけど・・・
ただx86CPUは発熱大きくて組み込みには向かないでしょう。実際にはWindows CE(+ T-Kernel)になるんじゃ無いかな。
#中の人だけどID
Re:MS 叩きが多いけれど (当然か) (スコア:1)
# なんでRTOSの話にBSDやLinuxが出てくる?
XP Embeddedが入ったPOSレジが横にあったりしますが、これは普通に落ちます。RTOSでもないし。
-- siu
Re:MS 叩きが多いけれど (当然か) (スコア:1)
以前仕事で VxWorks を利用したときには、あまり RTOS としてのメリットが感じられなかった (要求に対する応答遅延が激しすぎ) 上に、ただの Unix 互換環境じゃん、としか感じられなかったというのが大きかったりします。
バージョンを上げられないという制約があったのも、原因にあるのかもしれません。
Web サーバとして使っていたので、遅延大きすぎというのは Web ブラウザ上からの応答が、という話です。遅延が激しすぎるのは、kernel に組み込んだ Web サーバモジュールの出来が悪いと言われたらその通りですが。(そこは某 FSI 社 に突っ込みたいところ)
Windows Embedded が落ちまくるのはドライバの問題じゃ? という気が激しくする訳ですが、その辺りはどうなのでしょうか。
Re:MS 叩きが多いけれど (当然か) (スコア:0)
> という気が激しくする訳ですが、その辺りはどうなのでしょうか。
メモリとかリソースとかリークしていても難なく動いてしまう様な、
そんな環境でしかプログラムを書いた事がない開発者を許容してしまう、
ある意味で大変おおらかな環境が、
組込み用途でよく落ちるシステム(開発者)を排出しているんですよ。
# 思い込みかもしれないのでAC
Re:MS 叩きが多いけれど (当然か) (スコア:0)
組み込み系の知識があまり無いからでしょ。日経コンピュータは読んでもエレクトロニクスは読まない人たちが
ここのメインでしょうから。
Re:MS 叩きが多いけれど (当然か) (スコア:1, 興味深い)
せいぜいMIPSとかARMとかColdFireをコアにしてメモリとペリフェラルをぶら下げたワンチップMCUがいい所だと思いますけど。
高級な所でPowerPC40x系、低級ならば68HC12系ってあたりな訳で…
そういう物には既にeCosやらμITron系やらOS-9やらエンジン制御のようなクリティカルな用途に使われた実績を持つRTOSがゴマンとあるし、究極的にはRTOSのっけないでやってしまうという事も未だにある訳で…
MSがこの領域に手を出すのは開催側のブランド嗜好とかMS側が箔を付けたいとか色々色気があるからなんでしょうけど、なんか納得がいかないんですよね。
OS-9ナツカシス (スコア:1)
ええ、当然キモヲタだったのでモテませんでしたよ。
屍体メモ [windy.cx]
Re:OS-9ナツカシス (スコア:2, 参考になる)
当時の用語はキモヲタではなく、根暗です。
性格的に根が暗いかどうかはこの際関係なく、「マイコン少年? 根暗なの?」とされた時代でしたなあ。(遠い目)
Re:OS-9ナツカシス (スコア:0)
コミュニケーションぶりのせいでしょう
空気嫁無い (スコア:1)
失礼しました。
屍体メモ [windy.cx]
Re:空気嫁無い (スコア:0)
空気は吸うものだ。
# 保守派
Re:MS 叩きが多いけれど (当然か) (スコア:1)
なんかマック系サイトで「Intelじゃ熱くてF1マシンに乗せられないんだよ! PPCなら発熱低いからね!」みたいなこと書いてあって吹き出した覚えが。
CPUなんかよりよっぽど発熱するもんが積まれてるというのに……
Re:MS 叩きが多いけれど (当然か) (スコア:2, すばらしい洞察)
これを書いたヤツは、冗談で書いたんだろうけど、吹き出すような内容じゃないね。エンジンの方が熱いから問題ないだろうと単純に考えているんだろうけど、冷却によるドラッグを考えれば、少しでも発熱は低いほうが有利ですしね。
それに、車載用コンピュータは、電磁波対策で分厚いケースに囲まれてたり、粉塵対策にファンがなかったりしますから、発熱の問題は重要だと思いますよ。まあ、それでも演算速度が速い方がレースに有利なら使うでしょうけどね。
CPUの発熱ぐらいまで気を使うようじゃないと、F1では勝てないでしょうね。
発熱と電力消費量の関係 (スコア:0)
電力消費量が増えればハーネスを太くして、バッテリー容量を増大させて、オルタネーターを増強して、と重量増加要因になる。
重くなるだけじゃない。
オルタネーターの負荷増大はパワーユニット全体の出力配分に悪影響するし燃費の悪化要因になる。
エンジン本体の冷却損失に加えて電子機器の発熱による損失が無視できないほど大きくなると車両デザイン全体に影響してくる。
それに加えて燃費はチームの作戦を左右するのでレース展開にも影響してくる。
市販車でさえグラム単位で重量削減の努力をしているのにF1カーですよね。
無駄を極限まで削ぎ落とした機能美とは正反対の方向性だよなぁ。
Re:MS 叩きが多いけれど (当然か) (スコア:0)
GPUのことですか? とマジボケしてみる。
Re:MS 叩きが多いけれど (当然か) (スコア:0)
そりゃ皆さんブルーバックがどうたらって言っているんだから考慮済みでしょう。
#実際はヘッドレスだろうけどね。
Re:MS 叩きが多いけれど (当然か) (スコア:1)
# 触ったことないのでどの程度のものかは知らないですが……
# それだけだけどID
Re:MS 叩きが多いけれど (当然か) (スコア:1)
携帯電話クラスなら十分ですが、はっきりいってmsecどころかμsecレベルの応答性能を要求されるECUみてーな制御系ではぜんぜんお話になりません。
#まあ、携帯電話でもスマートフォン級のリソースがないとLinuxはかなり苦しいようですが。
Re:MS 叩きが多いけれど (当然か) (スコア:1, すばらしい洞察)
リアルタイム OS って応答時間のワーストケースが保証されてて、それを当てにしてシステムが組めるものだと思ってました。保障された応答時間が遅くても、遅いなりに保障されないと困る分野に使用するもんだと。
Re:MS 叩きが多いけれど (当然か) (スコア:1)
Re:MS 叩きが多いけれど (当然か) (スコア:1)
ワンメイクのサプライヤって、それ自身が巨大なスポンサーであることが殆どですからね。
プライベーターをFIAが味方につける為に、共通ECU搭載を前提に巨額スポンサーマネーを保証、
とかいうのは普通にやりそうですし。
ワークスにしても、タバコマネーの撤退があるから、資金繰りは厳しくなってるし、
BMWやマクラーレンのような、お金のないワークスもその流れに追随するかも。
Re:MS 叩きが多いけれど (当然か) (スコア:0)
ソフトウェアは Windows という発想しかできないのだろうかここの連中は。
もし本気でそうなると信じているならアホにも程がある。
ネタとして楽しめるというのは否定しませんよ。
#もっとも悪い意味で僕らの期待を裏切らないベンダーだけどな、M$は
Re:MS 叩きが多いけれど (当然か) (スコア:1)
「でかい・複雑・低信頼性」ってイメージ(と実績)がありますから。
F1のように、極小さと高信頼性を求められるところに出ようとすると、
こういう論評があつまるのは仕方ないかと。
どこまで出来るかな?