boards: seeed: Add support for XIAO ESP32S3 Sense

[pblxptr]

The Seeed Studio XIAO ESP32S3 Sense board is a board based on the XIAO ESP32S3 board with a soldered B2B connector that allows to connect extension board with a camera sensor, microphone and the sdcard slot.

Tested by executing samples/drivers/video/capture with some modifications needed to save an image on the sdcard.

Btw. sorry for the typo in the source branch name, but there is no way to change the source branch once the PR has been created.

[pblxptr]

Kindly asking - is anyone going to have a look at this?

[rhvarrier]

Great work. I was looking forward for this feature as well. However I see that you have used the generic zephyr, camera driver while there is a specific one for Espressif boards espressif,esp32-lcd-cam
What is the difference between these drivers?

[pblxptr]

Great work. I was looking forward for this feature as well. However I see that you have used the generic zephyr, camera driver while there is a specific one for Espressif boards espressif,esp32-lcd-cam What is the difference between these drivers?

I'm not sure what do you mean by generic zephyr,camera, could you elaborate on this?
I think that you confuse chosen node "zephyr,camera" with the driver that in fact is being used here.

As you can see in boards/seeed/xiao_esp32s3/seeed_xiao_connector.dtsi
xiao_sense_lcd_cam: &lcd_cam {};

xia_sense_lcd_cam points to lcd_cam which is defined here: https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/xtensa/espressif/esp32s3/esp32s3_common.dtsi
and if you have a look at this you'll see this:

lcd_cam: lcd_cam@60041000 {
	compatible = "espressif,esp32-lcd-cam";
	reg = <0x60041000 DT_SIZE_K(4)>;
	clocks = <&rtc ESP32_LCD_CAM_MODULE>;
	interrupts = <LCD_CAM_INTR_SOURCE IRQ_DEFAULT_PRIORITY 0>;
	interrupt-parent = <&intc>;
	status = "disabled";
};

which as you can see ueses espressif,esp32-lcd-cam that was recently added to zephyr.

[henrikbrixandersen]

I decided to add this board as a shield instead of a new board, as this is the same as the already supported XIAO ESP32S3 except for the fact that this one has a B2B connector soldered whereas the non-sense board (although in fact it has traces on the PCB) does not contain B2B connector soldered on the PCB.

This approach allows to reuse most of the config and device-tree files with a small modifications needed to enable shield overlay. Any other opinions especially why it would be better to deliver this as a separate board are welcome, I can easily convert this to board instead of shield if there is a good reason to do this.

Thank you for working on this! I have this board, and would love to see support for it in Zephyr.

I think this should just be a variant of the existing XIAO ESP32S3 board, placed in the same folder. This too allows reusing the base devicetree files etc. between the two variants without the "overhead" of adding a board-specific shield.

[pblxptr]

I decided to add this board as a shield instead of a new board, as this is the same as the already supported XIAO ESP32S3 except for the fact that this one has a B2B connector soldered whereas the non-sense board (although in fact it has traces on the PCB) does not contain B2B connector soldered on the PCB.
This approach allows to reuse most of the config and device-tree files with a small modifications needed to enable shield overlay. Any other opinions especially why it would be better to deliver this as a separate board are welcome, I can easily convert this to board instead of shield if there is a good reason to do this.

Thank you for working on this! I have this board, and would love to see support for it in Zephyr.

I think this should just be a variant of the existing XIAO ESP32S3 board, placed in the same folder. This too allows reusing the base devicetree files etc. between the two variants without the "overhead" of adding a board-specific shield.

Hi, thanks, will explore this and rework the solution.

// EDIT
Done.
Seems that PR label still points to "Shields", perhaps somebody could change it.

[josuah]

FYI: There need to be at least 2 reviews before Kartben being able to merge it.
You could ask extra reviews on the #pr-help Discord channel.

In this case, the _sense variant only adds features, so mechanisms like this might still work:

If both the common plank_defconfig file and one or more board qualifiers specific plank_<qualifiers>_defconfig files exist, then all matching files will be used. This allows you to place configuration which is common for all board SoCs, CPU clusters, and board variants in the base plank_defconfig and only place the adjustments specific for a given SoC or board variant in the plank_<qualifiers>_defconfig. -- doc

I am a bit confused, but having a "no-variant variant" is actually how it is done in Zephyr, like the Raspberry Pi Pico (rpi_pico_defconfig) vs Rasberry Pi Pico W (rpi_pico_rp2040_w_defconfig).

Still, to help users discovering that if they order the XIAO ESP32S3, they would get a missing connector, some documentation changes could help.

Many thanks for porting this very compact computer vision capable board!

[uLipe]

Besides on @josuah comments, LGTM so far.

[henrikbrixandersen]

One minor nit, rest looks good!

[ngphibang]

The source device can be retrieved from the remote-endpoint-label (you can see aea820d) so no need to do direct reference via phandle here. This is just a recommendation, perhaps for next time.

[ngphibang]

We should also use the video-interfaces binding in the lcd-cam yaml. If not, declaring remote-endpoint-label or remote-endpoint or anything else will not have any effect (although it still compiles).

I am not sure which is the binding yaml file of the lcd_cam. Is it espressif,esp32-lcd-cam.yaml ? If so, by using the video-interfaces binding, you can also avoid declaring a number of vendor customized DVP properties for example, data-width, hsync, vsync, etc.

This can be addressed next time.