【Toppers】組込みOSのスレがないじゃないか【freeRTOS】
お前らみんなベアメタルなの?
freeRTOSがフリーなRTOSの一般名詞だと思ってたんだが、アマゾンの組込みOSだと知って衝撃を受けた。
つか、10年くらい前からやってるtoppersなんか遥か彼方に追い越した感があるけど、どうなってんだろうな。
今日、試しにcubeIDEでSWを押すとLEDの点滅間隔が変わるだけのソフトをfreeRTOSを使って動くのを作ってみたんだが
結構簡単だな。 ルネサスが推してるthreadXとかマイナーなん? STMcubeMX使うとマウスをクリックするだけでfreeRTOSが使えるようになる
ちゃんと動かせるようにするには試行錯誤が必要だけど CubeMX_with_FreeRTOS_training_JPN_rev1.pdf
にきっちりFreeRTOSの動かし方が書いてる。試行錯誤なんか必要なし >>25
Lチカさせるだけのチュートリアルじゃん
まさかhello world出力したら天下取った気になっちゃう人? >>29
お前馬鹿じゃないのか?
つまり、CubeMXを使って、FreeRTOSを動かすための設定以外に何を期待してるんだアホ
RTOSのイロハやFreeRTOSそのものがSTMのマニュアルにでも書かれてると思ってんのか馬鹿たれ >>34
CubeMX_with_FreeRTOS_training_JPN_rev1.pdf
を読んでもFreeRTOSの設定もできない馬鹿は死ね無能
ほんとアホの極みだなwwww >>29
>Lチカさせるだけのチュートリアルじゃん
RTOSってのは
タスク優先順位をもとにしたタスクディスパッチ、
排他制御さえ実装できれば
ほぼ目的を達成してること自体理解してない知障
アホは死ねwwww 実際やってみると、教科書通りには行かない
エアプにはそれが分からない はぁ?
CubMXを使ったコードをFreeRTOSをコンパイルするまでの手順を書いた教科書なのに
動かせないのは馬鹿か知障だ。
お前みたいなアホでもないかぎり確実に動かせる。
馬鹿は死ねwww OSを使いこなす人達のスレは内容が高度すぎてついていけないわ RTOSの開発環境を整えるのに、どこみてもCmakeがどーとか、Ninjaどーとかさっぱりです
Mplabみたいにマイコンメーカーが提供する開発環境しか使ったことが無いんでもうなにがなんだか
今一時的にアマゾンのチュートリアル通りに開発環境が構築できても今後は周辺の状況が
変わるとまたできなくなりそうで怖いです
「開発環境を作るスキル」ってどうやって身につけたらいいんでしょうか? 素直にマイコンメーカーが提供する開発環境を使えば良い >>43
AWSにデータを挙げるのに、FreeRTOS使いたいっていう前提を書いてませんでした
こういうのサラサラっと開発環境作れる人ってどういう勉強してきたんだろう・・・、どういう勉強続けているんだろう >>45
基本はやっぱmakeの勉強からですか
ありがとうございます >>46
makeマクロが読めるに越したことはないけど、読めても開発環境を作るのには
あまり役に立たないかな
CmakeもNinjaもmakeと同じようなビルド用マクロツールで、それぞれ独自の
構文で記述されたマクロにしたがって目的のオブジェクトを作るツールという
だけなので、どのツールを使うか決めてツールの使い方を覚えるしかないので
GUIで提供されるIDEみたいな統合ツールとか、メーカーが提供する解凍一発で
使用可能なツールセットが用意されていない場合には、解説サイトに載っている
ツール一つ一つをトライ&エラーで勉強していくしかないと思うけど
そしてサラサラっと環境を作っている人の大半は、チュートリアル通りにやって
できたーってやっているので、環境が変わったりトラブルが起こると感嘆には
対応できないのが普通なんじゃないかな
昨今の開発環境は、意識高い系の人が作った僕の考えた最強ツールを
次々と入れ替えるのがトレンドなので、あまり個々のツールにこだわっても
すぐに別のものに置き換わってしまうから、手順どおりに組み上げて自分に
必要な部分の知識を拡充するみたいにしないと付いていけないと思う >>47
ありがとうございます
現状、AWSのesp32用のチュートリアル通りにやっても全然できない状況で
遠回りが近道と考えチュートリアルにでてくるCMake、Ninja、MSYS、 これらを
1から勉強して、その後もう一度トライしようと思っていましたが、考え直します。
Windowsでのビルド環境の構築は行き詰ったので、Linux環境でビルドしている人の
真似を真似を一通りやってみてできればそれでよしということにします。
できなかったらできなかったとき、テクニカルサポートにお金を出すか検討して
みます。
はぁ、しかしツールの使い方覚えるだけで時間が過ぎ去って覚えた頃には次の
ツールが出来上がってそう・・・新陳代謝が早すぎてついていけない >>50
まじかよ・・・・・
ここは勇気ある撤退だな
仮に環境作れたところで、その先も超難関だ
サポートに金を払ったところで解決するとは思えない
流しのエンジニアの俺が面倒見てやってもいいが、ちと高くつくぜ >>51
そうですか・・・どういったところで壁にぶつかるんですか? >>52
デモのアプリが動いたから次は自作のアプリを動かしてみようとすると、そこからが難しい >>53
主にAWS間ですか?
S3にデータ投げたり、MQTTで通信したりとか。
それともLチカレベルが難しいですか? >>55
あっアメリカの団体だった
まっ、イっか? Interface誌4月号でFreeRTOSが特集されて、記事で紹介されてたSTMicroの
ボードを買って試してみた。
GUIでタスクなど設定できるので、そこは便利で簡単に使えるが、看板のネット機能
を実装するのは容易でないことが判った。 対話処理も無いGUIも無い組み込みOSは何に使ったらよいかイメージが掴みづらいので、今一つブレイクしない そこそこ機能のある家電なんかには
組込OSは入ってると思うが。
そもそもOSなんてユーザーに見えなくてもいい。 >>60
それで合ってる
・・・「TRON系OSは2000年代以降も、主に炊飯器・洗濯機・カメラ・ゲーム機などと言った日本メーカーの家電製品に搭載されたマイコンを制御するための組み込み用OSとして、広く使われている。」 —Wikipedia
IEEEに著作権の移管・標準化されてるし、皆、知らない間に使ってるんだね 組み込みOSっていうとやっぱり感覚的にはリアルタイムOS(RTOS)なのかなぁ?
Linuxはリアルタイムクロック(RTC)やWatchDocもサポートしてるのでRTOSと
しても動作するよね
それともああいうのはRTOS言わない?w Unix系OSで厳密なスケジューリングは無理
それ以前にUnix系OSは組み込みには重すぎる >>62
WindowsだってRTCはサポートしてるだろ。WatchDocは知らない。 >>61
>皆、知らない間に使ってるんだね
この板に来る奴(趣味の電子工作おっさん)は使ったことがない奴が圧倒的多数だろうが
俺が社畜しているちんけな会社ですら昔からマイコンにTRON系OSを使っている。
いまや、ちんけな会社でもCortex-A搭載のSoMやFPGAを使う組み込みLinuxやっている状況だし
ターゲット組み込みだとCortex-A+Cortex-M搭載のSoC普通に出ているし >>66
> >皆、知らない間に使ってるんだね
> 昔からマイコンにTRON系OSを使っている。
昔は使っていたが、今 iTronは見掛けなくなった印象だけどなぁ。
印象だが(俺はハード屋)Armが当たり前となり、ソフト屋はメーカーサポートしているOS採用し、わざわざiTronを買ってくる事はせず、無論移植もしないし野良OSも使わない。
そんな俺様マインドシェアなのに未だにトップ↓とか、どこで使っているんだろう???
組み込みOSのAPIはTRON系OSがシェア60%、24年連続トップ
https://monoist.atmarkit.co.jp/mn/articles/2005/01/news072.html なんだ実シェアではなく
「パシフィコ横浜で開催された「Embedded Technology(組み込み総合技術展)2019」において、会場と特設Webサイトで実施したアンケート結果を集計」
なアンケート結果かぁ〜。
展示会に行く暇人(=現場エンジニアは行くヒマが無い)のアンケートなら、かなり偏りそうな気がするけどどうよ? >>69
こう言うのにまで iTRON が採用されてんだから、少なくとも日本じゃ相当なシェアになるんじゃ無いの?
https://i.imgur.com/kdFGZdg.png >>68
ARMのRTOSって何使ってんの?
Linuxはリアルタイム性に難ありだし、VxWorksとかになるのかな。
まさかのMbed? 普通は半導体ベンダーのOSじゃないかな
世界標準はFreeRTOSでiTRONなんて国内だけじゃないかな CMSIS RTOSなら
FreeRTOS(byあまぞん)がメインになるんじゃやないかな! >>71
>>73氏も言ってるけど今はFreeRTOSが多いんじゃないの。
Mbed OSはRTOSだっけ? 初期はそうじゃなかったけど、今はRTOSに進化したのかな? >>72-74
ほんとだ、結構ひろがってて、凄いな MicroC/OS-II がSilicon Labsに買われてオープンソースになった後放置されてるようだが使ったことある人いる? NIOS(アルテラ)使いたいんだが。 Azure RTOSは、「Azure RTOS ThreadX」の他、ファイルアロケーションテーブル(FAT)と互換性のあるファイルシステム「Azure RTOS FileX」や、組み込みグラフィカルユーザーインタフェース(GUI)アプリケーションデザイン環境「Azure RTOS GUIX」、Windowsベースの分析ツール「Azure RTOS TraceX」および、産業用グレードのIPv4とIPv6のデュアルネットワークスタック「Azure RTOS NetX Duo」が用意されているという。 >>78
ほぉーっ、こんなに導入実績があるんだ?
しかもマイクロソフトがね
・・・世界中の 100 億を超えるデバイスに導入されています。・・
https://azure.microsoft.com/ja-jp/services/rtos/#overview >>79
100億はまさかのスゲーっと思ったけど、Armチップは累計1800億個とか。
これにはスマホも含まれると思うが、その中でシェア5.6%は多い?少ない? Javaの30億とかしょぼいな。
いつまでたっても増えないし。 >>80
スマホだとAndroidだけど、これRTOSに分類されるの? >>84
RTOSに分類されないAndroidを持ち出されてもね FreeRTOSはメモリリークなんか絶対起きない、というのは本当ですか?
自慢気に語られました。 FreeRTOSのApplication Protocolsの中で関数ポインタが構造体のtypedefの内部で
使い倒されており、APIが理解し難く使い難くてたまらん。 FreeRTOS使って見ても、ラズパイLINUXと比べて優位点があるのか
いまひとつ確証が得られない。 ラズパイ & Linuxを使えるアプリで、FreeRTOSを使うものと比較する意味がどれぐらいあるんだろう。 Unix環境を余計とするか優位とするかでちがってくる
RTカーネルにしたら性能差はあるけど実際には困らないとは思う その通りだな、議論のレベルが違う
原付と乗用車比べるようなものだ FreeRTOSは有名だけど、それよりもAzure RTOSやNuttxがいいと思うんだよね!
カンだけど >>91
その通りで実際にはLINUX(ラズパイ)で困らないように思えてしまう。
RTOSの基礎的なタスク処理のしくみはともかく、FreeRTOSの売りはApplication
Protocolsで、HTTPSやMQTTまで無償だ。
メーカー製の有償RTOSですら暗号通信までサポートしているものはほとんどない。
けど現行のFreeRTOSは情報が少なく、自分が選んだMPUで自分が構築した
プロジェクトにHTTPSを組み込むのは一苦労で、その苦労が報われるかという話。
LINUXなら楽勝なのに。 >>95
それならRTOSを選択するのが間違いでは?
RTOSはリアルタイム性確保が主目的で、通信系はそれを邪魔する >>95
ラズパイ & Linuxを使えるアプリで、ラズパイ & Linux で困らないのは当たり前。
それとも、ラズパイ & Linuxを使えるアプリで、それ以外を使うケースとの比較なんだろうか。
とはいえ、ラズパイ & Linux以外を使うことを求められるのは、
処理能力的にラズパイ & Linuxを使えるとしてもそのほかの条件で、
結果として、実はそれがラズパイ & Linuxを使えないアプリだからでは。 >>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原則が言われ始めたおかげなのかもしれない。 携帯端末の定義なんかも20世紀からさんざん変わっており、通信機能が必須に
なったのも最近のことだ。
AmazonはRTOSにに暗号通信機能が必須と言っている。 そりゃAWS使わせるためにFreeRTOS買ったんだから
そう言うだろうよ まだあんまり調べられてないけど 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/ >>116
vPortYieldFromISR() でいくらカーネルオブジェクトを変更しても、
retiで元のタスクに一旦戻るから、次にカーネルに来るまでタスクは切り替わらない。