軽く挫折
TOPPERS/ASP for LPCXpresso1768 アプリケーション用のスケルトンをLPCXpresso用に作ろうとしていたのですが、今日、挫折しました。軽い方向転換が必要です。以下、まとめ
最初の構想
最初に考えたのはこういうディレクトリ構造でした。
- app0
- kernel
- cmsis
- app1
- kernel
- cmsis
- app2
- kernel
- cmsis
つまり、スケルトンにcmsisとkernelのサブディレクトリをもたせる方式です。この方法はわりと簡単に動かすことができたのですが、大問題がありました。
まず、あまりにもソースが大きくなりすぎることです。なんといってもcmsisのソースが巨大すぎて、リビルドするたびにとんでもない時間がかかります。アプリケーションのclean/buildのたびにこんな時間をとられてはたまりません。
また、アプリケーションごとにコピーをもたせるデメリットもあります。
２番目の構想
次に、構造を維持したままライブラリ化をすることを考えました。
- app0
- kernel
- cmsis
- app1
- kernel
- cmsis
- app2
- kernel
- cmsis
kernelとcmsisサブディレクトリには、インクルード・ファイルとアーカイブ(.a)だけを置くことで、リビルドの時間を大幅に短縮できます。
しかし、libcmsis.aはあいかわらず巨大です。もっぱらの理由はdsplibがもつ係数データが膨大であることです。使用しなければリンク時に消えてしまいますがちょっと不愉快です。
また、バイナリ・ファイルである.aを配布するのもちょっと考えてしまう点です。特に、カーネルに関しては構成を変えて試験したいことが多いので、libkernel.aをサブディレクトリに置くのはいい方法じゃありません。LPCXpressoでは、一つのプロジェクトの中でライブラリとアプリケーションを作り分けることはできません。毎回外部でリビルドする面倒くささがあります。
3番目の構想
次に考えたのは以下のように、cmsisとkernelを独立したライブラリ・プロジェクトとして作り、アプリケーションから外部のlibkernel.a, libcmsis.aを参照する方式です。
- app0
- app1
- app2
- kernel
- cmsis
これはうまくいくかのように思えたのです。しかし、うまくいかないことがわかりました。これはTOPPERS/ASPカーネルに問題があります。ASPカーネルのパッケージはその名前と裏腹に、カーネルに加えてシリアル・サービス・タスクをもっています。これは大変便利なのですが、不可避的にカーネルをライブラリ化する場合にはタスクIDを生成する必要があります。タスクIDはアプリケーションに固有です。
つまり、TOPPERS/ASPの枠組みではアプリケーションに共通のlibkernel.aを作ることはできないのです。
大幅に手を入れればそれも可能になるかもしれませんが、保守性が悪すぎるため避けたいところです。
今後どうするのか
今考えているのはこんな感じです。
- app0
- kernel
- app1
- kernel
- app2
- kernel
- cmsis
かっこわるいことこの上ありませんし、途中でkernelに変更を入れると全アプリケーションに変更を加えることになります。しかし、各アプリケーションのファイルの数と、コンフィギュレーションの容易さを考えると、このあたりがうまい落としどころに思えます。
なお、それぞれのアプリケーションをマネージド・プロジェクトにするかmakefileプロジェクトにするかは考えどころです。
マネージド・プロジェクトの場合、Debug/Relesaeのコントロールが簡単です。
Makefileプロジェクトの場合、libkernelによるビルドの高速化を望めます。
