Closed pcppcp closed 6 years ago
Hi @pcppcp ! Could you please tell me more about this requirement? Do you want test beyond the gtest?
Hi @devtodev! There are some board-specific things (like LEDs) that are not available if building for the QEMU. The goal is to support building both targets.
This will need some research as I still don't know how hardware abstraction layer works in Zephyr. The solution might be simple or it can take couple of days to understand how to create virtual hardware overlay.
But if you want to play with the Zephyr build system the issue #49 is also very important (no testing is required ATM, it should just verify that the firmware compiles for NRF52x)
Great, sounds like a nice challenge. So the idea is keep the Zephyr RTOS and make a hardware abstraction layer to build the Zephyr App to x86 and ARM processors.
For now, the BUILD_XCOMPILE parameter is the condition to add and compile the Zephyr App, but for this requirement for one way or another the Zephyr always will be added. The only thing will be out if BUILD_XCOMPILE are defined is the tests.
I will research it and search a design pattern to implement it. All the advices are good receiving!
Hi! I've kind-a fixed this one: see PR #71
BUILD_XCOMPILE
tells cmake to use zephyr build system. What I've added is just a simple conditional that adds -DBUILD_QEMU=1
to cflags if $BOARD
is set to qemu.
haha ok! I compiled and run well to DBOARD=qemu_x86, when I execute ninja run, booting the app in the qemu-system-i386 so..
For what I read, Zephyr manage the hardware hierarchy in linking time. But... I still have the question about pin and UART mapping between different architectures. I will researching...
Our build is at the moment specific to nRF52x board. It would be nice to have a generic build that can be tested on the local machine.
main.c
so it is usable with both-DBOARD=qemu_x86
and-DBOARD=nrf52840_pca10056