Q&A
通信タスクがデータを読んでる間、(排他されてるもんだから)センサタスクがデータを更新できない、ってことですか?
バッファを置けばそこにコピーする短い時間だけ排他すればいいのでしょうが、うーん...
プリエンプティブマルチタスクなRTOS・C言語を使用して、
センサの値を通信で他のマイコンボードに送信する機能を作っています。
用語
・センサタスク・・・センサ値を取得しセンサモデルにセット、センサドライバが実行される。
・センサモデル・・・センサ値を保持する(排他制御有り)
・通信タスク・・・センサ値を通信で送信、通信アプリが実行される。
センサタスク(タスク優先度高)で1ms周期でセンサ値をAD変換し、
センサモデルにセンサ値をセットします。
一方で、通信タスク(タスク優先度低)では10ms周期でセンサモデルからセンサ値を取得し、
通信で他のボードへセンサ値を送信します。
センサモデルのデータは、
データのセット、取得時にバイナリセマフォで排他制御を行っています。
センサタスクと通信タスクのタスク優先度の間には、
他にも処理が重いタスクが複数あります。
問題：
通信タスクでセンサモデルからセンサ値を取得する際にセマフォを取得すると、
センサタスクがセンサモデルにセンサ値をセットする際に、セマフォで待たされ、
センサ値のAD変換の1ms周期が満たせなくなります。
この問題は、どのように回避すればいいのでしょうか？
センサデータのサイズがかなり大きいため、
ダブルバッファ等を使わず、RAMの使用量を最小限に抑えたいです。
よろしくお願いします。
回答がつかないので、stackOverflowでも質問しています。
回答がもらえたら、こちらで報告します。
> RAMの使用量を最小限に抑えたい
いまさら言うことではないとも思いますが、RAMを余らせても仕方ないので「最小限」にすることは意味がないです。組み込みの場合は言ってしまえば足りなくならければOKですから(まぁ、多少は将来の拡張を見込んで確保...とかもありますけれど)。
具体的に、システムのRAMがどれだけで、現状での使用量/空き容量がどれだけ、データサイズがどれだけなのでしょう。
すでに検討済ではあるようですが、バッファを噛ませるのが普通に思いつく対策なので、それがダメだという経緯は示しておいていただきたく思います。
あとは...通信タスクを起こすのは誰なのでしょう。単にタイマーで起こされるようなタスクなら、センサが10回データを取ったらそれをトリガにして通信タスクを起動すればよい、なんていう構造も考えられなくはないと思いますが。
> 単にタイマーで起こされるようなタスクなら、センサが10回データを取ったらそれをトリガにして通信タスクを起動すればよい、なんていう構造も考えられなくはない
ああ、確かに。同じデータを送っても意味無いし、送信し切れないデータを集めても仕方無い。センサーデータの重要度も関係するかもしれませんね。1度たりとも欠落してはならないのとそうではないのとでは、えらい違いです。（クリップこそしてませんが実は注視している質問です）
>通信タスクがデータを読んでる間、(排他されてるもんだから)センサタスクがデータを更新できない、ってことですか?
その通りです。
通信タスクのタスク優先度は、センサタスクよりもタスク優先度が低いため、
通信タスクが多少待たされるのは許容できるのですが、センサタスクが待たされると
センサ値の取得タイミング1msが守れなくなってしまいます。
>バッファを置けばそこにコピーする短い時間だけ排他すればいいのでしょうが、うーん...
通信タスクがコピーする時間を短縮できたとしても、
センサタスクと通信タスクの間の優先度に、処理が重いタスクが複数あるので、
コピー中に運悪く、これらが割り込んでくると、結局はセンサタスクが待たされてしまいます。
> センサが10回データを取ったらそれをトリガにして通信タスクを起動すればよい
これはアリでしょうね。あるいはセンサタスクがデータ書き込み完了したタイミングで(mutex+condition_variableかなんかで)他タスクの待ちを解くよな造りも考えられる。
>いまさら言うことではないとも思いますが、RAMを余らせても仕方ないので「最小限」にすることは意味がないです。組み込みの場合は言ってしまえば足りなくならければOKですから(まぁ、多少は将来の拡張を見込んで確保...とかもありますけれど)。
すみません、質問にかけてなかったですが
センサタスク・通信タスクと同じような、排他制御の問題を抱えている箇所が
他にも60箇所以上あるので、排他制御の問題に解決をするためにRAMを使うと、
それが数十倍になってなって返ってきます。
なので、RAM使用量を最小限にと書きました。
余らせても意味がないのはその通りです。将来の機能拡張のためです。
>具体的に、システムのRAMがどれだけで、現状での使用量/空き容量がどれだけ、データサイズがどれだけなのでしょう。
使用料/空き容量は、450kb/50kb程度です。
データサイズは、200byte程度です。
>すでに検討済ではあるようですが、バッファを噛ませるのが普通に思いつく対策なので、それがダメだという経緯は示しておいていただきたく思います。
センサモデルに相当するものが60個以上あり、
バッファをかませるためにRAMを使用すると、RAMが溢れるためです。
>あとは...通信タスクを起こすのは誰なのでしょう。単にタイマーで起こされるようなタスクなら、センサが10回データを取ったらそれをトリガにして通信タスクを起動すればよい、なんていう構造も考えられなくはないと思いますが。
その方法が合理的だとは思うのですが、
通信タイミングは、通信相手との間の通信規約で定められていて、
変えることができません。
>センサタスクと通信タスクの間の優先度に、処理が重いタスクが複数あるので、
RTOSのセマフォまたはミューテックスで、優先度継承プロトコルはサポートしていないのでしょうか？
これを使うと通信タスクが資源をロックしている間にセンサタスクより優先度の低い他のタスクが割り込むことがなくなるので資源を占有している時間を短縮できます。
優先度継承プロトコルをサポートしているので、試しに使ってみます。
回答1件
ベストアンサー
あなたの回答
tips
プレビュー
