ちょっと時間が開きました。
実は前回まで書いた作業は出張前に慌ててやった物でして、テキストは出張中に書いた物だったりします。先週の週末に出張から帰ってきて、ようやくこの連休に追加作業の時間がとれました。
結論として、TOPPERS/ASPはLPC1830 Explorer上で動いています。コメントおよびDoxygenコメント、MANIFESTファイルはチェック済みで、おそらく target/lpc1830_generic_gccはリリースしてもいいでしょう。私は簡単なチェックでOKとするいい加減なヤツなので、リリースもすぐです。
ただ、ここに到るまで紆余曲折がありました。大きな問題は二つで、移植にかかった時間の大半はこの二つでした。
アサーションが起きる
一つはLPC1830への理解の不足の問題です。問題が眼の前に現れたときには、「CPUロック（割り込み）禁止期間で割り込みが発生している」というアサーションの形でした。そんな馬鹿なことがあるか！と思われるかも知れませんが、TOPPERS/ASPではあり得ます。TOPPERS/ASPカーネルは、割り込みの許可/禁止、CPUのロック、アンロック、ディスパッチの許可/禁止などのAPIを用意しており、ターゲット依存部で実装しなければなりません。
TOPPERSプロジェクトが公式配布しているCORTEX-M3依存部はCPUロックAPIを実装しています。この実装では、ロック状態制御をCORTEX-M3 BASEPRIレジスタで行い、その状態の検出を連動するフラグ変数で行っています。そのため、この二つの連動がずれれば当然のように「割り込み禁止状態で割り込みがかかる」という妙な事が起きます。今回はアサーションがかかったわけですが、逆にいえばよくある問題なのでassert()を仕掛けているのでしょう。
何故CORTEX-M3依存部でCPUロックを実装しているのにLPC1830依存部だけが問題を起こすのでしょうか。それは、実装の一部がパラメータ化されているからです。
CORTEX-M3依存部はCPUロックをBASEPRIレジスタへの操作で行っています。このレジスタには割り込み順位を指定でき、その順位以下の割り込みは阻止されます。ところが、CORTEX-M3では、SoC設計者の判断で割り込みレベル数を制限することができます。この制限は割り込み順位を固定小数点数として扱うことで成り立っており、最大8ビットあるフィールド幅を変更して使います。
LPC1768ではこの幅が5bitでした。だいぶ長くなったので結論を書くと、このビット幅が変わったにもかかわらず、ソースコード内で正しい値を指定しなかったために問題が起きました。ファイル名はarch/arm_m_gcc/lpc1800_gcc/lpc1800.hで、指定に使うマクロはTBITW_IPRIです。この値を3とすべき所を5にしていたため、正しい割り込みマスクが作られず、冒頭の妙なアサーションが起きたのでした。
では何故間違えたのでしょう？それはマニュアルにある情報にバグがある（と思われる）からです。LPC1830のユーザーズマニュアル、UM10430は、NVICの章でIPR0の説明を以下のようにしています。
Interrupt Priority Registers 0. This register allows assigning a priority to each interrupt. Each register contains the 5-bit priority fields for 4 interrupts.
5-bit priority fieldと書いています。UM10430にはCORTEX-M3のSoC設計社によるコンフィギュレーションパラメタが書いてありません（単に見つけていないだけの可能性もある。1200ページ）。
では、なぜ3bitではないかと考えたかというと、この章の冒頭にこう書いているのです。
Eight programmable interrupt priority levels with hardware priority level masking.
8レベルです。8レベルに5ビットは要りません。3ビットで足ります。TBITW_IPRIを3にしたところ、アサーションは消えました。
シリアルポート
もう一つ、シリアルポートのハンドルで苦労しました。結論から言えば、これはリリースしていないリポジトリの先頭をベースに選んだ私のミスです。
リリースしたコードをベースにしたところ、問題なくsample1が動作するようになりました。
ソースコードは toppers/asp for LCPプロジェクトのgitリポジトリ、experimental-1843-cleanから取得できます。