Jumping from#153

On Linux, Kconfig is there to change the code, and the devicetree is only a binary configuration file that does not require rebuilding the kernel, but only rundtc (devicetree compiler). Zephyr makes the distinction blurry as both are used at build-time.

Implementing boot-time modification without recompiling Zephyr... is not easy, as Zephyr drivers are currently compiled with the configuration hardcoded in the driver C code via C macros. Sometimes it does not affect performance, sometimes it does. Long term challenge in Zephyr.

Another approach to make this smoother is improve the build environment on all platforms, which is probably a WIP.

Thanks@josuah,

It will be interesting to see what approaches Arduino might take to do some of this.

For example, I can imagine creating multiple board variants for each board: For example the GIGA. There could be one
for with Giga Display shield and another one without. There could be variants for each of the supported cameras. But then
the combinations between the two grows exponentially. So probably not viable.

Or maybe Arduino, can somehow set it up, where they run the whole equivalent of: west build, and maybe the sketch allows you
to define an overlay and config file... Maybe libraries as well? Not sure how viable or desired that is...

For the Camera stuff that@mjs513 and I have been playing with, I have been tempted to attempt a different tactic, and that is to
try to extract most of the camera specific stuff out of the main Zephyr build. Sort of like generate the equivalent of the
Arducam_dvp library. Where maybe in the zephyr build for GIGA and Portenta H7 is something like the video_stm32_dcmi.c code.

That allows a class object to register at it at init time, with either a jump table or potential a c++ class... And then have all of the
camera stuff compiled into the sketch... Don't know how well that would work. I know that might break some of the zephyr
model, but would it make it a lot easier to test stuff in the Arduino world.... This is sort of like SPI, where in the Arduino Setup
we have the SPI objects defined for each of the busses, and then in the Arduino Wrapper, we have code that enumerates all
of these and creates C++ objects for them and then SPI devices write their code using these, versus define all of the SPI
objects we use into the device tree...

In the mean time I have been doing a lot of my own playing and testing directly building directly with Zephyr. I am still
learning my way around. Also not sure how much of the Arduino stuff to add into my own building blocks... Like I now
have two of the display drivers I have been using on zephyr (and mbed) ported over. But in doing that should I then add
in the Arduino Pin enumerations and SPI enumerations. Currently I have it hacked in like:

&spi2 {status = "okay";pinctrl-0 = <&spi2_sck_pi1     &spi2_miso_pc2 &spi2_mosi_pc3>;pinctrl-names = "default";/* added for sketch */generic_tft_spi_dev: generic_tft_spi_dev@0 {status = "okay";compatible = "vnd,spi-device";reg = <0>;spi-max-frequency = <30000000>;};};

Where I query for this object and then can get the SPI object. But then how to get the other three IO pins associated with it
CS, DC, Reset? CS I can probably add that into the SPI2 object, but have not done that yet. Instead using a different hack:

zephyr,user {generic_tft-gpios = <&gpioj 11 GPIO_ACTIVE_HIGH>,/* CS D2 */<&gpioc 7 GPIO_ACTIVE_HIGH>,/* DC D4 */<&gpiog 7 GPIO_ACTIVE_HIGH>;/* RST D3 *//* <&gpio1 30 GPIO_ACTIVE_LOW>;touch cs Pin 26 */};

And knowing that the first item is CS, second DC and third reset, and at times maybe a 4th for touch support...
It has been a learning experience, but now I can make changes to the settings and the like and get back to trying to stuff
out a lot quicker.

Thanks again
Kurt