-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Camera interface esp32s3 #75331
Camera interface esp32s3 #75331
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for this driver! I tried to spot a few things that I thought you'd be interested in adjusting. Glad to see more device families part of the Video driver collection.
a705d85
to
3bd5053
Compare
I'm no expert with cameras or the differences between successive generations of esp32's, but is this fundamentally bound to the "s3" version of esp32? Or would it also be compatible with older esp32's as well? |
@ASerbinski The s3 is the only esp32 model with a dedicated video interface. The other esp32 variants use the I2S interface to "emulate" a video interface. Therefore, this driver is only compatible with the esp32s3. |
119a3ec
to
c4e5d10
Compare
Concerning the tests/samples, I can't seem to find your sample code anywhere. I'd really like to contribute with testing, so can you point me in the right direction? |
The best could be to have the upstream examples supported, making modifications to the example only if needed, and using a shield, a bit like how it was done for this OV5640 module. Maybe one way to figure out how to compose the example together would be to add another example here on this PR, just for the sake of publishing the source and reviewing it, even if it is removed afterward... Or just paste the snippets of code/config if there are just a few. Thanks again! |
I made a new commit and added the overlays for the |
Thanks for the reminder, but I already have a working setup with your PRs patched in and been tinkering with it and my own zephyr projects a bit. I'm looking forward to test your code in my spare time! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work! Please check some comments and minor concerns I placed across this patchset
drivers/video/video_esp32_dvp.c
Outdated
} | ||
|
||
if (dma_block_iter->next_block) { | ||
LOG_ERR("Not enough descriptors available. Increase DMA_ESP32_DESCRIPTOR_NUM"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed there is neither irq_unlock, not goto_unlock which may cause irq state conflict.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good spot
LCD_CAM.cam_ctrl.cam_update = 0; | ||
LCD_CAM.cam_ctrl1.cam_start = 1; | ||
|
||
data->is_streaming = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question, is it a must to place a giant lock inside of this function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably not, since the interrupts are inactive when you start the stream any how...
I'll remove it and add a check to make sure we are not already streaming on stream_start().
This commit creates a new node for the lcd_cam interface. It enables the lcd_cam pheripheral clock and adds the possibiliy to controll the camera clock frequency trough the `cam-clk` property. This is its own device for two reasons: 1. It enables to use the camera clock as a standalone clock. 2. It enables to initialize xclk before the sensor driver. Signed-off-by: Armin Kessler <[email protected]>
Adding support for the esp32s3 camera interface. Signed-off-by: Armin Kessler <[email protected]>
Remove the VSync interrupt handle, as DMA captures VSync through the in_suc_eof event. Signed-off-by: Armin Kessler [email protected]
adding xiao_esp32s3 support to video capture sample Signed-off-by: Armin Kessler [email protected]
8a742c3
to
8ebcb45
Compare
The driver now calls the `<hal/cam_hal.h>` API instead of writing directly into the registers. Signed-off-by: Armin Kessler [email protected]
@LucasTambor I've added a new commit to so that the driver now uses the espressif hal instead of writing directly into the registers. |
@@ -0,0 +1,4 @@ | |||
config CLOCK_CONTROL_ESP32_CAM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is wrong, it should default to y and have a "depends on DT_HAS...". See Kconfig files for the other clock control drivers
config CLOCK_CONTROL_ESP32_CAM | ||
bool "master clock for esp32 camera interface" | ||
help | ||
This option enables the pheriphery and cam clock for the lcd_cam module. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Spelling
@@ -0,0 +1,6 @@ | |||
config VIDEO_ESP32S3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto: default y / DT_HAS_...
* SPDX-License-Identifier: Apache-2.0 | ||
*/ | ||
|
||
#define DT_DRV_COMPAT espressif_esp32_cam |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be better to keep driver file name and compatible consistent. Go for either cam or dvp everywhere (I personally prefer cam, I'd say)
CONFIG_VIDEO_ESP32S3=y | ||
CONFIG_VIDEO_BUFFER_POOL_SZ_MAX=40000 | ||
CONFIG_VIDEO_BUFFER_POOL_NUM_MAX=3 | ||
CONFIG_CLOCK_CONTROL_ESP32_CAM=y |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Drop. Not needed when you will have fixed the kconfigs
@@ -0,0 +1,5 @@ | |||
CONFIG_DMA=y | |||
CONFIG_VIDEO_ESP32S3=y |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same
fmt.width = 160; | ||
fmt.height = 120; | ||
fmt.pitch = fmt.width * 2; | ||
fmt.pixelformat = VIDEO_PIX_FMT_RGB565; | ||
|
||
if(video_set_format(video_dev, VIDEO_EP_OUT, &fmt)){ | ||
LOG_ERR("Unable to set format"); | ||
return 0; | ||
} | ||
|
||
printk("- Set format: %c%c%c%c %ux%u\n", (char)fmt.pixelformat, | ||
(char)(fmt.pixelformat >> 8), (char)(fmt.pixelformat >> 16), | ||
(char)(fmt.pixelformat >> 24), fmt.width, fmt.height); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just a workaround to be able to fit the captured frame into internal ram.
It should and will be removed once #76982 is merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I see. But since this impacts (negatively) users using other drivers, I would not consider this workaround acceptable. If you wanted, I guess you could add Kconfigs to the sample to allow setting a max resolution though, and based on the supported resolutions you get from the call to video_get_capabilities you could set to whatever resolutions is the closest?
int ret = 0; | ||
|
||
if (0 == cam_clk) { | ||
LCD_CAM.cam_ctrl.cam_clk_sel = |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you use HAL API here as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I left a comment in the hal/cam PR.
@@ -0,0 +1,6 @@ | |||
config VIDEO_ESP32S3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use just VIDEO_ESP32
, it's more generic for later SoCs
Thanks for all the reviews. |
Since @LucasTambor took over this at #77709 and #77879 I close this PR |
Pull Request Summary
This pull request introduces video capturing functionality for the ESP32-S3 LCD_CAM interface.
To use this feature, you must first merge pull request #74974.It depends on the hal espressif being merged and added to the zephyr manifest.
Alternatively drop the last commit so the driver writes directly into the registers and skipping the hal.
Using the xiao_esp32s3 board and the OV2640 camera sensor, I successfully captured low resolution images in RGB565 format.
Open Topics for Discussion
Although the driver is functional, several topics need further discussion:
1. Using External Memory
Due to issues with memory reallocation on the ESP32-S3, testing was limited to internal memory, requiring the imager to be set to the lowest resolution (160x120px).#76982 enables to choose the video buffer location and to put it into to external ram. This enables this driver also to capture high resolution images.
2. ESP32-HAL
Currently, the driver directly writes to the LCD_CAM register values using the SOC register structs.It may be more appropriate to move these calls to the hal_espressif.
3. Devicetree structure:
The LCD_CAM module involves four different devices (cam-clk, lcd-clk, lcd-interface, cam-interface).
Initially, I attempted to combine the cam-clk and cam-interface into one device and set the cam-clk rate based on a devicetree property.
This approach failed because the cam-interface references the sensor (OV2640) in the device tree, requiring the sensor to be initialized before the cam-interface, which isn't possible without first initializing the camera clock.
A proposed structure is:
However, this might be overly complex, especially since espressif,esp32-lcd_cam would only enable the peripheral without much additional functionality.
If you have a better idea or see an alternative way to implement this, please leave a comment!
4. Testing
I have some tests locally that only run on the xiao_esp32s3 with the ov2640 sensor. I could add them to the zephyr test folder but I don't know where to place them exactly.It would also be nice to add support for the
sample/subsys/video/
samples.This PR adds an overlay for the
xiao_esp32s3
to thesamples/drivers/video/capture/
.