【Toppers】組込みOSのスレがないじゃないか【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で元のタスクに一旦戻るから、次にカーネルに来るまでタスクは切り替わらない。 今インターフェース2021年4月号みてるが、p49 図4解りやすく書いてるね。
設計思想として、どうなんだろうって思うね。
特に小さい遅いマイコンの場合はtime tickを長くして負荷を減らすようにするのが定石だけどね。
実際、5MHhzのマイコンの場合は
10msをtimetickにしてたし、
そうなるとタスク起動は、10ms待たされることになる。
それなら、割り込み使ってタスク起動なんて遅いだけだと思うね >>117
個人のブログじゃなくて公式の資料読んだ方がいい
YieldFromISRはコンテキストスイッチを起こす http://w3c.digital-rc.sub.jp/?eid=47#gsc.tab=0
このサイトに実験結果が書かれている。タスクディスパッチはtime tickの1ms周期でしかしないという結論だよ 全面的に俺の間違い、勘違いでした。すまなかった。
実際ソースを見た。 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のサイトの記載がよろしくないんだろうと思う。
実際ソース見て、どや顔するつもりが逆になったという話でした。 だから個人ブログじゃなくて公式見ろと
自分で挙げた >121 を読んでも理解できないようでは仕方ないけど 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
公式でも同じ。 個人がこんなカーネルのコアな部分さわるとかないからね。 バカなっ・・・あいつ赤信号なのに・・・・・轢かれたぞっ!! RTOSについて検索しても「FreeRTOSでTCP/IP」みたいな記事ばかり出てくる
・RTOSっていっぱいあるけど何がどう違うの?
・○○みたいなのを作りたいのだけどどのRTOSが適しているの?
みたいな疑問は全く解消されない RTOSはDOSやUnix系OSに慣れた人には最初取っ付き難い
昔ベアメタル環境のプログラミングしてたら感覚的に理解出来るだろうが RTOS本来の恩恵で考えれば、どれ使っても同じだとおもう。
ペリフェラルをコントロールするライブラリが充実してるとか簡単に見つかるとか、書籍やWEBが多くて調べやすいとか
重要なのはそのあたり。そういう差じゃないだろうか?
ディスパッチさえ書ければだいたいの制御は事足りると個人的に思う レスサンクス。どちらかと言えばベアメタルでゴリゴリ書く方だけどRTOSの説明を読んでもピンとこない
・よくある解説だとタスクA/タスクB/タスクCみたいな例が示されるけど3個くらいならハードウェア割り込みベースのタスク管理と大差あるとは思えない
もっと大規模なシステムなら恩恵があるのかもしれないがそのような解説は見つからない
・リアルタイム制御と説明されるがどのくらい時間精度を実現できるのかという情報はあまり見かけない
極端だがソフトウェアUART(usオーダー)やソフトウェアUSB(nsオーダー)といったタスクをマルチタスク動作させられるのか?
あとデバイスドライバは高速応答が発生しがち
・RTOSを利用したシステムを実装するうえでRTOS下にない処理(便宜上タスクと呼ぶ)の取り扱い
すべてのタスクをRTOS下に置けないというケースは現実的にあると思われる。例えば割り込み後最速でDMAを起動する必要があるなど
最近のマイコンはCPUを介さずにあれこれ出来たりするけどそのような機能の扱い方。またそのような動作は大なり小なりRTOSの動作を乱す
・移植性が高いと説明されることがあるが各RTOSでどう違うのか
一部のCPUがもつ高速にコンテキストスイッチを実行する機能を利用できるような改造をしやすいかなど 余談かもしれないが
リアルタイムOSのリアルタイムの定義はその仕様書のオーダーによるんだ。
仕様書に一分以内に完了することと書かれていたらほぼどんな書き方でもマイコンでもリアルタイム制御を実現できるし、その条件を満たせばリアルタイム。
逆にレーザー距離計を作るとして光の波長を捉えようとしてもリアルタイムで光波をカウントできるマイコンやFPGA、OSはこの世に無い。
車のブレーキであればmsecで制御を返せばよくて、人間の反射はもっと遅いからリアルタイム制御と言える。
どんな案件でどこまでをリアルタイムと定義するかによる。
タスクはいいよ
仮にLED100個の点滅をmsec単位でユーザーが起動後それぞれ自由に変更できるシステムを構築するとしたらどう?
マルチタスク無いと相当大変な工夫が必要じゃない?
たとえタスクなしでそのシステムが完成しても、顧客から仕様変更でUARTをはさみたいと言ってきたらイチから見直さないといけなくなる地獄
タスクいらないという人もいるのも事実なのでこれ以上は言わないけど。 DMAはCPUから独立して働くとおもうので、CPU上のRTOSを乱すとしても影響は小さい?、詳しい人が以下にあほバカ言いながらレスするだろう。
注意しないといけないのがDMA先のメモリ参照とCPUの参照先がデッドロックを起こすかもしれないのでミューテックス・セマフォを使わないとだめだと思う。
移植性はなんとも >LED100個の点滅をmsec単位でユーザーが起動後それぞれ自由に変更できるシステムを構築するとしたらどう?
100個のLEDを完全独立制御するのは特殊ケースだろう。一般的にはダイナミック駆動で点灯することになると思われる
となると割り込みによる入力&処理タスクとタイマ&DMAによる波形生成タスクの2分割かな
後者はCPUに依存しないからCPUの仕事は前者のみ。これにUARTによる通信機能を追加しても割り込みで十分対応できるはず
というかもっと実践的な例示をしてほしい
例えばハイエンドマイコンに液晶パネル、オーディオアンプ、スピーカー、SDRAM、フラッシュメモリを外付けして動画を再生すると仮定する
外付けのフラッシュメモリやSDRAMは遅いからメモリは2〜3層の階層構造をもち、必要に応じて先読みやバッファする
ソフトウェアが行うべき主な仕事は
・フラッシュメモリ読み出し
・読み出しバッファ制御
・ファイルシステム制御
・スプリッタ
・ビデオデコード
・オーディオデコード
・ビデオレンダリング
・オーディオレンダリング
・ビデオ/オーディオ同期制御
・フレームバッファ制御
・オーディオバッファ制御
・液晶パネル制御
・オーディオ出力
・UI入力
あたりかな?リアルタイム制御はmsオーダーだしRTOSを応用するシステムとしては緩めか
でこれらの仕事をどのようにタスクに分割してどのようなタスクの実行条件を設定し効率的に動作させるか?って問題
ITRON系の本を読んでもこのような実践的な解説は出てこないし、FreeRTOSの解説サイトを見ても同様 RTOSちょー便利ー
予想してたけどめちゃコーディング楽ちんでちょっとだけ感動した。 最悪応答時間がOS+MCUの組ごとに規定されてほしい。 が、実際はそうなっていない。
STM32F0xx+FreeRTOSの場合、最悪応答時間をクロックやタスク数等の関数として知りたい。
「応答時間が保証できないRTOSは無価値」というベアメタル原理主義の人に反論するにはその武器が必要なのです。 >>136
サービスコールによってクリティカルセクションの長さが違うから、それを求めるのは難しいんでしょうね。
正しくRTOSを使うシステムを作って実測し、その実測値に遅くなりうる要因・時間を上乗せするのが現実的ではないでしょうか。
非最高優先度のタスクは悩ましいけれど、RTOSが持つ機能でどうにかできるはずです。
マイコンとRTOSの性能よりも、それらを正しく使うことの方が重要だと思います。
使うのはヒトですから、以下のような間違いや経験不足はついて回ります。
優先度を間違えた、ミューテックスを使うべきところにバイナリセマフォを使った、
同期IOした、割り込みハンドラの処理が長い、安易に排他している、DMACがあるのに使っていない rtos思ったより難しいなぁ
擬似マルチタスクなんだね. 僕美容院の予想が当たらないの?
上がってもまだ含んでる・・・・ 早くなんとかしないと思うよ
まず
名前がかっこよくね
スノはなんなのではないな ナウシカ
嫌!なんにも773円の頃ETF2300円だったんだが FreeRTOSとAzure RTOSとでは、FreeRTOSのほうが優勢に見える。
ライセンス条件が甘く、任意の(特に中国製MCU)に自由にインプリできるのは
大きいのか。
AzureクラウドですらFreeRTOSをサポートしているし。 >>147
AzureRTOSはThreadXベースなんですね。ThreadXはほとんど印象がないです。
uITRONを買収したら日本人にはよかったかも?坂本氏は昔ほどの元気もなさそうだし。 Azureは重すぎる、と言うか重装備過ぎるんよ
クラウド接続前提にしすぎてるから…
uITronみたいに、コアだけでもってのとは方向性が違うよね FreeRTOSもAzure RTOSも、APIの仕様がITRONと比べてレベルの違う複雑さだ。
クラウド接続機能の特にTLS暗号が重い。それに合わせてAPI設計しているから
すべてが重くなっている。
制御目的でマルチタスク機能だけ欲しいというユーザ層には、あまりにオーバースペックだ。 これって昔からあった問題かもね。
DOSでパソコンアプリを作っていた人にとって、Windowsのオブジェクト指向APIは
発想の大転換が必要だっただろうし。 設計のアイデアを教えてください。関わりそうなRTOSはZephyrかFreeRTOSです。
■ハード
・押しボタンSW3個
・LCDドットマトリクス
・SWは外部割込ピンに接続
■機能
・SWでLCDの画面切替を行う
・画面別にSW1個または複数個の押下げ・長押しに応じ異なる処理あり
実際にこういう開発をしているわけではなく、典型例です。
RTOSベースで設計する場合、すぐにイメージできないのが
①チャタリング対策
② SW別の処理切り分け
です。通信系はイメージしやすいです。
どちらもOSタイマをうまく使うのがいいのかな。②はイベントフラグ向きに思えますが、画面別に独立にする方法が浮かびません。
ベアメタルだと①は、SWに外部割込を使わず定期ポーリングで複数回読み込み。
②は①を元に同時押しや条件成立でフラグ立てるか関数テーブルで分岐。 その内容だとRTOS全く関係ない質問なんだけど。
チャタは普通、入力割り込み後チャタが収まるミリ秒程度sleepすればいいだけ、
ポーリングだとタイミング的に運悪く意図しない論理を拾う可能性が残らない?
②は好きにかけば良い感じ。 >>152
そういうスイッチだと押してイベント、離してイベントの時間間隔を計るのでは。
・短ければチャタリング
・一定期間(0.2秒〜3秒くらいかな)だと通常の押下
・それより長ければ長押し 草だけ生やして、だんまり決め込む人生。
ある意味うらやましいっすよパイセン >>155
>チャタは普通、入力割り込み後チャタが収まるミリ秒程度sleepすればいいだけ
なるほど、それはひとつのやり方ですね。よさそう。
長押しや複数長押しは…
ベアメタルの場合のポーリングは例えば10ms周期で行って、4回連続の入力の一致で確定とします。長押しは確定と同時に時間計測開始、確定が変化したら計測中断です。 >>158
長押し判定について、私ならRTOSのマルチタスクを利用して
SW割り込み先処理の中にsleep10msを設置します。
同じ位置に長押し用カウンタを設置し、割り込み回数を数えます。
4回(40msec)で確定
304回(3秒押し)で長押し確定
という処理にします。
sleep中でもCPUはハングアップしないので、同時に多数のボタン割り込みを処理できます。
あくまでも一例なのでもっといい方法は>>154が書いてくれるでしょう。