私のシナリオは Arduino Due (ARM ターゲット) へのクロスコンパイルに関するものですが、これは一般的な C の弱いシンボルの問題だと思います。
ファームウェアを 3 つの部分に分けたい: 1. ハードウェア ライブラリ (CMSIS、ミドルウェア) -> libHardware.a 2. リアルタイム OS ライブラリ -> libOS.a 3. アプリケーション コード -> 上記にリンクされている Output.elf
参照されている CMSIS 実装では、次のことが宣言されています。
void SysTick_Handler ( void ) __attribute__ ((weak, alias("Dummy_Handler")));
// ...and a few dozen IRQ handler hook skipped for brevity
CMSIS 設計の考え方は、IRQ の一部を選択的に実装および処理するアプリケーション コードを持たせることです。
libHardware.a の nm レポート
startup_sam3xa.o:
00000000 W SysTick_Handler
...
私のシナリオでは、これらの IRQ ハンドラーを libOS.a に実装したいと考えています。
void SysTick_Handler(void) を実装し、nm レポート:
cortex_handlers.o:
00000000 T SysTick_Handler
....
次に、それらをリンクします。これは基本的に次のようになります。
g++ -o app.elf -Wl,--start-group app.o libHardware.a libOS.a -Wl,--end-group
(OS は低レベルのハードウェア関数に依存するため、グループ化が必要です。ハードウェアは、OS によって提供される IRQ/main() 関数を呼び出す必要があります)
nm レポート:
...
00080124 W SysTick_Handler
...
まだまだ弱い！libOS.a で定義されているストロング シンボルを使用していると思われます。最後に、SysTick は処理されず、もちろん壊滅的な障害につながります。
一方、libHardware/startup_sam3xa.c で弱いと宣言しなければ、すべて正常に動作します。app/app.c に SysTick_Handler を実装することを選択した場合、それも強くリンクされます。
私の質問は、libHardware.a で定義された弱いハンドラーを libOS.a がどのように実装できるかということです。または、これらのファームウェア開発シナリオでのベスト プラクティスは何でしょうか?