(toppers-users 3107) Re: sample1の’S'コマンドtslp_tskについての疑問

k.shinozaki sweet15th @ at717-oclock.sakura.ne.jp
2010年 3月 25日 (木) 19:16:07 JST


たびたび恐れ入ります。篠崎です。

私見ですが、Toppersカーネルを使われると言うことですので、プロセッサ依存の部分、
ボード依存の部分を「ドキュメントにある作法に従って」移植される方がよろしいかと個人的には思います。
カーネル共通部分に関する御疑念などは、本MLに投稿されれば碩学の方々にご回答いただけると
思いますし、カーネル自体の改良も随時進んでいるようにお見受けしますから
それに対するキャッチアップもしやすいかと思います。

他、実行時間測定に関してですが、「カーネルや他部分の影響もあるので統計的にデータを取った方が
より実際に近い」という考え方だったと記憶していますが、違っていますでしょうか。
単にその時々の実行時間測定だけを行うのであれば、ICEや古典的なI/O出力などの方法が
簡単な気もしますが、多数実行して傾向をつかむという方法が実践的で参考になった記憶があります。

以上、お耳汚しかとも思いますが、よろしくお願いします。



From: koizumi yoshiyuki 
Sent: Thursday, March 25, 2010 2:23 PM
To: users @ toppers.jp 
Subject: (toppers-users 3106) Re: sample1の’S'コマンドtslp_tskについての疑問


篠崎さま

 下記のページの紹介有難うございます。知ってはいましたが、2回までしか進んでいません。読んで直ぐに理解できるほど賢くないので、余白に書き込みをしながら、じっくり読まないと理解できない状況です。画面だけでは小生少々辛いです。

以上


2010年3月23日19:31 k.shinozaki <sweet15th @ at717-oclock.sakura.ne.jp>:

  ML拝見しております。

  篠崎と申します。開発側の方々にはこういった情報も公開していただいているようです。

  http://www.nces.is.nagoya-u.ac.jp/NEXCESS/blog/index.php?itemid=129

  参考になりませんでしょうか。ITRON仕様書も当然読まれていると思いますが、下手に解釈するより
  こちらの解説を読まれた方が良いかと思います。
  サンプルはOSそのものの動作試験用途かとも思いますので、移植後一通り動作するようでしたら
  ご自身で再構築してみた方が使いやすいのではないでしょうか。

  以上、横レスになってしまいますが失礼させていただきます。



  From: koizumi yoshiyuki 
  Sent: Tuesday, March 23, 2010 1:32 PM
  To: users @ toppers.jp 
  Subject: (toppers-users 3100) sample1の’S'コマンドtslp_tskについての疑問


  koisanです。

   sample1を使ってTOPPERS移植後の確認をしています。
   ’S'コマンドtslp_tskを実行すると、待ち時間を過ぎた時E_TMOUT・・・とエラーが発生しているようなメッセージが出ます。TOPPERSの移植に誤りがあるのか、tslp_tskの仕様か判断できないので質問します。
   slp_tskは待ちになって戻ったときE_OKになっています。tslp_tskの動作を考えると、待状態になり、設定時間を過ぎてタイムアウトになったと考えるのか、設定時間を過ぎてtslp_tskが正常動作したと考えるのか判断に迷っています。TOPPERS新世代カーネル統合仕様を見ましたが、小生にには判断できませんでした。sample1ではエラーだと考えて作ったように見えます。小生の移植に間違いがあるのか心配です。

   sample1について疑問
   main_taskの起動時に実行時間を測定してる処があります。ここに#ifdef MEASURE_TWICEの記述があり、コメントには一回目の測定は正確ではないので捨てると書かれています。確かに1回目と2回目では測定時間が違っていました。この差は1回目と2回目の差ではありますが、測定の前に自身が実行しているsyslogが関係していると思われます。実行時間の測定は他のタスクや、意図しない割り込みが実行されない状態で測定する必要がありますが、デバッガで止めると1回目の測定時はメッセージ表示が完了していませんでした。user.txtには、logtask_flush(0)の記述がありログ出力完了がチェックできるので、2回測定するより、logtask_flush(0)で回避するほうが好ましいと思っています。

   更に疑問
   そもそも、実行時間の測定が何故必要か考えてみました。
   測定値はtaskでメッセージ出力を行った後のloop回数に使用しています。このloopを削除すると、ログ処理でバッファ不足が発生するので、ログの出力が大量になる(連続する)のを防ぐために使われているようです。この時間はログ出力の時間により変化する値なので、待ち時間の設定値の算出基準のコメントが欲しいと思っています。
   こちらの待ち時間をlogtask_flush(0)で回避することは出来ません。logtask_flush(0)はバッファが空でないときdly_tskを実行するのでディスパッチが発生します。taskはディスパッチが発生しないことが前提です。dly_tskのないlogtask_flush_nwでも追加し時間待ちのloopは削除するのがよいと思っています。

   尚、sample1のログが常に流れているのは使いにくいと感じています。
   外のタスク(main_task)と自タスク用にタスク動作メッセージ表示要求フラグを作成し、タスクの動作条件が変わった時にフラッグを使ってメッセージを表示するような修正を考えています(ほぼ動作しています)。
   tslp_tskの問題は動作していないタスクに発行すると、すぐには表示されません、他のコマンド操作でスリープしたタスクが動作したときに一瞬表示され先に進んでしまうので、問題にたどり着くまで多くの時間を使いました。こんな意味で、現状のsample1は使いづらいと感じています。
   (小生、この仕事を始めた当時、時間待ちの処理は将来必ずトラぶるので、安易に時間待ちをしてはいけない。必ず報告と正確なコメントの記述せよと、Y先輩から「きつい指導」を受けました。Y先輩の言葉を思い出し、この処理はくさそうだと細々調べてみました。小生の解析は誤りがあれば連絡ください。koisanとY先輩のKYな話でしょうかね)

   以上
-------------- next part --------------
HTMLの添付ファイルを保管しました...
URL: <http://www.toppers.jp/pipermail/users/attachments/20100325/3c3dac15/attachment.html>