CMSISとGCC
LPC1768の学習は、今週末少し開き直ったことでかなり進みました。先ほどTIMERによる割り込みが正常動作することをSRAM/FLASH上の実行で確認しました。GDBも快調ですし、GDBからレジスタをアクセスする仕掛けもそれなりに助けてくれます。これまでの仕込みがうまく機能している感じです。
一方、CMSISについてはいちいち躓いています。一つはARM提供のCORE部のCMSISの完成度とNXP提供のCMSISの完成度に著しい違いがあることです。具体的にはDoxygenコメント。CORE部はドキュメントが割と充実していますが、NXP部はまったく提供されていません。結局ソースをスクロールしながら調べ物をするわけで、なんだかなぁと思います。
まぁ、R8C Tinyで味わった衝撃に比べれば天国ですが。
LPC17xxにはPLLの設定ルーチンがCMSISに用意されていますが、このルーチンには引数がありません。はて、とおもって調べたところ、KEILのツールに付属のコンフィギュレータで自動生成したとか。GCCには当然そんなツールありません。
だめじゃん！
TOPPERSプロジェクトは今後の方針をはっきりとさせたほうがいい
s_meikaさん経由でASPカーネルの新リリースを知りました。相変わらず私は情報が遅い。
最新カーネルが1.6である一方、公式配布されているCORTEX-M3依存部は、カーネル1.3.2対応です。これはいったいどういうことなのでしょうか。
1.5、1.6と矢継ぎ早に発表されたバージョンアップですが、TOPPERSプロジェクトをのぞいてみると、対応依存部として発表されているのはMacOS依存部だけです。組み込みOSなのに、公式サイトには最新版用のターゲット組み込みCPUが公開されていません！！
情報がないなら勘ぐるしかない
私はTOPPERSプロジェクトのメンバではありませんから、内部で何が起きているかはわかりません。しかしながら、この動きからは今後TOPPERSプロジェクトがどんどん閉鎖的になっていくことが伺えます。建前上はオープンソースとしていますが、おそらくはプロプライエタリなビジネスにフォーカスしていくのでしょう。
最新２バージョンのターゲットがシミュレータ以外公開されておらず、かつ、世界で一番勢いのあるCORTEX-Mシリーズがすでに３バージョンの間手つかずなTOPPERS/ASP。どうつきあうべきか少し考えてしまいます。
オープンソースの看板を下ろした方がいいのではないでしょうか。
GDBでCORTEX-M3をきれいにリセットする方法
デバッガが不安定だと何をしているのかわからなくなっていやなものですが、デバッガにはデバッガの事情があっていろいろと難しい面があります。中でも大変なのは「リセット後に停止」することです。
アプリケーションはリセット状態から実行する用にかかれています。しかし、デバッガを使ってデバッグを開始する直前はターゲットは実行状態だったわけで、リセット直後の状態にはなっていません。これを何とかしないと、想定していない状態からの実行となり、いきなりデバッグが破綻します。
OpenOCD / GDBの組み合わせでは、GDBのコマンドラインで次のようなことをしろとする例をよくみますし、私もそうしてきました。
(gdb) monitor reset (gdb) monitor halt
しかしながら、これはうまくいかないことがあります。最初のコマンドでターゲットが実行を開始してしまうため、割り込みにでも入ろうものなら、せっかく停止して新しいプログラムをロードしても、CPUやペリフェラルは割り込みを起こす気満々だったりします。
そうするとSRAMにロードした直後のプログラムは割り込みを受け入れる体制が整っていないため、最初のステップ実行から動作が破綻することもありえます。
そこで、次のようなコマンドを発行すると、この問題を解決できます。
(gdb) monitor soft_reset_halt
停止状態でターゲットをリセットしますので、プログラムをロードしてきれいに実行させることができます。
