Zephyr - Any display library or examples available?

@ptillisch @pennam @ ...leonardca

I know that @Merlin513 and I had a version of Arduino_GIGADisplay library working with zephyr almost a year ago. I believe that we created a pr for back last August ( Modifications for using with Zephyr by mjs513 · Pull Request #34 · arduino-libraries/Arduino_GigaDisplay )

About a month and a half ago this PR was closed as now being a duplicate of [Add Zephyr support and migrate to Arduino_Video by leonardocavagnis · Pull Request #46 · arduino-libraries/Arduino_GigaDisplay]

Which point to using a new library: Page not found · GitHub
Which is still currently private.

Note: my earlier sketches that displayed on the GIGA display shield are not faulting. I am guessing that the memory management may have changed over the last several months.

Question is, should I spend the time re-debugging our PR to the old library or will there be something released or at least no longer private soon?

Seems like we are now taking a step backwards - what good is it to have a display shield that we have no way to access any more.

Guess real question is when will the new libraries be available for using graphics or video or are we going to be saddled with using lvgl or nothing.

Unless I miss some detail, I don't think it is accurate to say "no way to access any more". The GIGA R1 WiFi board is still supported by the "Arduino Mbed OS Giga Boards" platform, and the GIGA Display Shield supported in combination with that platform by the examples of the Arduino_GigaDisplay library and the related established public open source libraries:

It is great that you both have been contributing to the work to provide support for the GIGA R1 WiFi and other boards by the Zephyr OS-based platform, but it is important to note that the platform is currently in the beta development phase, and Arduino still recommends the use of the Mbed OS-based platforms are still for production use with boards other than UNO Q.

I don't have any information regarding the timeline for publishing the "Arduino_Video" library, and am not involved in the management or development of that project. So unfortunately I am not able to answer this question. Hopefully one of the other Arduino employees who is involved in the project will be able to answer.

@ptillisch
My apologies for coming across a bit strong - think a bit of frustration has been creeping in lately. Understand can still use Mbed OS with the giga.

Hopefully. I know they are working on some other libraries like FDCan that I noticed as well.

Thanks @ptillisch - Just a bit of frustration. And yes I understand that all of these boards under Zephyr are labeled as Beta (feels more at times like Alpha)

I have found at least one issue, with our older PR that was closed in that the RGB format setting has changed, have not fixed it but commented out the code that tries to set it as it looks like we have it set as the default RGB565 in the device tree. Still most of the sketches I had are still failing.

But found at least one that is partially working. Which is my paint program


At least it is drawing and my RGB Led code is setting the color.
The palette is drawing, but so now touch is not working

But maybe good enough to see if I can get my camera image to display code working again... So I can test my PR for deferring the init of the camera after I merged in all of the current changes to defer-init most of the objects. Again sometimes frustrating, on the fact this PR has not been reviewed or the like in like 8 months now. Again why start up the camera and allocate all of the resources if a sketch never actually uses the camera.begin() type call...

Sorry...

Just a quick update. Decided to play with the giga display, however, I am still using our ArduinoGraphics library and our Arduino_GigaDisplay_GFX.h library. One caveat though is that I am using my custom library that uses its only framebuffer configuration.

Display output with camera

Display output with Graphics lib

Camera output to Arducam App:

Haven't tried the Touch stuff yet or looked to see if it still enabled in the core.

Great stuff... @ptillisch sorry I may have overreacted yesterday was just a bit frustrated...

As for Touch figured out the issue. It has to do with the deferred init of the devices.

The zephyr branch of the Arduino_GigaDisplayTouch code needs the stuff init the device and apply the pinctrl:

bool Arduino_GigaDisplayTouch::begin() {
  static const struct device *const dev = DEVICE_DT_GET(DT_CHOSEN(zephyr_touch));
  if (!dev) {
    printk("<ERR> touch DEV null\n");
    return false;
  }
  (void)zephyr::arduino::init_dev_apply_pinctrl(dev);

That still did not work as, at least what I found is that with the current deferred stuff, definition in the ArduinoCore-zephyr Giga overlay with:

&i2c4 {
	status = "okay";
	zephyr,deferred-init;
	gc2145: gc2145@3c {
		compatible = "galaxycore,gc2145";
		reg = <0x3c>;
		zephyr,deferred-init;
		reset-gpios = <&gpiod 4 GPIO_ACTIVE_LOW>;
		pwdn-gpios = <&gpioa 1 GPIO_ACTIVE_LOW>;

		port {
			gc2145_ep_out: endpoint {
				remote-endpoint-label = "dcmi_ep_in";
			};
		};
	};
};

So the I2C4 object is deferred init.

However in the Zephyr boards shields arduino_giga_display_shield overlay for the GIGA it has:

&i2c4 {
	pinctrl-0 = <&i2c4_scl_pb6 &i2c4_sda_ph12>;
	pinctrl-names = "default";
	clock-frequency = <I2C_BITRATE_FAST>;
	status = "okay";

	gt911: gt911@5d {
		compatible = "goodix,gt911";
		reg = <0x5d>;
		alt-addr = <0x14>;
		reset-gpios = <&gpioi 2 GPIO_ACTIVE_LOW>;
		irq-gpios = <&gpioi 1 GPIO_ACTIVE_HIGH>;
	};
};

So gt911 touch controller was not marked as deferred... I added it like:

&i2c4 {
	pinctrl-0 = <&i2c4_scl_pb6 &i2c4_sda_ph12>;
	pinctrl-names = "default";
	clock-frequency = <I2C_BITRATE_FAST>;
	status = "okay";

	gt911: gt911@5d {
		zephyr,deferred-init;
		compatible = "goodix,gt911";
		reg = <0x5d>;
		alt-addr = <0x14>;
		reset-gpios = <&gpioi 2 GPIO_ACTIVE_LOW>;
		irq-gpios = <&gpioi 1 GPIO_ACTIVE_HIGH>;
	};
};

And then it started working again.

Not sure best way to do this. Could repeat the define probably within ArduinoCore-zephyr...

EDIT: I know I should probably create issues and PRs for some of this

@KurtE @Merlin513 we are on it. Both the deferred init issue and the unpublished library.

:smile: Thanks!

@Merlin513 @ptillisch,

Sorry again, I know that the Zephyr board releases are marked as Beta, but I am also most of the time working on the Bleeding Edge of it.

That is with current sources, which I know the risks of doing so. But I also know that if I am trying to contribute new stuff it needs to be tested with current sources and it is probably a good thing to find potential issues and if appropriate resolved before a new release comes out.

Like the current code on the GIGA for using a Camera is broken.
GIGA/Portenta H7 - Camera code with the new deferred init setup... · Issue #491 · arduino/ArduinoCore-zephyr

Two (or Three) main issues.
a) Camera (GC2145) is not marked as defer-init, but the I2C object above it is. And as mentioned in the fix to get the Giga Touch controller to work again, the fix does not scale.

b) If the Camera itself has to be defer-init There is no easy handle in the current code to get it. Also unclear if the DCMI object can startup if the object that it is going to interact with is...

c) PWM pins - The timers and the like are marked as defer-init, the pwmclock is not, but even more than this with the GC2145 object, the Timer pins are not setup for default pin control:

&timers1 {
	status = "okay";
	st,prescaler = <0>;

	pwm1: pwm {
		status = "okay";
		zephyr,deferred-init;
		pinctrl-0 = <>;
		pinctrl-1 = <>;
		pinctrl-2 = <&tim1_ch3_pj9 &tim1_ch1_pk1 &tim1_ch2_pj11>;
		pinctrl-names = "default", "sleep", "arduino";
	};
};

How does one work with that setup? First several attempts failed. I have a hack in now in my test sketch:
analogWrite(57, 64);
And then allow my startup code to still work, however I need to ignore the return code
if ((ret = zephyr::arduino::init_dev_apply_pinctrl(camera_sensor)) != 0) {

Note: for most of this stuff, I earlier tried to make all of the camera stuff to be defer-init, now trying to update that PR (again)?
camera: try to defer init of video objects by KurtE · Pull Request #195 · arduino/ArduinoCore-zephyr

But at least with all of this hacking, I at least have an image up again on the display:

Note: the camera is plugged into the shield through an adapter board I long time ago, to rotate 90 degrees, using it here as I also have connector on the back of it, to allow camera to point the other way, but it allowed me to connect up Logic Analyzer.

Now back to playing (or seeing what else I can break) :wink: