(toppers-users 3349) Re: TOPPERS/ASPをLPC1343チップに移植していますが、難儀しています。
koizumi yoshiyuki
koizumiyoshiyuki ＠ gmail.com
2010年 12月 28日 (火) 19:53:31 JST
酔漢さま
こいさんです。
スタックフレームの問題は前のメールに書きましたが同じ問題ですね。回避策は機能をバージョン1互換に戻す手法と、スタックフレームがアドレスの３ｂｉｔが１で割り込みが発生した場合のフラグがスタックに保存されているので、これを見て補正する手法もあるでしょう。どちらが高速に動くのかは良くわかりません。どちらが良いでしょうね。チップを作っているメーカの人は知っていると思います。
Cortex-M3はワンチップ用のマイコンです、バス幅はチップ内の話なので64bitにして処理速度を上げたのでしょう。違いは通常の使い方では表面に出ない問題ですが、Cortex-M3のTOPPERSでは割り込み処理の中で、モード切り替えの細工した為、見えてしまったようです。
割り込み処理の互換と性能の話ですが難しいですね。小生の頭の中では、問題が整理されてきたので、TOPPERS/ASPのディスパッチとその呼び出し周りの見直しを始めるところです。TOPPERSのディスパッチャ周りは元々、割り込みでディスパッチャが起動されるケースと、APIでディパッチされる場合で処理を分けています。（なぜ分けたのか、私には良くわかりません）
遅延ディパッチと呼ばれる手法を使えば分けずに実現できるはずです。これをやるとTOPPERSではなくなってしまうのかなと考えたりもしています。遅延ディスパッチをHWで支援する命令がPendSVです。TOPPERSではRTOS管理外割り込みの概念が有るので、RTOS側が少々遅くても我慢できるつくりにはなっていると思います。RTOS外割り込み(高速割り込みハンドラ)から、遅くても良いのでRTOS側とリンクを取るための手順も工夫する必要があるかも知れません。
又、現状のつくりではSVC命令が使えないのも少々気になっています。
以上
2010年12月28日14:04 suikan <suikan7 ＠ yahoo.co.jp>:
> こんにちは。酔漢です
>
> スタックフレームの処理というのは、
> http://d.hatena.ne.jp/suikan+embedded/20101005 の話でしょうか。私も他の
> 方指摘されるまで苦しんでいました。なんとなくTOPPERS/ASPのスタック配置を
> 8byte整列にすれば解決する 問題ではないのかと思っていますが、時間ができる
> たびに忘れているので放置状態です。
>
> TOPPERS/ASPがCORTEX-M3のNVICを活かしきっていない事については私も同じ考え
> です。しかし、（製品思想に依るとは思いま すが）RTOSの第一目標は信頼性で
> あり、CPUの機能を全部使う事ではないので私は今の状態で満足して使っています。
>
> もっとよくしたいと言う気持ちはわかりますし私も興味はありますが、CORTEX-
> M3のそういった深い部分について日本語で論じられている場所 は私も知りませ
> ん。おそらくどこかの掲示板でこいさんが口火を切って辛抱強く書き込みを続け
> なければ、同じような事に興味のある人は集まらないの ではないかと思います。
>
> TOPPERS/ASP, JSPをLPCxxxxに移植したと言う情報はネット上ではちらほら見ま
> すが、その結果についてノウハウを蓄積・公開しようという動きは見あたらない
> よう です。
>
> TOPPERSプロジェクトには会員専用のコミュニティがあります。ただ、そちらで
> ご質問の内容に沿うディスカッションをしているかどうかは、私 にはわかりま
> せん。
>
> 私もCORTEX-M4への移植を計画し、M0も情報を集めているところです。私が話し
> 相手で良ければTOPPERS/ASP for LPCプロジェクトの掲示板でお待ちしています。
>
> http://sourceforge.jp/projects/toppersasp4lpc/
>
> 酔漢
>
> (2010/12/27 12:58), koizumi yoshiyuki wrote:
> > 酔漢さま
> >
> >
> こいさんです。本件はCPUのバージョンによりスタックフレームの処理が異なることが原因だと判明しました。スタックが合わないのは仕様の認識の誤りでした。この対応を追加し、無事動作しています。ハードウェアは正しく動作していましたね。
> >
> > 処で、
> >
> 酔漢さんの名前は時々見かけ、色々参考にさせていただいています。小生、TOPPERS/ASPをCortex-M3以外(たとえばM0やM4)に移植する事を検討しています。又、現状のTOPPERS/ASPはARM7の割り込みアーキテクチャを無理やりCM3に移植しているように見えます。（私の個人的な見解です。たとえば、PendSVを使った遅延ディスパッチや、HWの多重割り込み機能を使うことで、TOPPERSがソフトで処理している多重割り込みをどのように回避すればよいのか・・・、など）この辺の議論がされているところをご存知でしょうか。（小生、netを探すのが苦手で、なかなか目的とする情報にめぐり合えないようです。自分のあほ加減を知るのは難しいでですね）
> > もう少し問題が整理出来たら、ここにあげることを考えています。
> >
> > 以上
> >
> > 2010年12月24日22:14 suikan <suikan7 ＠ yahoo.co.jp>:
> >
> >> こんにちは酔漢と申します
> >>
> >> LPC1000シリーズに関しては、LPC1768への移植例をSourceforgeで公開していま
> >> す。また、その移植過程についても私の Blogで公開しています。
> >>
> >> http://sourceforge.jp/projects/toppersasp4lpc/
> >> http://d.hatena.ne.jp/suikan+embedded/searchdiary?word=*[TOPPERS/ASP]
> >>
> >> 野良カーネルに抵抗がないのならば、見ていただくのも手かと思います。チップ
> >> 依存部をターゲット依存部から切り離しているほか、Doxygenド キュメントも用
> >> 意しているため、LPC1768からLPCからLPC1343への移植は楽なはずです。
> >>
> >> また、こちらで議論されていることもカバーしています。
> >>
> >> 酔漢
> >>
> >> (2010/12/14 14:40), koizumi yoshiyuki wrote:
> >>> こいさんです。
> >>>
> >>>
> >>
> 小生、LPC1343チップにTOPPERS/ASPを移植しています。sample1のmain_task動作中にusageフォルトが発生しています。
> >>> 移植の誤りの可能性もありますがディスパッチャ周りの動きが理解出来ず難儀しています。 何かヒントが頂ければ幸いです。
> >>> 当初メモリ不足でだましだましデバッグしていましたが、ｉｓｔａｃｋ問題でこちらは解決です。
> >>>
> >>> ★
> >>>
> >>
> targetの修正部はtarget_serial.cとtarget_config.cで後はincludeファイル名変更程度です。(cq_starmを使わないようした為）
> >>> 非依存部やアセンブラ部には手を入れていません。
> >>>
> >>> 現象
> >>> １
> >>>
> >>
> logtask_mainのsyslog_1を表示中(UART割り込みで出力継続)にmain_taskが動作しsyslogで出力します、がdoのループまで到達しないうちにusageフォルトになる。
> >>> ２
> >>>
> >>
> main_taskはsyslog_1の出力が完了し、時間に計測処理を行っています。計測処理中にタイマ割り込みでlogtaskのdly_tsk(LOGTASK_INTERVAL)が解除されます。logtaskの優先度が高いのでmain_taskは待ちになります。
> >>> ３
> >>>
> >>
> LPC1343のUARTはFIFIOが8段あります。logtask中に2byte出力して、UARTの割り込みが解除になり、残り6byteは割り込み処理でUARTにデータを詰め込みます。この時はまだlogtaskが動作しています。其の後、logtaskはdly_tskで待ちになります。
> >>> ４
> >> logtaskはdly_tskで待ちになったので、２で待たされたmain_taskに起動がかかりますが、このときusageフォルトが発生します。
> >>> ５
> >>>
> >>
> ２の時、タイマ割り込みを禁止にして、logtaskのメッセージ表示が終わった後、タイマ割り込みを有効にするとusageフォルトは発生せず、logtask_mainのメッセージは表示されます。(処理を単純にするため、テストタスクは起動していません。テストタスクのメッセージがどうなるのかは未確認)
> >>> ６ UARTの出力時にブレークポイント設定してもusageフォルトは発生しません。正常に動作します。
> >>> ブレークポイントを設定すると条件が変わってしまい、発生しなくなるため現象の把握に苦労しています。
> >>>
> 何かタイミング絡んでします。となると、UARTドライバの作りかも知れませんが、UARTドライバの戻りでフォルトが出ているわけではないようです。
> >>>
> >>> ★ ディスパッチャ周りで変だと思われる流れを見つけました。
> >>>
> >>
> ３のlogtaskはdly_tskの後をデバッガを使ってシングルステップで追いました。main_taskのスタックポインタが4byteずれているのではないか思っています。
> >>> １
> signal_timeで(*(p_tmevtb->callback))(p_tmevtb->arg);によりlogtaskがreadyになる
> >>> ２ signal_time関数を終了するとret_int:に戻り
> >>> ３ EXC_RETURN_PSPなのでret_int_1:に飛ぶ
> >>> ４ ”trueならret_int_3へ”でret_int_3:へ飛ぶ
> >>> ５ ”Threadモードへ移行”でret_int_4:へ飛ぶ
> >>> ６ 残りのレジスタを保存のときのスタックポインタが本来の値より-4されていると思っています。
> >>>
> >>> 割り込み時に8byteスタックに積み、4byteは捨てているが、4byte残ったままになっているのだと思います。
> >>>
> >>
> どこかでPSPを-4すればよいのでしょうが、何処で行えばよいのか分かりません。適当にPSP-4のルーチンを入れてみましたが別な処でトラップが発生しました。
> >>> ★ ブレークポイントを設定しデバッグを行っているので、この動きが正しいのかは分かっていません。
> >>>
> >>> ■ 分かりにくい説明で済みませんが、この辺り解る方が居られましたら、サポートをお願いします。
> >>>
> 一週間ほど費やしました、この間istackの設定誤り(?)を見つけ解決かと思いきや、システムは相変わらすフォールトで、私はハングアップ状態です。
> >>>
> >>> 追伸
> >>> 既にＬＰＣ１３ｘｘ系にTOPPERS/ASPを移植された方は居られませんでしょうか。
> >>>
> >>> 以上
> >>
> >> --
> >> 酔漢
> >> Blackfin 空挺団 http://blackfin.s36.coreserver.jp/
> >> TOPPERS/JSP for Blackfin http://sourceforge.jp/projects/toppersjsp4bf/
> >> Blog http://blackfin.g.hatena.ne.jp/suikan/
> >>
> >> --------------------------------------
> >> Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
> >> http://pr.mail.yahoo.co.jp/ie8/
> >>
> >>
>
>
> --
> 酔漢
> Blackfin 空挺団 http://blackfin.s36.coreserver.jp/
> TOPPERS/JSP for Blackfin http://sourceforge.jp/projects/toppersjsp4bf/
> Blog http://blackfin.g.hatena.ne.jp/suikan/
>
> --------------------------------------
> Get the new Internet Explorer 8 optimized for Yahoo! JAPAN
> http://pr.mail.yahoo.co.jp/ie8/
>
>
-------------- next part --------------
HTMLの添付ファイルを保管しました...
URL: <http://www.toppers.jp/pipermail/users/attachments/20101228/7d9003c9/attachment.html>