Single Hardware / Multiple Binaries

[TorstenRobitzki]

Hi,
we would love to create multiple binaries for the same hardware / hardware configuration. The purpose of this, is that we factor out all hardware decencies and test our code against hardware mocks. We try to have the hardware layer as thin as reasonable possible. To test the hardware layers, we use different binaries that run on the same hardware as the final firmware, but contains just one hardware layer (driver) and some interface, that allows to interact with the hardware layer.

I was surprised, that Zephyr is not exposed as a CMake library target, that could be used to link against, but that one has to add sources to a given library. But maybe, there is such a target, that I could use in different executable targets to link against? If not, is there a Zephyr way to have multiple binaries for the same board?

The only solution, I can currently think of, is to have a build parameter and have a lot of if/else in the cmake files to collect different source and then to have multiple builds.

best regards
Torsten

[dbaluta]

Why would you like to have multiple binaries instead a single binary and select the hardware based on the dts? Managing the multiple binaries would be a nightmare.

[nextsilicon-itay-bookstein]

The idea here is having multiple different firmware executables that one wants to load onto the CPU/board at different times. All these firmware executables are different applications that all share the same compiler settings, are comprised of the same code libraries, but do different things. For instance, one firmware could be for running some specific tests. Another could be the production firmware. Another could be a debug-enabled firmware into which a lot of extra tracing functionality was compiled / linked.

CMake abstractions natively support these scenarios within the same cmake invocation (so, same compiler/platform/global compiler tuning flags, etc) - you use libraries and executables, and you can link the same library into multiple executables. The build is incremental, and libraries shared between different executables are simply linked into each rather than rebuilt from scratch.

If the Zephyr build system code is written in such a way that a CMake invocation can only ever produce a single firmware executable, this precludes these use-cases.

[TorstenRobitzki]

Well, the hardware is the same for all the binaries, I want to build. So the dts is the very same for all of them.

With "normal" CMake, managing multiple binaries, is as simple, as adding add_executable to a CMakeLists.txt file and to add some dependencies to that new target. That's why I'm so surprised by the way Zephyr is using CMake.

Let's assume, I have some software, that interacts with a UART. This part of the software has just a dependency to that UART and is complex enough to being worth to have a lot of unit tests. I can factor out the UART, provide an interface to the software under test, write a mock for the hardware and can create every behavior I want to have for the UART. Probable even behavior which would be extremely hard to create in reality (like data arriving in unusual blocks, data outside of frames, backpressure from hardware handshakes etc.).

Now, I'm certain, that the software, that is interacting with the UART is correct. What is missing now, is the UART driver itself. For that, I would like to have a binary for the target hardware, that I can use to interact with the driver itself.

Does that makes sense to you?

[nordicjm]

use the unit_testing board

[TorstenRobitzki]

Hi Jamie,
thanks for your response. Can you elaborate on your answer? For "simple" unit tests, I just use CMake/CTest/Catch2. That's pretty straight forward and is not hampered by Zephyr. So, that is not an issue.

Now, I need a way to build some extra binaries for the target platform (nrf53 in our current case), with the exact hardware as the final firmware will run on. But with (for example) some UART interface, that would allow me to trigger (for example) the blinking of an LED to see that the very thin LED driver is working as expected.

best regards,
Torsten

[TorstenRobitzki]

As a workaround, I collect all firmware targets and then, use a function to conditionally add sources to a target:

register_embedded_firmware_target(usb_cdc_test)

target_sources_for(spi.cpp firmware)
target_sources_for(external_pin.cpp firmware)
target_sources_for(usb_cdc.cpp firmware)
target_sources_for(usb_cdc.cpp usb_cdc_test)

Where firmware is the "usual" firmware for the target hardware and usb_cdc_test is small test program to be run on the target hardware, but that only tries to software-test the usb_cdc driver.

To build either the firmware or the usb_cdc_test, a CMake cache variable has to be set and the Zephyrs one and only executable target will be build.

[TorstenRobitzki]

Well, I wrote two CMake functions (target_sources_for and register_embedded_firmware_target), which basically do what CMakes add_executable and target_sources do. This, then allows me to build different firmware binary targets. Of cause, I have to run this in multiple builds, switching between targets (by setting a CMake cache variable).

This is just a workaround. CMake has all that is required to build multiple binaries and to share common code among the binaries. Unfortunately, Zephyr is not linked in as a library, but is the one and only binary.

[zakimoo]

Hi @TorstenRobitzki,
Do you have this workaround some where on github?
Best regards

[TorstenRobitzki]

No, sorry.

[zakimoo]

@TorstenRobitzki would you mind sharing your implementation
please

[TorstenRobitzki]

Sorry, but it's a customers project and I'm not able to share that. But it's really not that hard. But in the end, I think we all would love to see that Zephyr plays well with CMake, which by default allows as much executable targets as you like.