0001774ワット発電中さん2019/08/29(木) 19:37:37.17ID:1mQYwlMH
お前らみんなベアメタルなの?
freeRTOSがフリーなRTOSの一般名詞だと思ってたんだが、アマゾンの組込みOSだと知って衝撃を受けた。
つか、10年くらい前からやってるtoppersなんか遥か彼方に追い越した感があるけど、どうなってんだろうな。
今日、試しにcubeIDEでSWを押すとLEDの点滅間隔が変わるだけのソフトをfreeRTOSを使って動くのを作ってみたんだが
結構簡単だな。
FreeRTOS使って見ても、ラズパイLINUXと比べて優位点があるのか
いまひとつ確証が得られない。
ラズパイ & Linuxを使えるアプリで、FreeRTOSを使うものと比較する意味がどれぐらいあるんだろう。
Unix環境を余計とするか優位とするかでちがってくる
RTカーネルにしたら性能差はあるけど実際には困らないとは思う
その通りだな、議論のレベルが違う
原付と乗用車比べるようなものだ
FreeRTOSは有名だけど、それよりもAzure RTOSやNuttxがいいと思うんだよね!
カンだけど
0095774ワット発電中さん2021/09/05(日) 06:02:50.02ID:cNkVgkSW
>>91
その通りで実際にはLINUX(ラズパイ)で困らないように思えてしまう。
RTOSの基礎的なタスク処理のしくみはともかく、FreeRTOSの売りはApplication
Protocolsで、HTTPSやMQTTまで無償だ。
メーカー製の有償RTOSですら暗号通信までサポートしているものはほとんどない。
けど現行のFreeRTOSは情報が少なく、自分が選んだMPUで自分が構築した
プロジェクトにHTTPSを組み込むのは一苦労で、その苦労が報われるかという話。
LINUXなら楽勝なのに。 >>95
それならRTOSを選択するのが間違いでは?
RTOSはリアルタイム性確保が主目的で、通信系はそれを邪魔する >>95
ラズパイ & Linuxを使えるアプリで、ラズパイ & Linux で困らないのは当たり前。
それとも、ラズパイ & Linuxを使えるアプリで、それ以外を使うケースとの比較なんだろうか。
とはいえ、ラズパイ & Linux以外を使うことを求められるのは、
処理能力的にラズパイ & Linuxを使えるとしてもそのほかの条件で、
結果として、実はそれがラズパイ & Linuxを使えないアプリだからでは。 0099774ワット発電中さん2021/09/05(日) 10:30:27.11ID:cNkVgkSW
>>96
なんで?
ネット通信はDMA転送だから、通信タスクの優先順位は低くて何も問題ないよ。 LinuxやWindowsはリアルタイム処理は出来ない
小規模環境、省リソース、少コスト
リアルタイム処理
起動時間
信頼性
この辺が特徴
世の中の多くの製品で使われている
この辺が不要ならRTOSを考える必要はない
>>95
通信が100ms遅れても良い
起動に1分かかっても良い
電力を1W使っても良い
信頼性はそれほど重要じゃない
簡単にTCP/IP通信したい
なら素直にWindowsやLinuxを使ってください >>99
なんで?
リアルタイム処理優先している間にバッファオーバーフローしても通信出来るとでも? >>103
まぁ、実際にはそんな大ナタにしなくてもWIZnet社のIC:W5500でも載せれば問題解決なんだけどね。 少なくともTCP/IP 通信ならパケット損失しても大きな問題にはならない。
100us以内に応答して結果を出力
こういうオーダーなのがリアルタイム処理
CPUを長時間(100msオーダー)占有するような処理は
(RTOS的には)リアルタイム処理ではない
優先度の高い処理でCPUが長時間占有するなら
それはCPUの選択や要件が間違ってる
それぞれの処理を延々とやっているように見えて、占有させてないわけだし。
Linux動かすならそこそこのターゲットかなとおもうけど
そこで応答性の保証が仮に数桁ちがったとして困らんという話
別に汎用PC上で稼働させるわけじゃなし
まぁ 長い事、教科書はオブジェクト単位をタスクとして扱ってきたからな。 100msディスパッチが応答速度と勘違いするやからが一杯。
タスクはオブジェクトのイベントポーリングを包含するだけのものと変化してきた最近はまともなRTOS設計が増えてきた。
オブジェクトの中にタスクがある。
これも、クリーン・アーキテクチャー、SOLID原則が言われ始めたおかげなのかもしれない。
0113774ワット発電中さん2021/09/06(月) 07:00:33.47ID:4EEN8Gxv
携帯端末の定義なんかも20世紀からさんざん変わっており、通信機能が必須に
なったのも最近のことだ。
AmazonはRTOSにに暗号通信機能が必須と言っている。
そりゃAWS使わせるためにFreeRTOS買ったんだから
そう言うだろうよ
>>116
vPortYieldFromISR() でいくらカーネルオブジェクトを変更しても、
retiで元のタスクに一旦戻るから、次にカーネルに来るまでタスクは切り替わらない。 今インターフェース2021年4月号みてるが、p49 図4解りやすく書いてるね。
設計思想として、どうなんだろうって思うね。
特に小さい遅いマイコンの場合はtime tickを長くして負荷を減らすようにするのが定石だけどね。
実際、5MHhzのマイコンの場合は
10msをtimetickにしてたし、
そうなるとタスク起動は、10ms待たされることになる。
それなら、割り込み使ってタスク起動なんて遅いだけだと思うね
>>117
個人のブログじゃなくて公式の資料読んだ方がいい
YieldFromISRはコンテキストスイッチを起こす だから個人ブログじゃなくて公式見ろと
自分で挙げた >121 を読んでも理解できないようでは仕方ないけど
バカなっ・・・あいつ赤信号なのに・・・・・轢かれたぞっ!!
0127774ワット発電中さん2024/02/07(水) 14:14:55.34ID:XDEE0bP5
RTOSについて検索しても「FreeRTOSでTCP/IP」みたいな記事ばかり出てくる
・RTOSっていっぱいあるけど何がどう違うの?
・○○みたいなのを作りたいのだけどどのRTOSが適しているの?
みたいな疑問は全く解消されない
RTOSはDOSやUnix系OSに慣れた人には最初取っ付き難い
昔ベアメタル環境のプログラミングしてたら感覚的に理解出来るだろうが
0129774ワット発電中さん2024/02/07(水) 18:22:11.61ID:BM1DrTGR
RTOS本来の恩恵で考えれば、どれ使っても同じだとおもう。
ペリフェラルをコントロールするライブラリが充実してるとか簡単に見つかるとか、書籍やWEBが多くて調べやすいとか
重要なのはそのあたり。そういう差じゃないだろうか?
ディスパッチさえ書ければだいたいの制御は事足りると個人的に思う
レスサンクス。どちらかと言えばベアメタルでゴリゴリ書く方だけどRTOSの説明を読んでもピンとこない
・よくある解説だとタスクA/タスクB/タスクCみたいな例が示されるけど3個くらいならハードウェア割り込みベースのタスク管理と大差あるとは思えない
もっと大規模なシステムなら恩恵があるのかもしれないがそのような解説は見つからない
・リアルタイム制御と説明されるがどのくらい時間精度を実現できるのかという情報はあまり見かけない
極端だがソフトウェアUART(usオーダー)やソフトウェアUSB(nsオーダー)といったタスクをマルチタスク動作させられるのか?
あとデバイスドライバは高速応答が発生しがち
・RTOSを利用したシステムを実装するうえでRTOS下にない処理(便宜上タスクと呼ぶ)の取り扱い
すべてのタスクをRTOS下に置けないというケースは現実的にあると思われる。例えば割り込み後最速でDMAを起動する必要があるなど
最近のマイコンはCPUを介さずにあれこれ出来たりするけどそのような機能の扱い方。またそのような動作は大なり小なりRTOSの動作を乱す
・移植性が高いと説明されることがあるが各RTOSでどう違うのか
一部のCPUがもつ高速にコンテキストスイッチを実行する機能を利用できるような改造をしやすいかなど
0131774ワット発電中さん2024/02/08(木) 01:15:00.18ID:nF+IFror
余談かもしれないが
リアルタイムOSのリアルタイムの定義はその仕様書のオーダーによるんだ。
仕様書に一分以内に完了することと書かれていたらほぼどんな書き方でもマイコンでもリアルタイム制御を実現できるし、その条件を満たせばリアルタイム。
逆にレーザー距離計を作るとして光の波長を捉えようとしてもリアルタイムで光波をカウントできるマイコンやFPGA、OSはこの世に無い。
車のブレーキであればmsecで制御を返せばよくて、人間の反射はもっと遅いからリアルタイム制御と言える。
どんな案件でどこまでをリアルタイムと定義するかによる。
タスクはいいよ
仮にLED100個の点滅をmsec単位でユーザーが起動後それぞれ自由に変更できるシステムを構築するとしたらどう?
マルチタスク無いと相当大変な工夫が必要じゃない?
たとえタスクなしでそのシステムが完成しても、顧客から仕様変更でUARTをはさみたいと言ってきたらイチから見直さないといけなくなる地獄
タスクいらないという人もいるのも事実なのでこれ以上は言わないけど。
0132774ワット発電中さん2024/02/08(木) 01:56:50.89ID:nF+IFror
DMAはCPUから独立して働くとおもうので、CPU上のRTOSを乱すとしても影響は小さい?、詳しい人が以下にあほバカ言いながらレスするだろう。
注意しないといけないのがDMA先のメモリ参照とCPUの参照先がデッドロックを起こすかもしれないのでミューテックス・セマフォを使わないとだめだと思う。
移植性はなんとも
>LED100個の点滅をmsec単位でユーザーが起動後それぞれ自由に変更できるシステムを構築するとしたらどう?
100個のLEDを完全独立制御するのは特殊ケースだろう。一般的にはダイナミック駆動で点灯することになると思われる
となると割り込みによる入力&処理タスクとタイマ&DMAによる波形生成タスクの2分割かな
後者はCPUに依存しないからCPUの仕事は前者のみ。これにUARTによる通信機能を追加しても割り込みで十分対応できるはず
というかもっと実践的な例示をしてほしい
例えばハイエンドマイコンに液晶パネル、オーディオアンプ、スピーカー、SDRAM、フラッシュメモリを外付けして動画を再生すると仮定する
外付けのフラッシュメモリやSDRAMは遅いからメモリは2〜3層の階層構造をもち、必要に応じて先読みやバッファする
ソフトウェアが行うべき主な仕事は
・フラッシュメモリ読み出し
・読み出しバッファ制御
・ファイルシステム制御
・スプリッタ
・ビデオデコード
・オーディオデコード
・ビデオレンダリング
・オーディオレンダリング
・ビデオ/オーディオ同期制御
・フレームバッファ制御
・オーディオバッファ制御
・液晶パネル制御
・オーディオ出力
・UI入力
あたりかな?リアルタイム制御はmsオーダーだしRTOSを応用するシステムとしては緩めか
でこれらの仕事をどのようにタスクに分割してどのようなタスクの実行条件を設定し効率的に動作させるか?って問題
ITRON系の本を読んでもこのような実践的な解説は出てこないし、FreeRTOSの解説サイトを見ても同様
0135774ワット発電中さん2024/03/04(月) 19:38:06.57ID:mCOdB31W
RTOSちょー便利ー
予想してたけどめちゃコーディング楽ちんでちょっとだけ感動した。
最悪応答時間がOS+MCUの組ごとに規定されてほしい。 が、実際はそうなっていない。
STM32F0xx+FreeRTOSの場合、最悪応答時間をクロックやタスク数等の関数として知りたい。
「応答時間が保証できないRTOSは無価値」というベアメタル原理主義の人に反論するにはその武器が必要なのです。
0137774ワット発電中さん2024/04/04(木) 21:25:08.14ID:MbGNbO7u
>>136
サービスコールによってクリティカルセクションの長さが違うから、それを求めるのは難しいんでしょうね。
正しくRTOSを使うシステムを作って実測し、その実測値に遅くなりうる要因・時間を上乗せするのが現実的ではないでしょうか。
非最高優先度のタスクは悩ましいけれど、RTOSが持つ機能でどうにかできるはずです。
マイコンとRTOSの性能よりも、それらを正しく使うことの方が重要だと思います。
使うのはヒトですから、以下のような間違いや経験不足はついて回ります。
優先度を間違えた、ミューテックスを使うべきところにバイナリセマフォを使った、
同期IOした、割り込みハンドラの処理が長い、安易に排他している、DMACがあるのに使っていない 0138774ワット発電中さん2024/04/23(火) 22:17:21.98ID:LngQU12C
rtos思ったより難しいなぁ
擬似マルチタスクなんだね.