Arduino Zephyr - from 50 thousand feet - How do you envision it working?

[KurtE]

@facchinm @pillo79 @mjs513 and all

Sorry, it may be just me, but I still don't understand Arduino’s goals, on what a released version of the Arduino boards on Zephyr
will look like.

It might really help if there was a writeup somewhere maybe part of the wiki that might explain the goals and a
general idea of what releases might look like. I know bits and pieces of this have been talked about in several different places but it would be great to have some top-level understanding.

My guess is a lot of this is still in flux and may take several iterations of alpha/beta releases before things fully solidify. But I still think it would be helpful to at least get a general idea of what your current thought are.

On general goals, things like:
a) How compatible should the Zephyr versions be to the current releases (MBed, Renesas, etc.) to the MBED. Things like Pin name/numbers, devices (Wire, SPI, SerialX, etc)

b) How much will the typical users need to know about Zephyr? Device Trees? On the same line, will a high percentage of users need to install from sources: ArduinoCore-zephyr, Zephyr, and all the parts it pulls in? Will this be necessary in order to configure and use the different devices and the like that are part of Zephyr? Like How would I use an OV7675 camera on the GIGA?

c) Do you believe that a reasonable percentage of developers will develop for the Arduino boards directly using the Zephyr setup? That is doing west build and west flash? If so, what things should we be migrating out of the ArduinoCore-zephyr cores/variants should be migrated down lower into the zephyr sources. Things like overlays?

d) How do you plan to setup for Boards alone versus boards that have a shield or carrier board. Like Giga with or without Giga Display Shield. Portenta alone or on a Carrier: Breakout, Hat, Mid, … In both cases with or without Cameras? For example, do you
expect that The GIGA Display Shield will stay as a Zephyr Shield? Likewise, for Portenta boards? An Arduino Variant for each of these configurations?

e) Will there be options for a user to define their own overlay and config files as part of an Arduino build? I would assume not, but...

f) How to use Multiple cores?

...
Thanks
Kurt

[josuah]

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 run dtc (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.

[KurtE]

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