【Toppers】組込みOSのスレがないじゃないか【freeRTOS】

**774ワット発電中さん** · 2019/08/29(木) 19:37:37.17

お前らみんなベアメタルなの？

freeRTOSがフリーなRTOSの一般名詞だと思ってたんだが、アマゾンの組込みOSだと知って衝撃を受けた。
つか、10年くらい前からやってるtoppersなんか遥か彼方に追い越した感があるけど、どうなってんだろうな。

今日、試しにcubeIDEでSWを押すとLEDの点滅間隔が変わるだけのソフトをfreeRTOSを使って動くのを作ってみたんだが
結構簡単だな。

**774ワット発電中さん** · 2021/09/04(土) 08:51:26.09

FreeRTOS使って見ても、ラズパイLINUXと比べて優位点があるのか
いまひとつ確証が得られない。

**774ワット発電中さん** · 2021/09/04(土) 11:22:12.47

ラズパイ & Linuxを使えるアプリで、FreeRTOSを使うものと比較する意味がどれぐらいあるんだろう。

**774ワット発電中さん** · 2021/09/04(土) 12:15:41.71

Unix環境を余計とするか優位とするかでちがってくる
RTカーネルにしたら性能差はあるけど実際には困らないとは思う

**774ワット発電中さん** · 2021/09/04(土) 12:31:53.83

優位点がわからないような人は使う必要無いのでは？

**774ワット発電中さん** · 2021/09/04(土) 16:16:39.49

その通りだな、議論のレベルが違う
原付と乗用車比べるようなものだ

**774ワット発電中さん** · 2021/09/04(土) 22:21:46.77

FreeRTOSは有名だけど、それよりもAzure RTOSやNuttxがいいと思うんだよね！
カンだけど

**774ワット発電中さん** · 2021/09/05(日) 06:02:50.02

>>91
その通りで実際にはLINUX(ラズパイ)で困らないように思えてしまう。
RTOSの基礎的なタスク処理のしくみはともかく、FreeRTOSの売りはApplication
Protocolsで、HTTPSやMQTTまで無償だ。
メーカー製の有償RTOSですら暗号通信までサポートしているものはほとんどない。
けど現行のFreeRTOSは情報が少なく、自分が選んだMPUで自分が構築した
プロジェクトにHTTPSを組み込むのは一苦労で、その苦労が報われるかという話。
LINUXなら楽勝なのに。

**774ワット発電中さん** · 2021/09/05(日) 09:13:07.73

>>95
それならRTOSを選択するのが間違いでは？
RTOSはリアルタイム性確保が主目的で、通信系はそれを邪魔する

**774ワット発電中さん** · 2021/09/05(日) 09:55:33.73

>>95
ラズパイ & Linuxを使えるアプリで、ラズパイ & Linux で困らないのは当たり前。
それとも、ラズパイ & Linuxを使えるアプリで、それ以外を使うケースとの比較なんだろうか。

とはいえ、ラズパイ & Linux以外を使うことを求められるのは、
処理能力的にラズパイ & Linuxを使えるとしてもそのほかの条件で、
結果として、実はそれがラズパイ & Linuxを使えないアプリだからでは。

**774ワット発電中さん** · 2021/09/05(日) 10:01:01.09

禅問答かな？

**774ワット発電中さん** · 2021/09/05(日) 10:30:27.11

>>96
なんで？
ネット通信はDMA転送だから、通信タスクの優先順位は低くて何も問題ないよ。

**774ワット発電中さん** · 2021/09/05(日) 12:38:46.36

>>89
それ比べちゃうのかよｗ

**774ワット発電中さん** · 2021/09/05(日) 12:55:44.68

LinuxやWindowsはリアルタイム処理は出来ない

**774ワット発電中さん** · 2021/09/05(日) 12:59:17.11

小規模環境、省リソース、少コスト
リアルタイム処理
起動時間
信頼性

この辺が特徴
世の中の多くの製品で使われている

この辺が不要ならRTOSを考える必要はない

**774ワット発電中さん** · 2021/09/05(日) 13:31:35.87

>>95
通信が100ms遅れても良い
起動に1分かかっても良い
電力を1W使っても良い
信頼性はそれほど重要じゃない
簡単にTCP/IP通信したい

なら素直にWindowsやLinuxを使ってください

**774ワット発電中さん** · 2021/09/05(日) 14:08:54.13

>>99
なんで？
リアルタイム処理優先している間にバッファオーバーフローしても通信出来るとでも？

**774ワット発電中さん** · 2021/09/05(日) 14:18:52.07

>>103
まぁ、実際にはそんな大ナタにしなくてもWIZnet社のIC:W5500でも載せれば問題解決なんだけどね。

**774ワット発電中さん** · 2021/09/05(日) 14:19:33.95

少なくともTCP/IP 通信ならパケット損失しても大きな問題にはならない。

**774ワット発電中さん** · 2021/09/05(日) 14:32:55.01

100us以内に応答して結果を出力
こういうオーダーなのがリアルタイム処理

CPUを長時間(100msオーダー)占有するような処理は
(RTOS的には)リアルタイム処理ではない

優先度の高い処理でCPUが長時間占有するなら
それはCPUの選択や要件が間違ってる

**774ワット発電中さん** · 2021/09/05(日) 14:38:22.62

それぞれの処理を延々とやっているように見えて、占有させてないわけだし。

**774ワット発電中さん** · 2021/09/05(日) 16:58:42.67

Linux動かすならそこそこのターゲットかなとおもうけど
そこで応答性の保証が仮に数桁ちがったとして困らんという話
別に汎用PC上で稼働させるわけじゃなし

**774ワット発電中さん** · 2021/09/05(日) 17:31:20.56

お前が困るとか困らないとかどうでも良い

**774ワット発電中さん** · 2021/09/05(日) 18:42:27.48

まぁ　長い事、教科書はオブジェクト単位をタスクとして扱ってきたからな。　100msディスパッチが応答速度と勘違いするやからが一杯。
タスクはオブジェクトのイベントポーリングを包含するだけのものと変化してきた最近はまともなRTOS設計が増えてきた。
オブジェクトの中にタスクがある。
これも、クリーン・アーキテクチャー、SOLID原則が言われ始めたおかげなのかもしれない。

**774ワット発電中さん** · 2021/09/05(日) 20:18:21.73

なんか変なのが来た

**774ワット発電中さん** · 2021/09/06(月) 07:00:33.47

携帯端末の定義なんかも20世紀からさんざん変わっており、通信機能が必須に
なったのも最近のことだ。
AmazonはRTOSにに暗号通信機能が必須と言っている。

**774ワット発電中さん** · 2021/09/06(月) 19:26:50.55

そりゃAWS使わせるためにFreeRTOS買ったんだから
そう言うだろうよ

**774ワット発電中さん** · 2022/01/24(月) 20:54:45.81

まだあんまり調べられてないけど　FreeRTOS

RL78 FreeRTOSの利用手順（割り込み）
https://qiita.com/shirokumaneko/items/e4b05cd06a257ee85eed

上記の記事見ると、割込みからカーネルに戻らずにreti (RL78の割込みからのリターン命令）
で終わってる。　つまり　ITRONで言うところの「遅延ディスパッチ」ってやんないんやね。

その辺のところは、
Chapter 4 割り込み管理(Interrupt Management) (FreeRTOS チュートリアル日本語訳)
https://qiita.com/azuki_bar/items/7f31eb80e8b6b2eff17f
に書いてあるけど、次のtimetickまでタスクスイッチは待たされるみたい。

あと
遅延ディスパッチについては、以下のTRONのサイトで解説がある
https://www.tron.org/ja/page-722/rtos10/

**774ワット発電中さん** · 2022/01/24(月) 21:21:43.72

vPortYieldFromISR()

**774ワット発電中さん** · 2022/01/24(月) 21:57:28.50

>>116
vPortYieldFromISR()　でいくらカーネルオブジェクトを変更しても、
retiで元のタスクに一旦戻るから、次にカーネルに来るまでタスクは切り替わらない。

**115** · 2022/01/25(火) 07:28:30.97

今インターフェース2021年4月号みてるが、p49 図４解りやすく書いてるね。
設計思想として、どうなんだろうって思うね。
特に小さい遅いマイコンの場合はtime tickを長くして負荷を減らすようにするのが定石だけどね。
実際、5MHhzのマイコンの場合は
10msをtimetickにしてたし、
そうなるとタスク起動は、10ms待たされることになる。
それなら、割り込み使ってタスク起動なんて遅いだけだと思うね

**774ワット発電中さん** · 2022/01/25(火) 20:28:38.01

>>117
個人のブログじゃなくて公式の資料読んだ方がいい
YieldFromISRはコンテキストスイッチを起こす

**774ワット発電中さん** · 2022/01/26(水) 06:20:52.02

実際に動かしてみるまでわからん

**115** · 2022/01/26(水) 07:18:21.33

>>119
https://qiita.com/azuki_bar/items/7f31eb80e8b6b2eff17f
これ公式の翻訳だが
そう書いてるんだな

**115** · 2022/01/26(水) 07:25:02.79

http://w3c.digital-rc.sub.jp/?eid=47#gsc.tab=0
このサイトに実験結果が書かれている。タスクディスパッチはtime tickの1ms周期でしかしないという結論だよ

**115** · 2022/01/29(土) 12:41:35.94

全面的に俺の間違い、勘違いでした。すまなかった。
実際ソースを見た。　raspberry-piの個人が実装したソースなんだが
ちゃんとFreeRTOSが入っていて、その割り込みから戻るときに
ちゃんと、ullPortYieldRequiredを見て切り替えてる
Exit_IRQ_No_Context_Switch　に飛べばタスク切り替えずに割り込みされたもとに
もどり、分岐しなければスケジューラに行くという流れになってる。

https://github.com/eggman/FreeRTOS-raspi3/blob/master/FreeRTOS/Source/portable/GCC/ARM_CA53_64_RaspberryPi3/portASM.S
LINE;281
/* Is a context switch required? */
LDR X0, ullPortYieldRequiredConst
LDR X1, [X0]
CMP X1, #0
B.EQ Exit_IRQ_No_Context_Switch

単純に言い訳すれば、
qiitaのRL78のサイトの記載がよろしくないんだろうと思う。

実際ソース見て、どや顔するつもりが逆になったという話でした。

**774ワット発電中さん** · 2022/01/29(土) 19:16:28.45

だから個人ブログじゃなくて公式見ろと
自分で挙げた >121 を読んでも理解できないようでは仕方ないけど

**774ワット発電中さん** · 2022/01/30(日) 13:30:20.16

https://github.com/FreeRTOS/FreeRTOS-Kernel/blob/main/portable/GCC/ARM_CA53_64_BIT/portASM.S
LINE:343
/* Is a context switch required? */
LDR X0, ullPortYieldRequiredConst
LDR X1, [X0]
CMP X1, #0
B.EQ Exit_IRQ_No_Context_Switch

公式でも同じ。　個人がこんなカーネルのコアな部分さわるとかないからね。

**774ワット発電中さん** · 2023/10/17(火) 08:27:43.23

バカなっ・・・あいつ赤信号なのに・・・・・轢かれたぞっ！！

**774ワット発電中さん** · 2024/02/07(水) 14:14:55.34

RTOSについて検索しても「FreeRTOSでTCP/IP」みたいな記事ばかり出てくる
・RTOSっていっぱいあるけど何がどう違うの？
・○○みたいなのを作りたいのだけどどのRTOSが適しているの？
みたいな疑問は全く解消されない

**774ワット発電中さん** · 2024/02/07(水) 18:09:17.96

RTOSはDOSやUnix系OSに慣れた人には最初取っ付き難い
昔ベアメタル環境のプログラミングしてたら感覚的に理解出来るだろうが

**774ワット発電中さん** · 2024/02/07(水) 18:22:11.61

RTOS本来の恩恵で考えれば、どれ使っても同じだとおもう。
ペリフェラルをコントロールするライブラリが充実してるとか簡単に見つかるとか、書籍やWEBが多くて調べやすいとか
重要なのはそのあたり。そういう差じゃないだろうか？
ディスパッチさえ書ければだいたいの制御は事足りると個人的に思う

**127** · 2024/02/07(水) 23:28:29.80

レスサンクス。どちらかと言えばベアメタルでゴリゴリ書く方だけどRTOSの説明を読んでもピンとこない

・よくある解説だとタスクA/タスクB/タスクCみたいな例が示されるけど3個くらいならハードウェア割り込みベースのタスク管理と大差あるとは思えない
　もっと大規模なシステムなら恩恵があるのかもしれないがそのような解説は見つからない
・リアルタイム制御と説明されるがどのくらい時間精度を実現できるのかという情報はあまり見かけない
　極端だがソフトウェアUART(usオーダー)やソフトウェアUSB(nsオーダー)といったタスクをマルチタスク動作させられるのか？
　あとデバイスドライバは高速応答が発生しがち
・RTOSを利用したシステムを実装するうえでRTOS下にない処理(便宜上タスクと呼ぶ)の取り扱い
　すべてのタスクをRTOS下に置けないというケースは現実的にあると思われる。例えば割り込み後最速でDMAを起動する必要があるなど
　最近のマイコンはCPUを介さずにあれこれ出来たりするけどそのような機能の扱い方。またそのような動作は大なり小なりRTOSの動作を乱す
・移植性が高いと説明されることがあるが各RTOSでどう違うのか
　一部のCPUがもつ高速にコンテキストスイッチを実行する機能を利用できるような改造をしやすいかなど

**774ワット発電中さん** · 2024/02/08(木) 01:15:00.18

余談かもしれないが
リアルタイムOSのリアルタイムの定義はその仕様書のオーダーによるんだ。
仕様書に一分以内に完了することと書かれていたらほぼどんな書き方でもマイコンでもリアルタイム制御を実現できるし、その条件を満たせばリアルタイム。
逆にレーザー距離計を作るとして光の波長を捉えようとしてもリアルタイムで光波をカウントできるマイコンやFPGA、OSはこの世に無い。
車のブレーキであればmsecで制御を返せばよくて、人間の反射はもっと遅いからリアルタイム制御と言える。
どんな案件でどこまでをリアルタイムと定義するかによる。

タスクはいいよ
仮にLED100個の点滅をmsec単位でユーザーが起動後それぞれ自由に変更できるシステムを構築するとしたらどう？
マルチタスク無いと相当大変な工夫が必要じゃない？
たとえタスクなしでそのシステムが完成しても、顧客から仕様変更でUARTをはさみたいと言ってきたらイチから見直さないといけなくなる地獄

タスクいらないという人もいるのも事実なのでこれ以上は言わないけど。

**774ワット発電中さん** · 2024/02/08(木) 01:56:50.89

DMAはCPUから独立して働くとおもうので、CPU上のRTOSを乱すとしても影響は小さい？、詳しい人が以下にあほバカ言いながらレスするだろう。
注意しないといけないのがDMA先のメモリ参照とCPUの参照先がデッドロックを起こすかもしれないのでミューテックス・セマフォを使わないとだめだと思う。

移植性はなんとも

**127** · 2024/02/10(土) 13:17:27.45

>LED100個の点滅をmsec単位でユーザーが起動後それぞれ自由に変更できるシステムを構築するとしたらどう？
100個のLEDを完全独立制御するのは特殊ケースだろう。一般的にはダイナミック駆動で点灯することになると思われる
となると割り込みによる入力＆処理タスクとタイマ＆DMAによる波形生成タスクの2分割かな
後者はCPUに依存しないからCPUの仕事は前者のみ。これにUARTによる通信機能を追加しても割り込みで十分対応できるはず

というかもっと実践的な例示をしてほしい
例えばハイエンドマイコンに液晶パネル、オーディオアンプ、スピーカー、SDRAM、フラッシュメモリを外付けして動画を再生すると仮定する
外付けのフラッシュメモリやSDRAMは遅いからメモリは2～3層の階層構造をもち、必要に応じて先読みやバッファする
ソフトウェアが行うべき主な仕事は
・フラッシュメモリ読み出し
・読み出しバッファ制御
・ファイルシステム制御
・スプリッタ
・ビデオデコード
・オーディオデコード
・ビデオレンダリング
・オーディオレンダリング
・ビデオ/オーディオ同期制御
・フレームバッファ制御
・オーディオバッファ制御
・液晶パネル制御
・オーディオ出力
・UI入力
あたりかな？リアルタイム制御はmsオーダーだしRTOSを応用するシステムとしては緩めか
でこれらの仕事をどのようにタスクに分割してどのようなタスクの実行条件を設定し効率的に動作させるか？って問題
ITRON系の本を読んでもこのような実践的な解説は出てこないし、FreeRTOSの解説サイトを見ても同様

**774ワット発電中さん** · 2024/02/19(月) 22:53:04.46

百個なんて13バイト書き込むだけじゃん

**774ワット発電中さん** · 2024/03/04(月) 19:38:06.57

RTOSちょー便利ー
予想してたけどめちゃコーディング楽ちんでちょっとだけ感動した。

**774ワット発電中さん** · 2024/04/04(木) 16:33:00.41

最悪応答時間がOS+MCUの組ごとに規定されてほしい。が、実際はそうなっていない。

STM32F0xx+FreeRTOSの場合、最悪応答時間をクロックやタスク数等の関数として知りたい。

「応答時間が保証できないRTOSは無価値」というベアメタル原理主義の人に反論するにはその武器が必要なのです。

**774ワット発電中さん** · 2024/04/04(木) 21:25:08.14

>>136
サービスコールによってクリティカルセクションの長さが違うから、それを求めるのは難しいんでしょうね。
正しくRTOSを使うシステムを作って実測し、その実測値に遅くなりうる要因・時間を上乗せするのが現実的ではないでしょうか。
非最高優先度のタスクは悩ましいけれど、RTOSが持つ機能でどうにかできるはずです。

マイコンとRTOSの性能よりも、それらを正しく使うことの方が重要だと思います。
使うのはヒトですから、以下のような間違いや経験不足はついて回ります。
　優先度を間違えた、ミューテックスを使うべきところにバイナリセマフォを使った、
　同期IOした、割り込みハンドラの処理が長い、安易に排他している、DMACがあるのに使っていない

**774ワット発電中さん** · 2024/04/23(火) 22:17:21.98

rtos思ったより難しいなぁ
擬似マルチタスクなんだね.

**774ワット発電中さん** · 2024/04/26(金) 23:17:40.97

https://i.imgur.com/6JhZq2f.jpg