Hyper Operating System(ITRON仕様OS)

Fork

メールボックスは、手元では動いているのですが。

すいません、宜しければ静的APIの記述とか、snd_mbx、rcv_mbxを使った所のコードを書いてもらえると、何か判るかも知れません。

>ソースをみますと、メッセージの取得でプライオリティを
>チェックして待ちに入いっているようです。
その部分は、プライオリティをチェックして待ちに
入っているのではありません。

　for ( msgpriを0→「最大優先度-最小優先度」カウンタとしてループ)
　{
　　優先度 「msgpri-最小優先度」のメッセージがあれば break;
　/* メッセージを優先度順に検索 */
　}

　if ( msgpri <= mbxcb_rom->maxmpri - TMIN_MPRI )
　{
　　カウンタが「最大優先度-最小優先度」以下なので、受信有り
　　受信処理を行い E_OK
　} else
　　先の検索ループでメッセージが検出できなかったので、
　　待ちに入る…

>msg = mbxcb_rom->mprihd[msgpri]
>if (msg != NULL){
>if (msg == msg->next )
この修正だと、範囲外の不定な値を参照するしていませんか？


以下どうでもいいこと

一時的なもので構いませんから、何か名乗っていただけると
フォローが書き易いです。

匿名については問題ありません。
今のように空いた状態であれば、誰が何に対して発言して
いるのか不明で分かりにくいといったこともありませんし。
ただ、何か識別子が無いと「～さんの修正は」とか
書きにくいというだけの、個人的な感覚です。

優先度については、よく勘違いしてしまいますね。
私も同様なことで嵌ったことがあります。

今後も不明な点がありましたら、お気軽にお問い合わせ
下さい。常に即答、解決に至るとは限りませんが。

100パーセントm-araiさんのお陰ですが、問題が解消してよかったですね。実は私もTA_MFIFOで今更勘違いしていた所が見つかって、助かりました。

イベントフラグですが、一つのイベントフラグに、同時に複数のタスクが待ち状態になるかどうかは実装依存で、HOSではサポートしていないですね。
ちょっと不便にも感じますが、イベントフラグの実装を軽くするには、その処置も適切かとも思えます。
イベントフラグって、最も軽いタスク間通信を期待してしまいますから。

静的生成の際に、TA_CLRを指定しなければ、勝手にクリアしない筈です。そうではなくて？。

「いけない」ということはありません。(^^)
また、「起こせない」という表現には違和感を感じますが、
つまりそういうことでしょう。

仕様書 Ver.4.02.00 p142を参照してみると、
TA_CLRとは「タスクをイベントフラグ待ち状態から
待ち解除する時に、イベントフラグのビットパターンの
すべてのビットをクリアする。」というイベントフラグ
属性です。それを意図的に指定する以上、そうなるのは
当然のように思えるのですが。

【補足説明】のところにも記述があります。
「TA_CLR属性のイベントフラグの場合、タスクを一つ待ち
解除した時点でイベントフラグのすべてのビットをクリア
するため、複数のタスクを同時に待ち解除することはない」

TA_CLRの振る舞いを、『待ち解除条件を満たす'全ての'
タスクを待ち解除した時点でビットをクリアする』ものに
変更したければ、タスク起床ループ内の

　if ( flgcb_rom->flgatr & TA_CLR )
　{
　　flgcb_ram->flgptn = 0;　/* クリア属性があればクリア */
　}

を
　/* 起動を行ったタスクがあるならディスパッチを行う */
　if ( wupflg )
　{
　　ここ
　　mknl_exe_dsp();　/* タスクディスパッチの実行 */
　　mknl_exe_tex();　/* 例外処理の実行 */
　}
に移動すれば良いと思います。(試してはいません)
勿論、この改造は仕様を逸脱しますが。


余談:
set_flg.cを見なおしていて気づいたのですが、
タスク起床ループ内の
　if ( flgcb_rom->flgatr & TA_CLR )
　{
　　　flgcb_ram->flgptn = 0;　/* クリア属性があればクリア */
　}
は、起床処理の後に移動して break; を加えるべきかな。
無駄な検索を少しだけ減らせる可能性があります。