前回は事の経緯だけで終わってしまいました。今回はLPC1830へのTOPPERS/ASP移植の概要を説明します。
TOPPERS/ASPはTOPPERSプロジェクトによってCORTEX-M3アーキテクチャに移植されています。このため、コンテキストスイッチについては他のCORTEX-M3アーキテクチャでもそのまま使えます。また、TOPPERS/JSPのARM-v4 (ARM7TDMI)版移植で頭を使った割り込み出入口処理については、CORTEX-M3コアがNVIC割り込みコントローラを内蔵しているため、出入口処理もCORTEX-M3依存部に内蔵されており、移植に関しては割り込みベクトルへのペリフェラルのマッピング程度で済むようになっています。
一方、TOPPERS公式CORTEX-M3版は、構造が共通部のほかに、Target依存部、Core依存部の二つに分かれています。これは「共通項になることが多いコア依存部を切り離して移植性を高めるため」です。が、SoC化が進んだ現代では、TOPPERSプロジェクトがターゲット依存部とするもののほとんどがチップに内蔵されています。たとえば、タイマー、シリアルポートなどがそれです。そこで、TOPPERS/ASPをLPC1769に移植する際、Target依存部をさらに二分して、Chip依存部とTarget依存部としました。つまり、TOPPERS/ASP for LPCプロジェクトは、ターゲット依存部を、CORE, CHIP, TARGETの三層に分けています。
TOPPERS/ASPのアーキテクチャでは、ターゲット非依存部が参照するのはTarget依存部だけです。そして、実装を多層化したければ、Target依存部から、より共通度の高い層に向けてリンクを張る形で層を深めています。先に書いたようにTOPPERSプロジェクト公式では二層、TOPPERS/ASP for LPCプロジェクトでは三層になっています。
この多層構造は、次のように実装されています。
- インクルードファイルは、入れ子インクルードによって、target -> chip -> coreとインクルードしていく。ファイル名はtarget_xxx.h, chip_xxx.h, core_xxx.h
- Makefileの構成ファイルであるMakefile.xxx も入れ子インクルードによって target -> chip -> coreとインクルードしていく。ファイル名は Makefile.target, Makefile.chip, Makefile.cpu
- ソースファイルは、Makefile.xxx 内部で宣言することでカーネルに組み込む。ファイル名は core_xxx.c, chip_xxx.c, cpu_xxx.h
このような多層化はいくらでもやることができますし、基本的には性能に大した影響を与えません。最近はターゲットをさらにTargetとboardに分けてアプリケーションとボードを分離してやろうかなどと考えることもありますが、我ながらやりすぎです。
さて、実際のターゲット依存部の移植作業では、ほぼ3種類の移植作業が混在していると考えてください。
- TOPPERS/ASPカーネルの規約により要請される変更作業
- 開発環境により要請される変更作業
- チップのハードウエアに合わせて作りこむ変更作業
だいたい移植というとパッと頭に浮かぶのは3．ですが、それぞれ順に概要を説明しましょう。
1．の規約により要請される作業ですが、これは例えばTarget依存部識別マクロ、コンソールへ出力する文字列、依存部の情報を取りまとめたファイル名などがあたります。
Target依存部識別マクロはたとえばTOPPERS_CHIP_LPC1830などというマクロであり、このような識別マクロを使って他の部分をターゲット依存にするようドキュメントにより求められています。したがって、chip_stddefs.hやtarget_stddefs.hで宣言されているこれらのマクロを変更しなければなりません。この変更には一つメリットがあります。TOPPERS/ASP for LPCプロジェクトでは、識別子が未知の場合はビルドエラーが起きるようにしています。そのため、ターゲット依存部において、間違ったマクロ名宣言や、うっかりとした依存部記述ミスによる移植漏れが起きにくい仕掛けになっています。
コンソールに出力する文字列は、オプショナルです。変更しなくても何ら問題なく動きますが、起動時のコンソールに対するメッセージが全然無関係のものになって、カッコ悪いことこの上ないため変更したほうがいいです。
TOPPERS/ASP for LPCは、依存部と同じ名前の宣言ファイルを持ち、レジスタ情報などをそこから読み込むことを要請しています。たとえば、lpc1830.hなどといったファイル名にします。このファイル名は当然のこととして、ターゲットへの移植の度に名前と内容が変わります。
2.の開発ツールの要請によって変更すべき点というのは、考えてみればそれほどおかしなことでもありません。たとえば、メーカー発表のインクルードファイルの名前が変わるなどといった点です。この点は些細であり、まったく負担とはなりません。
3. のチップのハードウェアに合わせて作りこむ作業が、プログラマが考える移植です。たとえば、PLLの制御アルゴリズムは内部クロック周波数の決定、コアのコンフィギュレーションとソフトウェアのすり合わせ、割り込みハンドラの宣言、ピンの機能設定などがこれに当たります。
今回の移植では1,2は基本的に単純作業であり、ソースとコンパイルエラーを見ながら単純置き換えで済む話がほとんどでしたので、手数がかかっただけで、時間は大したことはありません。たぶん1時間くらいです。時間がかかったのは3.でした。
以下、さらに続きます。