Add opt-in CMakeLists.txt exporting a dotbot_libs INTERFACE target

[geonnave]

Summary

First step toward CMake + gcc-arm-none-eabi support in dotbot-libs. Adds a top-level CMakeLists.txt exporting a dotbot_libs INTERFACE target that downstream CMake projects can consume:

add_subdirectory(/path/to/dotbot-libs dotbot-libs-build)

add_executable(my_app ...)
target_link_libraries(my_app PRIVATE dotbot_libs)
target_compile_definitions(my_app PRIVATE NRF5340_XXAA NRF_APPLICATION BOARD_DOTBOT_V3)

Strictly additive. Existing SES .emProject projects continue to work unchanged — no source file moved, no build flag set globally. Only consumers that opt into CMake see this target.

Why INTERFACE + target_sources instead of STATIC

dotbot-libs source files behave differently per consumer — most notably bsp/gpio.h flips between NRF_P0_S and NRF_P0_NS based on NRF_TRUSTZONE_NONSECURE. A single STATIC library compiled once can't serve both bare and TrustZone-non-secure apps in the same build. INTERFACE + target_sources lets each consumer compile the same sources under its own define set, which matters when a project mixes both modes (e.g., a CMake-based version of swarmit-firmware would have a secure bootloader and a non-secure sandbox app side by side).

Scope of this first cut

Only sources that have been validated under gcc-arm-none-eabi for nRF5340 app core (via the proto-dotbot-firmware prototype, against real DotBot v3 hardware):

• bsp/nrf/: board.c, gpio.c, pwm.c, timer.c
• drv/: motors/motors.c, rgbled/rgbled.c

Subsequent PRs (separate, smaller, easier to review) will add:

• Per-chip variants (lh2_default vs lh2_nrf5340_net, radio_default vs radio_nrf5340_app)
• More drivers: control_loop, lh2, hdlc, imu, sensors
• nRF52840 / nRF52833 build support
• The vendored crypto/nrf_cc310/ blob

Consumer responsibilities

Documented in the CMakeLists.txt header comment:

• Cross-compiling toolchain (gcc-arm-none-eabi recommended; the prototype uses Homebrew's gcc-arm-embedded cask on macOS).
• Nordic MDK device headers + ARM CMSIS-Core on the include path. Easy path: FetchContent NordicSemiconductor/nrfx (use mdk/) and ARM-software/CMSIS_5 (use CMSIS/Core/Include).
• Board/chip/TrustZone-mode defines.
• Startup code, linker script, Reset_Handler.

Validated

Three CMake targets in the proto-dotbot-firmware prototype have been switched from hand-listing dotbot-libs sources to target_link_libraries(... dotbot_libs), rebuilt cleanly:

dotbot_bare    text=2900  data=24  bss=8280   (was 2900/24/8280 before — byte-cost-neutral)
dotbot_sandbox text=2912  data=24  bss=8280

The sandbox build correctly inherits NRF_TRUSTZONE_NONSECURE from its own target — same dotbot-libs sources compile differently per consumer, which is exactly the property INTERFACE buys us.

[geonnave]

Closing this for now as premature, just as other cmake PRs of last week.