Real　Time Operating Systemスレ

みなさんは組み込みマイコンのRTOSになにをつかっていますか？
ITRON?
Linuｘ？

NetBSD

つーか、半角と全角の区別も付かない馬鹿が糞スレ建てるな、と。

自作OS

NeetBSD

一瞬擦れたい見て何のスレか理解できなかったわ

リアルタイムos(rtos)
とかにすればよかったのにねw

使いやすいリアルタイムosって結局どれ？

作るのが楽なのならμITRON
サブセットなら機能少なくていいし、仕様は練られてて固まってるし。

OOPで書けばRTOSなんて要らないと思うが？

OOPで書けばどこからともなくセマフォとか割込みハンドラが使えるようになるのか。
初めて聞く説だ。

おれもITRONに一票。

POSIXな機能を使いたいならLinuxかNetBSD
GPLがダメならNetBSD
商用プロダクトまで入れるならVxWorksやQNX

俺もNetBSDに一票。

つーかOOPって使える時点で既にOSの上に乗っかってるだろ。
不要なのはOOPの方じゃん。MMU無しのアーキで構わないから、そのOOPとやらで
sbrkを実装してから出直してくれ。

>>11
MMU無しのアーキでNetBSD動かしてくれｗ

LinuxやNetBSDはリアルタイムOSではない。
RTOSでPOSIXな機能を使いたいならeCosがある。

WindRiver

mmuなしでnuetbsdって動作しないものなの？
ulinuxってmmu梨でもメモリ管理で問題内の？

ITRON(HOS Ver.1.02)

wait_evf

お前らがrecv_mbxしたら一生待ち状態だろうな

過去を振り返るとさりげなく何通か入っていたぞｗ

この板的にはmmu無しの話だろ？　ワンチップレベルの？

MQX

Norti

もうだいぶITRONにもなれてきた。

mmu無しワンチップレベルのrtosでシステムデザインなんかやってるとダイクストラの構造化呪縛から逃れられないぞ
oopでやれ！　セマフォ？　メッセージドリブンにすれば要らないんじゃね
メッセージキュー時のlock処理とディレードキューが必要だが簡単だ
ヒューマン入力インターフェースの会話が楽になるぞ！　デザパタのStateだからな　ｗ
もう　rtosはオワコンの時代

やっとITRON（HOS V4)上でSH/7045がまともに動いてくれた。
次はSH/7144だ。
（時代遅れもはなはだしいけどねｗ）

age

タスクを機能モジュールとしてリンクするなんていうシステムデザイン手法はもう終わってるんだがね
タスクをオブジェクトとして？　んなもん肥大化し過ぎるしオブジェクトの挙動にならねぇ
タスクをアプリとして？　そりゃワンチップの世界じゃねぇ

とどのつまりRMSはソフトウェア哲学としてはオワコン！
RMSの用途？　高速応答、高速制御だろうが　今の時代　tiny2313あたりやFPGAを並べればええ事

> 高速応答、高速制御

違う。最悪応答時間が保証されること。

RMSって何？

やっとSH/7144上でITRONが動いた。
これもちょっと苦労したな
同じSH2でも7144のほうがレジスタ数が多いし、しかも割り込みの優先順位などを決めるレジスタを適切に設定してやらないとうまくうごかんかった。

>>28
GNUプロジェクトを推進してるFSFのグル。

しかし、いまだにXINUの亡霊を見るとは…

>>30
なるほど、26は
”リチャード・ストールマンの哲学は終わっている”
という主張なのかｗ

でも、ストールマンは高速応答しないよねｗ

昔、GNUソフトの流用についてmailで質問送ったら、2分で返事来たよ。

GPLか
自分の恥ずかしいコードを晒すのは何となくイヤだな

大量生産しないんならタスクごとにマイコン載せるんじゃダメですかね
ライセンス費や習熟の手間を考えたら割に合うのでは

っ[故障率・信頼性]

OOPでも高速応答できるよ　C#とかPCの世界では無理だが　ファームウェアの世界はなんでも有りなんで　ｗ
しかし　となると　RTOSの弊害であるシステムデザインの構造化閉塞というのは致命傷かもしれんな

日本語で、プリーズ。

>>34
タスク間で同期を取るのがめんどくさそうだな
全タスク完全非同期でよければありかもしれんが、まあそんな都合のいい話はないからのう

>>34
ソフト的、ハード的なインターフェースは存在するから、
ある程度ソフトで済ませた方が楽なんじゃね？

ハードの構成が面倒くさいから、ソフト内でマルチタスクした方が楽ちん、
と言う思想はあったはず。

サウンド処理をz80に遣らせていたメガドライブとか、
i/o周りを別のプロセッサに処理させてたソニーのワークステーションとか、
いちいち外部装置ごとにプロセッサが有って通信し合ってるメインフレームとか
思い出した。

昔の機械はあちこちに専用のcpu一杯載っててマルチプロセッサだった気が。

今のPCだってあちこちに専用のCPU載ってるよ。
ネットワークカードに68k系のチップとかインテルのRISCが載ってたり、
ノートPCのバッテリー管理用にH8が載ってたり、
グラフィックカードはGPUと呼んでるか、まぁ、プロセッサが載ってるし。

>>40
>i/o周りを別のプロセッサに処理させてたソニーのワークステーションとか、
同じ680[23]0にやらせてた。マルチプロセッサだけど、SMPじゃないんだよね。
DMAC載せるより、同じCPU載せる方が安上がりで、しかも速いってだけで。

>>41
最近のNICにはCPU載ってないよ。昔のexelanとかi80186載ってたり、
今でもArduino(8bit)のイーサシールドにColdFire(68k 32bit)載ってたりしたけど。
RAIDカードは今でもPPCやi960/33MHz載ってるのが有るな。Core-i7やPhenom2x6
でソフトウェアRAIDした方が圧倒的に速いけど。
グラボはGPUが速くて、並列処理が効くならCPUより速いし、その速度向上ペースが
CPUより速いので、最近のスパコンはCPUは単なるメモリコントローラで、GPUを
(予算の限り)並べる作業に成ってるが。

FreeRTOSの説明書を購入してしまった。$35。円高の今だから悪くはない気がする。
ちなみに全部英語ですがｗ

>>41
すっかり忘れられたKBCがかわいそう…

>>42
例外処理専用の68000載せていたのはApolloだっけ？

例外処理っていうか、仮想記憶のページイン/ページアウト処理

専用ってわけでもなくて、普段はグラフィックプロセッサをやってる

SUN-1も。SUN-2は単なるX端末。
SUN-3から普通?のWSに成った。

電波テロ装置の戦争(始)エンジニアさん参加願います公安はサリンオウム信者の子供を40歳まで社会から隔離している
オウム信者が地方で現在も潜伏している
それは新興宗教を配下としている公安の仕事だ
発案で盗聴器を開発したら霊魂が寄って呼ぶ来た
<電波憑依>
スピリチャル全否定なら江原三輪氏、高橋佳子大川隆法氏は、幻聴で強制入院矛盾する日本宗教と精神科
<コードレス盗聴>
2004既に国民20%被害250〜700台数中国工作員3〜7000万円2005ソウルコピー2010ソウルイン医者アカギ絡む<盗聴証拠>
今年５月に日本の警視庁防課は被害者SDカード15分を保持した有る国民に出せ!!<創価幹部>
キタオカ1962年東北生は二十代で2人の女性をレイプ殺害して入信した創価本尊はこれだけで潰せる<<<韓国工作員鸛<<<創価公明党 <テロ装置>>東芝部品)>>ヤクザ<宗教<同和<<公安<<魂複<<官憲>日本終Googl検索

キーボードにもマウスにもCPUが入ってるしな。

i8051…intel入ッテル!

のもこみ

i8051なんてまだ使ってるか？

キーボードのcpuにウイルス送り込んだり出来るのかw

昔、Macのプリンタに送り込むウィルスって有ったな。

マカはプリンタもウイルススキャンしてそうだなw

想像力のないドザはこれだからな。

最近のプリンタが積んでる機能を見れば、ウイルスが作られるようなセキュリティホールが
残ってる可能性は十分にある。

恥ずかしい印刷してその内容がネットに公開されたりするのか。
マカって大変だなw

ドザ必死だな

ARMスレから来たので亀レス

>>44-45
> 例外処理っていうか、仮想記憶のページイン/ページアウト処理
そのアポロかどうかは知らないけど、確か少し命令を先に実行して、実空間の範囲内外をメインCPUが実行する前に検知。
それでスワップ処理してメインCPUが止まるのを避ける機構だったよね。

> 普段はグラフィックプロセッサをやってる
そんな処理する余裕ってあったの?

>>51
PSoC3が8051。
そのPSoCスレで説教垂れる御仁曰わく、沢山使われているらしい。

俺も最近、GbEチップの中に入っているのを見つけた。

>>58

> そのアポロかどうかは知らないけど、確か少し命令を先に実行して、実空間の範囲内外をメインCPUが実行する前に検知。

というような説明がよくされているけど、そんなふうに2個のMPUを同期させて、片方が
ちょと先を実行、とか事実上無理。RISCみたいに各命令のクロック数が同じでもないし。

> それでスワップ処理してメインCPUが止まるのを避ける機構だったよね。

68000では、メモリエラーのような、命令の実行途中で起きる例外で、例外ハンドラに
移行してしまうと、元の命令に戻って再実行する方法がない。だから、止まるのを
避けるのではなく、メモリエラーが発生した時点で、MPUを止めてしまうわけ。
（運良く？）68000は、命令の途中でも止めることはできた。

止めてしまって、別のプロセッサでスワップをして、そのあと、メインMPUの動作を再開して、
元の命令のメモリアクセスから実行させることができるので、それで無事実行される、
という仕掛け。

だから、スラッシングが起きているのでもなければ、普段はサブプロセッサは暇なわけ。

ttp://www.st.rim.or.jp/~nkomatsu/mc68k/MC68000.html このページの最後のほう、
「MC68000を用いて仮想記憶を実現するのは困難で、
から始まるところに詳しく書いてある。

>>60
プログラム実行領域限定のSWAPなら
バスフォルトが起こるとCPUは、NOP
が読めるようにして割り込みをかける
と自力でSWAP出来ると思うがどうな
んだろ？

>>60
> ちょと先を実行、とか事実上無理。RISCみたいに各命令のクロック数が同じでもないし。
簡単だよ。
メモリコントローラは今何処を実行しているかが判る。
あとは適時wait信号を出すだけ。

SUN-1の車輪を再発明するスレに…

FPGA使ってバスに繋ぐメモリサーバ的な物を作ったら面白いかと思った。
機能的にはMMU+メモリコントローラ+キャッシュ+スワップデバイスへのI/Oてな感じ。
CPU側からは待たされるだけで、透過的に仮想記憶にアクセスできる。
まあ、外部メモリ用のピンが出てて、仮想記憶を積んでないチップなんて多くないけど。

キャッシュとして積むメモリをCPUのリニア空間に実装した方が、はるかに
柔軟性が高くアクセス速度も速いと思うが？

想定しているCPUの動作クロックは？MMUのルックアップテーブルの容量と
レイテンシーはいくら？

ターゲットは、ST32F103CB6でRTOSを
使うとしたらどれが良いでしょうか？
freeRTOS、toppers、cooCox coOS
他にお薦めはありますでしょうか。

>>65
ソフト屋さん?
SRAMがDRAMよりどれほど高コストなのか、知らないの?

>>66
FreeRTOS。確かSTMicroがリリースしてた筈

>>64 だけど
>>65
少ない高速メモリを仮想記憶に使う話を書いたつもりなんだが、リニア空間に実装ってなんだよ。

RT性を考えるとスワップは要らんが、それ以外メモリ一式が丸投げできるデバイス
が有ると、色々捗るな。

>>65
学生？SRAMが高コストなのは、記憶ビットあたり、同等プロセスなら4倍の
トランジスタ数(≒ダイ面積)が必要なのと、市場が小さいからだよ。

>>69
少ないのはオマイの脳細胞じゃないか？

小容量のメモリは、必然的にヒット率が低い。したがって、頻繁にミス
ヒットして外部記憶へのアクセスが発生して効率が上がらない。

おまけに、いくらメモリが高速でもキャッシュ書き換えと、外部記憶への
ライトバックは、外部記憶のアクセス速度によって頭打ち。

I/Oバッファと基板上の配線による遅延が生じない同一ダイ上ならともかく、
アクセスタイム数ns程度が高速メモリを基板に並べてキャッシュに使う
なんて486DX時代の発想。

当時ですら一次キャッシュはCPUに内蔵されていたのに。

キャッシュではなく仮想記憶だといい、それもFPGA経由でぶら下げるなんて
妄想ができる知識レベルはある意味羨ましい。きっとタンポポがいっぱい
咲いているんだろうな。

>>70
それ、HDDやSSDが積んでいるディスクキャッシュと何が違うの？

うだうだ話しに何マジレスしてんだよ。
馬鹿なの？ しかも亀レスだし。

マジレス大いに結構じゃないか

馬鹿なんじゃねぇの

>>71
>それ、HDDやSSDが積んでいるディスクキャッシュと何が違うの？
ディスクキャッシュは、DRAMコントローラの面倒を一切見てくれない。

>486DX時代の発想。
SH4ベースの組込みRTシステムなんて、i486DX時代の技術レベルで止まってますが何か?
せいぜい当時はchipsetにやらせてたメモリコントローラが内蔵されたぐらいの違い。
抱き合わせでRAMまで1chipに内蔵してしまうから、マルチメディア機器なんかだと
容量足りなくなるので、DRAMは外付けにしたいのだがそうするとメモコンやキャッシュ
周りも新規に起こさないといけなくなって面倒臭いな、と思ってたところ。

SHはもうオワコンだからARMでやるとして、CCDの1行分が入るぐらいの小さい
キャッシュと、DRAMコントローラがFPGA1chipに丸投げできれば便利かもしれない。
スマホ向けSoCなら山ほど有るんだがなぁ。

ARM Cortex M3/M4あたりであれば、SRAM内蔵で、かつSDRAM用のインター
フェース持ってるデバイスは、各社それなりに揃っていますが？

SDRAMは、組込用としてMobile SDRAMが残るが、DDR2は既に縮小、DDR3も
主な需要先のPC市場の動向で、そのうちDDR4へ移行することになるだろう。

中途半端にFPGA使うとか、組込で向こう10年くらい修理サポートが必要に
なるとか、考えているのかね？

趣味の工作レベルならともかく、画像を扱うのに内部SRAMしかないデバイス
を選ぶのが間違っているし、ST MicroのSTM32Fあたりは、CCDカメラ用I/Fを
内蔵しているデバイスがあるので、DMA転送でRAMへ読み込めばいいだけ。

それどころか、元々車載向けに強かったMotorolaから分社化したFreescale
あたりだったと思うが、ARMベースで車載バックモニタ向け等に特化したSoC
もある。

i486DX時代の技術レベルで止まっているのは、ガラパゴスとその住人だけ。

>>76
支離滅裂になっているが、大丈夫か?

> M3/M4あたりであれば、SRAM内蔵で、かつSDRAM用のインター
> SDRAMは、組込用としてMobile SDRAMが残るが、DDR2は既に縮小、DDR3も
M3/M4にDDRをサポートしてるのなんて、無いよ。

話が随分逸れたな。
>>64
古典かもしれないが、現代に復活させるなら技術的に面白いな。

>>76
ARM7TDMIの頃はSDRAMif付き多かったけど
Cortex-MになってからはSDRAMif付きはめっきり見なくなった。
Cortex-A系との差別化の為だと思うけど。

なので低価格コントローラ向けSoCのSDRAMif付きには
まだまだARM926EJが位座ってたりするのだ。

>>78
Cortex-MでもSDRAMインターフェース付きはあるけど、ARM7の
頃と品種の数自体は大差ない感じがしてるなあ

MとAの間にRがあるはずなんだけどちっとも聞かないからARM9が
残ってるだけじゃねｗ

とんでもない自演を見た

そうですか

>i486DX時代の技術レベルで止まっているのは、ガラパゴスとその住人だけ。
そうは言われてもまだまだガラパゴスSH4の(国内)シェアは大きいわけで。

>Cortex M3/M4あたり
で、これは!…と思う石で外付けSDRAMif付きの奴って、そのSDRAMもChip on Chip
の2階建てSoCに成ってて、思うようなSDRAMを「外付け」出来ない奴ばっかなんだよな。
小さいCCDでも画素数が無駄に多過ぎなモノだらけなのも困った現状だが。
画素数より、感度とフレームレート(リアルタイム性)が欲しいのに。

このオッサン ID:0dmWfovc なんで最初から喧嘩腰なんだよ。

>>78
そうか? M3でも上位は結構あるけどな。
>>82
個人的には、日の丸CPUとしてSH-4Aには頑張ってほしいな。

>>64
> FPGA使ってバスに繋ぐメモリサーバ的な物を作ったら面白いかと思った。
面白いな。ターゲットはSH-2AかCortex-M3/M4あたりか?
ただ、SH-2Aには64MBの壁があって、連続させても128か256MBが限界か。

CPUは2つ以上繋げたいな。
かつ、CPUは仮想の仮想空間で実行。
実空間外にアクセスするとMPU(メモリープロテクト)が働く。
それをFPGAが検知出来ればいいんだか。

おっと、FPGAがDRAMとして振る舞えばもっと広いメモリ空間に見せることも出来るな。
そうすれば話はグッと簡単になるな。
デュアルにしたときのL1キャッシュの整合性はどうすんべ。

…と、知的好奇心的に興味深いな。
スレタイとは無関係だかw

SHシリーズは設計が古すぎるし、FPGAがDRAMとして振る舞うとか、
ワケワカメ。

DRAMコントローラって、何のためにあるのか知らないの?w

DRAMコントローラとDRAMは別だよね〜。恥ずかしいヤツ。

第一、いまどきMCUでも外部バスがあるマイコンならDRAMコントローラ内蔵
がフツーだよね。ｷｬﾊ　設計が古いSHに期待なんて言っている浦島脳じゃあ、
知らないのも無理ないかな。ｗ

もしかして、SDRAMじゃなくて、昔のマルチプレクサとRAS/CASでアドレス
を多重化していた時代とか、CASオンリーリフレッシュとかで止まっている
人なのかな？ｗ

それとね、MMUを積んでもアクセス違反でトラップされた命令を再実行でき
るCPUアーキテクチャでないと、バンク切替でメモリ空間が拡張されるだけ
で仮想記憶にはならんよ。

RTOSには邪魔なだけのMMUの話は他でやってくれ

>>87
> DRAMコントローラとDRAMは別だよね〜。恥ずかしいヤツ。
その通り。
で、DRAMコントローラはバンクを切り替えたり(重要)、アクセスとリフレシュを調停したり、そんなのをDRAMにコマンドを送りながら制御している訳だ。

>>85
> FPGAがDRAMとして振る舞うとか、ワケワカメ。
振る舞ったらどうよ?
バンク切り替え時にスワップイン/アウトしたらどうよ?
それはFPGAに繋いだDRAMが小容量でも、CPUのDRAMコントローラから見れば大容量DRAMに見える。

> 恥ずかしいヤツ。
こんな簡単な話を理解出来なかったお前に、そっくりそのまま返すわw

>>88 は〜い

>>89
学生か？意味も判らず頭に残ってるカタカナ語を並べているだけにしか
聞こえん。

必死過ぎてかわいそうな感じ

ゆとり最強伝説ですね。わかります。

ハード・リアルタイム・パフォーマンス
OS-9はあなたが決定論的なサブマイクロセカンド応答時間を外部イベントに必要とするアプリケーションに優れています。
Windowsやリナックスベースのシステムと異なって、OS-9は時間的クリティカルな組み込みソフトアプリケーションの高性能と高信頼性需要にこたえるように始めから設計されています。

>>94
OS-9ってリロケーションフリーが特徴なんだっけ？　相対アドレスモジュールのフル駆使だったような気が。
再配置して、コンテキストスイッチは楽だろうな。

6809＋MMUには、確かプロセスIDの設定を切り替えるだけでメモリバンクが変わる、
みたいな機能もあったはず。

キャッシュ外れても、DRAMリフレッシュ中でも、決定論的なハードRTって可能なのかな?

>>94
2MHzのCPUが500nsecで応答出来るの？

OS-9って、68070やPPC版も有るよ。

OS-9って、x86にARM版もあるよ。

>>97
CPUやOSによるけど、コアなところはキャッシュに留めておける。
正しくはキャッシュとして使わないんだけど。

OS-9が出来るかどうかは知らない。

でも最新インテルcpuみたいに凄く先読みしたあげくにミスキャッシュすると再読み込みで凄く待たされると思うけどね
それなら少量キャッシュでミス頻発するけど、その遅延も考慮するリアルタイム性を実装しとけば大幅に遅延なんてのも避けられるんじゃない

特急に乗れば平常運転の時は快適だけど、事故とかで詰まっちゃうとのろのろ運転で全然停車駅にたどり着けないと
普通に乗れば平常運転でも時間掛かるけど、事故で詰まっても最寄り駅停車まではいけると
みたいな感じ

リアルタイム性を重視するとmmuもdmaも邪魔だな
osが気づかない所で勝手に割り込みするなって感じ


例えばクアッドコアとかで４つのコアで全く同じ処理を並列実行させれば実コア数の４チャンネル分はリアルタイムで遅延泣く実行出来そうだけど、実際はコア間の同期で時間喰われるから凄く遅く成るなあ

>>102
TIのDSPがどうなっているか、見てみたら?

nuttxってどうよ　使ってるヤシ居る？

>>104
NuttXと eCosの違いって、なんなのさ?

つーかさ、CPUはARMで統一しはじめてるが、
RTOSもどっか１つに統一できねーもんかな。

どれも似たようなもんだし。
歌うほど、たいした差じゃねーし、
なきゃないでなんとでもなるだろ。

RTOSで１番っていったらどれ？
もうそれだけでやってけねーかね。

無理矢理1つと言うならVxWorksになるなのかな?

思うに大半のオプソなRTOSは使う事が目的じゃなくてOSを作る事が目的なんだと思うよ。それにこういうのは環境や目的によって適材適所だろ。メモリ一つとっても数KBから数GBオーダーまであるんだし。それを一番はどれとか意味不明。

その環境や目的というものに応じて、機能を限定し、多少メモリ利用効率を上げれば、
省メモリ動作なんて言うほど難しい話ではない。

RTOSが1つに統合出来れば、その程度の事にリソースをさくのはたいしたもんじゃない。

>>109
アーミーナイフ(十徳ナイフ)的なRTOSか、、、
小さい事に特化した精密ドライバーには負けるし、力持ちの電工ドライバーにも負ける。
一通りハサミやらも付いているが、、
結局中途半端なRTOS欲しいの？

RT-Linux...
ART-Linux...

>>110
省メモリ動作（数K）なんて、RTOSの基本機能に限定すれば簡単に
実現出来ると思う。

>>107
現在、RTOSで最も主流なのはVxWorksなのかね？
今後、"CPU"で言う"ARM"の立ち位置、つまり、"RTOS"という
分野のスタンダードになれるのか？

Linuxは今、最も勢いがあり素晴らしいが、ライセンス制約が厳しすぎる。
コード修正や保守が難しく、メモリ使用量削減が出来ない点や、
CPUにMMUが必要となる点で、CPUを選ぶOSとなってしまう。

RTOS枠でLinux語る人ってリアルタイム性なんて要らないんだろうな。>>111とかuLinuxみたいな亜流の話とも思えないし。

なぜ一本化出来ないんだろうって話はかつて日本ではスタンダードみたいな位置にいたitron系が最近はだんだん減っている理由を考えてみるといいよ。

というかCPUはARMに一本化されて・・・の下りから間違ってるんだけどな。組み込みの世界分かってなすぎ。

WindowsCEも、一応 RTOSなんだよね。びっくりだよねw

iTronって廃れたんだっけ?
ルネ系だと全然スタンダードな印象なんだけどぉ

ARMなら廃れたに同意

QNX なやつはおらんのか。

>>114
リッチな方はitron離れが進んでいる印象。だから減りつつあると書いた。そっち方面はQNX, VxWorksそしてリアルタイム性かなぐり捨ててAndroidを含むLinux系じゃないかな。

残念ながらCEはオワタと思ってる。俺の周りの環境ではitron, OS-9からCEになってQNXだわ。なんて書くと身バレしそうガクブル

お、さっそく登場か。
やっぱりGUIとかネットワークとかファイルシステムとか、POSIX API くらい無いとやってらんないっす。

Androidとか言ってる奴はRTOS知らんの?

>118
文意を汲む能力がないの?

>>119
「Real　Time Operating Systemスレ」で、スレ違の話する文意て何ぞ?

>>120
スレ違いと言うほどAndroidの話なんて出てないじゃん。何が不満なのさ？

>120
なるほど。その返答で能力が無いのがすごくよくわかった。
だからもう黙っててくれない?

>>122
RTOSからAndroidに変わった例でも挙げてみてからなんか言え

>123
尽く見当外れな事しか言えないのなら黙ってろ、というのがわからないの?

>>124
Androidの話が見当はずれだと言ってる。馬鹿は黙ってろ。

>125
このスレで誰よりも一番Android、Androidと連呼しているスレ違いのバカはお前だろw
自覚ないのか? そっくり返すよ、「馬鹿は黙ってろ」と。

>>126
>このスレで誰よりも一番Android、Androidと連呼しているスレ違いのバカはお前だろw

あれ? 文意によってはAndoroidの話してもいーだろって主張じゃなかったの?

>127
文意という語を誤解している印象だが、それはさておきそもそも何が不満なんだ?
「RTOSスレでAndoroidの語が出る事自体、どんな理由であれ一切まかりならん!」
と言いたいわけ?

>>128
>文意という語を誤解している印象だが、

http://dictionary.goo.ne.jp/leaf/jn2/197140/m0u/
> ぶん‐い【文意】
> 文章の表現しようとしている趣旨。文章の意味。「―をつかむ」

これ以外の意味があれば教えて呉。

>「RTOSスレでAndoroidの語が出る事自体、どんな理由であれ一切まかりならん!」
>と言いたいわけ?

「RTOSスレでお前なんで関係ない話してんの?」程度だな。

>129
その意味で合ってる。それを踏まえて自身の文章を読み返しても違和感を覚えないなら何も言うまい。
次。話の流れとか一切関係無く僅かでも非RTOSに言及したらそれ即ちスレに関係ない話である、って事?

>>130
>話の流れとか一切関係無く僅かでも非RTOSに言及したらそれ即ちスレに関係ない話である、って事?

RTOSを捨てる話の流れなんてないだろ。

>131
誤読ならすまないがそれはつまり、RTOSから非RTOSへの移行の話題はスレ違いで禁止、という主張?

そもそもそんな話題出てませんが？何と戦ってるんだ？

>133
131の意図する所はこうですか?という確認。
あれが正しい解釈なのか確証がないからこそ誤読ならと初めに断ってる。
違うなら違うでどう違うか言えばいいだけ。そんな言い方ではなく。

>>132
>RTOSから非RTOSへの移行の話題はスレ違いで禁止、という主張?

必要があって使ってたRTOSを何らかの理由で使わなくて良くなった、という話は
誰がしてるの？

馬鹿共を晒し上げw

自分で自分を晒し上げるバカは珍しいw

これから個人の趣味としてRTOSを勉強するなら何がお勧め?
有償でもいいけど何十万円とかは無理。

>>138
この本いいよ。
http://www.amazon.com/dp/0879304448/

>139
ありがとう。良い本だと思う。ただいきなりRTOS自体の設計と実装から
始めたいのではなくて、まずは既存RTOSのユーザから始めたいので。

>>140
ブラックボックス相手に悩むより、中身がどう実装されているか知っていると、対処しやすい。

RTOSってピンキリだから対象の環境ややりたい事、自分の持ってる開発環境でも選択肢変わって来るしまずはそこ晒したら？漠然と言ってるなら>>139みたいな話になるよ。

ただ簡単に動かしてみたいというなら中身ちゃんと読んだこと無いけどFreeRTOSはコード少なくてビルドしやすかった。一応本もある。

なるほど。漠然としか考えてなかった。特に明確な用途も無いので、使い方よりも
先にRTOS自体の仕組を学ぶのも面白そうに思えてきた。皆さん親切にありがとう。

CQ出版の桑野さんが書いたヤツが良かった
RTOSの使い方じゃなくて、作り方だけど

昔はナビにrtos必要と言われてたけど
アンドロイドでも十分だったね
しかも大量生産で安く成ってるし

rtosとはなんだったのか

馬鹿には分からんかもね

そうやってけむにまく所がrtosのよくないところ
情報弱者にも分かりやすく説明出来ない様な技術じゃ実用性低くて採用されないよ

rtos載せれば消費者が飛びついて勝っていく訳でもないんだし
売りには成らん
非rtosのほうが充実してる事ばかりだ

何年という期間をノートラブルで動作し続ける組み込み機器の開発に情弱は不要。
JavaかPHPでもやってろ。

>>147
はぁ？RTOSとラウンドロビンの選定基準がお前みたいな情弱に説明できるか否かて、馬鹿か？wwww
ラウンドロビンでいい用途はラウンドロビンを使うし、ターンアラウンド規定がシビアな制御用途にはRTOSを使う
RTOS営利目的で販売してるところもこれを情報端末に使ってほしいなんて思ってない。
それがわからないやつはこのスレから立ち去れ

>>145
エンジン制御にラウンドロビン使ってみろ馬鹿

イメージしてるのがRPiみたいなちょっと趣味でいじるマイコンボードレベルまでなんだろうね

RTOS以外はラウンドロビン、ていう意味不明の信仰を広めてるのはTRON方面だっけ？

RTOSとラウンドロビン程度のテクニカルタームすら理解できないアホはすっこんでな

RTOSとラウンドロビン程度のテクニカルタームしか理解できないアホ↑

今時の汎用OSはラウンドロビンじゃないし…
Linuxですら、わざわざRT-Linux持って来なくても、本家のconfigいぢるだけで
RTOSに出来てしまう時代に…
産総研のロボット制御なんかも、これでRTOSだね。

原発にrtosなんて使ってるから４０年前の前世紀の遺物が保守されてないし新基準にも適合出来ずに廃炉に成るんじゃ

ちゃんと保守されてるrtosは何年もパッチ当てずに動いてるなんて事は無いよ
そんなのrtosの技術者は何年も生活費得る手段が亡くなってしまう

リナックスのrtos機能はなんちゃってだろ
あんなので満足されても困る
ユニックス機能と同じくらい似て非なるものだよ
ちなみにリナックスはユニックスのライセンスは受けていないから

> リナックスのrtos機能はなんちゃってだろ
> あんなので満足されても困る

別に困らんだろう。
世の中その程度の機能・性能で済むアプリケーションがほとんどだ。
Linux を動かすリソースさえ確保できれば。
お前のレベルが低いだけと言いたいだろうが、誰もがミッションクリティカルな
システムを手掛けているわけではない。そんなのはごく一部。

そもそも精密にrtosが必要な用途って何？

>>157
>世の中その程度の機能・性能で済むアプリケーションがほとんどだ。

勝手に決めんなアホ

> ちゃんと保守されてるrtosは何年もパッチ当てずに動いてるなんて事は無いよ

海外の原発だかで、RSX-11で動いてるとかいうのがあるんじゃなかったっけ？

>>156
ワインバーグの工学の第一法則を思い出した。
「壊れてないものを治すな」
問題を起こしていないシステムを改良すると故障する

ワインバーグのテスト
「あなたはそのシステムに、自分の命をあずけられますか」

閉鎖系では、正しい。

少なくともLinuxなんか使ったら（ていうかUnixぐらい複雑なら他の奴でもみんなそうだけど）、
新しい脆弱性が見つかった、という外的要因で「何もしなくても、壊れる」から。

海外の原発で、PDP-11に由緒正しきUNIXで稼働中のものが有って、しかも
あと30年稼働させることが決定された、ってニュースなら見たな。
2038年問題どうすんだろ?

まだ２０００年問題も修正されてナイシステムが最重要施設で使われてたりするのか怖いな

閉鎖系では表面化しないだけでバグや脆弱性は修正されてない事がほとんど
ms-dosのパッチなんて無いだろ

PC DOS 2000 日本語版
http://www.amazon.co.jp/dp/B00008HYVG
> 製品概要・仕様
> PC-DOS J7.0/Vの西暦2000年対応版

>>145
単純に、メモリあんまし載せられなかったからじゃね？
Androidはかなりリソース使うから、メモリが爆安の最近じゃないと�_

>>158
ロケットや飛行機の制御系とか。

ボーイングは普通にウィンドウズだった気が
ロケットのosは流石に見た事無いや

VxWorks

常用する様なosじゃないからリアルタイムの精度が不明だな

リアルタイムos載せとけば国産ロケットもちゃんと打ち上げられたのにな

TOPPERS/HRP使ってますけど

じゃあなんで時間がずれて打ち上げ中止に成ったの？
リアルタイムだから制御コンピュータとロケットは同期してるよね

リアルタイムOSというものを全く知りません、と言っているに等しい発言、ありがとうございます。

RTCOSという新しいジャンルのOSが生まれた瞬間であった

QNXはBlackBerry Tablet OSに進化したの？
それともQNXは終わったのだろうか

打ち上げシステムとロケットの両方にリアルタイムosが乗ってれば時間は完全同期してるよ
まあrtcから読み出してるから当たり前なんだけどね

公務員が作ったリアルタイムosは精度が悪くて遅刻したりするんだろうな
民間で作った有料リアルタムosなら問題ない（きりっ

>>176
QNXは車載で大人気だぞ？

>>177
>まあrtcから読み出してるから当たり前なんだけどね

別のXTALで動作してるRTCが同期なんてする訳ないじゃん

リアルタイムOSは通信のタイムラグを無視できる魔法だと思ってるのかw

むしろ非RTOSの方がタイムラグを無視してくれるよな。
検出できないという意味でw

だからシステムエラーで止まってしまうポンコツシステム
所詮学者が作った玩具だよ


カーナビに命運を託したルネサスは終わろうとしている

イプシロン きょう午後打ち上げへ
http://www3.nhk.or.jp/news/html/20130914/t10014533631000.html

またリアルタイムなのに時刻が合わないんだろうなｗｗｗ

ちゃんと飛び立ったな。良かった良かった。

>>182
TRON, TOPPERSのことかっーーー!?

ｼｽﾃﾑｴﾗｰから割り込んで
最大限のﾒﾓﾘ内容を残す非常用立ち上げ処理後、
ﾀﾞﾝﾌﾟ吐く処理にしてた。

高信頼性リアルタイムOS TOPPERS/HRPカーネルとSafetyカーネル
この国産RTOSは、H-IIAロケットやH-IIBロケットの搭載コンピュータに採用されました
（2012年7月21日初フライト）宇宙航空研究開発機構（JAXA）
TOPPERS/HRPカーネルは、μITRON4.0のスタンダードプロファイルに、メモリプロテクション、
ミューテックス、アラームハンドラ、オーバランハンドラを追加し、信頼性機能を強化しています
TOPPERS/HRPカーネルには、JAXAと名古屋大学の共同研究の成果物を利用しています
TOPPERS/HRPカーネルとSafetyカーネルには、TOPPERSプロジェクトの成果物を利用しています

>>188
μITronに標準でmutexなかったっけ？
仕事でやっていた実装系はあったけどなぁ

http://ja.wikipedia.org/wiki/%E3%83%9F%E3%83%A5%E3%83%BC%E3%83%86%E3%83%83%E3%82%AF%E3%82%B9
> μITRON仕様
> 3.0仕様以前には、ミューテックスは存在しない。広義のミューテックスはセマフォで代用することは
> 可能であるが、優先度逆転を防げない。 しかしながら、3.0仕様準拠OSでも、実装独自に優先度
> 逆転を防止できるミューテックスが存在する可能性はある。
> 4.0仕様以降では、優先度上限および優先度継承をサポートするミューテックスオブジェクトが追加
> された。しかし、スタンダードプロファイルには含まれておらず、実質オプション扱いである。

何か実用性低い実装だな
国産ロケット打ち上げがたまたまうまく逝く程度な訳だ

>>191
>>187-190の書き込みもう10回位読み直したら？
その程度の日本語力の奴が人のやってる事批判するのは10年早いぞ。

>>192
日本語が母国語ではないのでしょう。

一方、ロシアはアナログ計算機を使った

>>194
ロシアはMSXじゃなかったけ。

nasaはシンクパッドとか使ってるよね
こないだステーションで見かけた

俺もそれチェックしたw 着眼点がそれか…

.

FreeRTOSはITRON準拠ですか?

>>199
全く準拠してない。

FreeRTOS用のCMSIS-OSラッパーならあるみたいだ
CMSIS-OSが今後の標準になるのかは別として

>>201
CMSISってARMのだよね。
それにラッパーってどいうこと?

>>202
CMSIS-OSはOS実装そのものではなくARM社が提唱するAPI仕様。俺の知ってるのでは、KEIL RTXをラップしたものとFreeRTOSをラップしたものが有る。基本的にはCortex-Mターゲットを前提としてるみたい。

>>203
つまり、
・CMSIS → 各チップ間の差異を吸収
・CMSIS-OS → 各OSの差異を吸収
ということか。

そこまで頑張っちゃうんだ

>>204
まさしくそんな所。
あとKEIL uVision5触っててきづいたのは、GPIOとかRCCとかのペリフェラル用APIもこれまでCPUベンダー毎に各社各様だったのが統一されてる。

これはOSではなくCMSISの側の領域なのかな。ここら辺もARM CPU全体で互換性が改善されてるみたいだ。

KEILはARMと提携してる(経営が同じ？)のかして、uVision5が互換性向上の実験場になってる気はするけど。

俺のこの認識って正しい?

Toppers … カーネル?がゴチャゴチャ沢山あって、なにが違うのかよ〜わからん。カーネルだけあってもだし、これなら T-Karnelが良い。
uT-Kernel … コンパクトな上、USBとかTCP/IPとか揃っている雰囲気。
FreeRTOS … カーネルだけで、それ以外は全部集めてこないとダメ。