Open
Description
Retesting the Camera (GC2145) on the giga with the giga display showed that the zephyr video api changed which required updating the camera library, see PR #135 for changes. After making the changes camera visualizer sketch seems to do nothing, i.e, nothing sent to processing visualizer sketch etc,
Did notice that in debug window:
[00:00:17.789,000] <inf> usb_dc_stm32: PWR not active yet
[00:00:17.911,000] <inf> usb_cdc_acm: Device suspended
[00:00:18.136,000] <inf> usb_cdc_acm: Device configured
[00:00:23.078,000] <wrn> video_stm32_dcmi: HAL_DCMI_ErrorCallback
[00:01:17.598,000] <wrn> shell_uart: RX ring buffer full.
[00:01:17.604,000] <wrn> shell_uart: RX ring buffer full.
which does not show the usual spew when the camera is working.
However if I remove the shield and put camera directly on the giga it works.
Activity
KurtE commentedon Jun 10, 2025
@mjs513, @iabdalkader - and all
Quick note: I have a quick and dirty stripped down version of a sketch to read the camera and output to the display
using GFX...
Most of the time it fails but I do get some frames..
It is up at: https://github.com/KurtE/Arduino_GIGA-stuff/tree/main/sketches/zephyr_giga_display_examples/Zephyr_GigaCameraDisplay_GFX
Most of the time it fails, I have had a few times when it actually reads a frames. I swap the bytes as they are in the wrong
order...
I am wondering if this might be some form of priority issue? Not sure if this version of the camera library is using DMA? Or interrupts. Will look later. Likewise for the display code. Or maybe issue with interrupts or threads priorities?...
Note sure if the thread list helps... but just in case:
I am running using @mjs513 updated version of camera...
mjs513 commentedon Jun 10, 2025
@KurtE - @iabdalkader - and all
I gave your sketch a shot and only once was I able to see more than 1 frame once!. Most of the time I will get 1 frame and then nothing:
Update - now getting streaming video to display after changing pwm1 from 12 to 10Mhz.
Also now getting video to the Processing sketch but it seems to be out of synched
KurtE commentedon Jun 11, 2025
Thanks @mjs513... I have the sketch updated, and I rotated the display and center the image and it works so far as you mentioned using 320x240 camera.
If I try setting the camera 640x480, I don't get any images... Need to see if there is issue with buffer sizing and the like.
So I then added some quick and dirty scale output code And try to output at scale 2.
320x240 output as 640x480 which fits in the 800x480 display. It looks like I get one output and then it fails...
Will look more tomorrow. (The updated sketch is up at the same place...)
iabdalkader commentedon Jun 11, 2025
Yes, the display hogs the bus or the driver disables IRQs for too long, which causes the DCMI to overrun. This is a known issue, I've reported it before. Reducing the clock fixes it as it slows down the camera. Alternatively the DCMI could be restarted when it stops, but that makes frame drops very visible.
Anyway, here's a simplified camera+display sketch for testing.
KurtE commentedon Jun 11, 2025
Thanks @iabdalkader - I just tried this sketch and it appears to work for maybe one frame and then it is hung or simply
not reading or display more frames.
My hacked sketch which I mentioned appears to work OK at 320x240 but not bigger. If I try 640x480 nothing displays.
And I think I am seeing on the printk monitor window messages like:
[00:00:03.146,000] <dbg> video_stm32_dcmi: HAL_DCMI_FrameEventCallback: Failed to get buffer from fifo
If instead I try to use code to print every pixel as a 2x2 rectangle, I get one output and again camera fails to read.
Maybe need to slow it down some more
mjs513 commentedon Jun 11, 2025
@iabdalkader just to add on to what @KurtE said this is what I am seeing in the debug window when trying 640x480
mjs513 commentedon Jun 11, 2025
@KurtE - @iabdalkader
As I just mentioned to Kurt I changed pwm1 to 9mhz and @KurtE sketch is now working with scaling factor of 2
KurtE commentedon Jun 11, 2025
Thanks... I tried 9 and it did several frames before it hung... Or I should say until the if (cam.grabFrame(fb)) {
started failing and the BUILTIN_LED would slowly blink...
iabdalkader commentedon Jun 11, 2025
@KurtE @mjs513 I think the FIFO was just disabled for some reason. Does this patch help?
This makes my sketch above (the only test I run) work fine at 12MHz. Lowering LTDC IRQ (currently 0) is also an option.
KurtE commentedon Jun 11, 2025
Updated to 8mhz and it appears to work a lot longer. I do get some of the messages like:
I tried then with native 640x480... not scaled up... And it fails to show any frames and the Kernel
Edit: @iabdalkader Will try your camera patch and see if that helps... Thanks
mjs513 commentedon Jun 11, 2025
@iabdalkader - @KurtE
Sorry had to run out to get new frames (pun not intentional) for my glasses.
Anyways applied your patch and:
320x240 @12mhz - getting frames and is stable
320x240 @12 mhz with scaleing = 2 - get a couple of frames on display and then freezes.
640x480 @12 mhz - seeing same errors as I saw before.
@10MHZ w/320x240 and scaling set to 2 - several frames now and freezes still.
@8MHz w/320x240 and scaling set to 2 - no issues scaling successful
UPDATE: at 640x480 actually getting frames that out of synch with the patch applied and at 8mhx
mjs513 commentedon Jun 11, 2025
@iabdalkader - @KurtE
Think this issue is has been resolved by adjusting the pwm1 clock. However, think there are still some issues with working with the camera and display. Do you all want to continue it here or make it a discussion?
iabdalkader commentedon Jun 12, 2025
So it does fix that at least.
How do you display 640x480? The display is 480x800, do you rotate the image somehow? Can you share your sketch?
mjs513 commentedon Jun 12, 2025
@iabdalkader
Before getting into the graphics api (Arduino_GraphicsDisplay and Arduino_Graphics_GFX) did find the following
display_set_orientation(display_dev, DISPLAY_ORIENTATION_ROTATED_90);
does not work to rotate screen. Saw that when we were working on the api.Now for the api's. We created a display api and then moded arduino_graphics_gfx (#92 (comment)). You will need those 2 libraries to run the sketch. Note: libs work with both mbed and zephyr used ifdefs as appropriate.
Then sketch we are using to test was set up by @KurtE:
KurtE commentedon Jun 12, 2025
@iabdalkader Morning.... At least here.
As @mjs513 mentioned, We have ported over several of the Arduino libraries associated with the Giga display shield to work with Zephyr. This includes the ones @mjs513 has up in his github account: Arduino_GigaDisplay and Arduino_GigaDisplay_GFX libraries:
https://github.com/mjs513/Arduino_GigaDisplay_GFX/tree/Arduino_GigaDisplay_GFX_zephyr
https://github.com/mjs513/Arduino_GigaDisplay/tree/Arduino_GigaDisplay_Zephyr
Which also has support for the Display LEDs(GigaDisplayRGB)
I have a version of the touch display working:
https://github.com/KurtE/Arduino_GigaDisplayTouch/tree/zephyr
But requires change to ArduinoCore-zephyr: #134
The GFX library (Arduino_GigaDisplay_GFX) has it's own Frame buffer, and the APIs like:
display.drawRGBBitmap - take the rotation into account. So will update the Frame buffer and when it completes this graphic
primitive it will then call off to display_write(this->gdev, x, y, this->buf_desc, buf);
Which as this is a full size buffer, it will simply set it as the new display buffer...
We also added a couple of methods, that would buffer up the changes, until we told it to end it's buffering which would
do the update to use the modified frame buffer. These were used in the sketch that Mike showed in previous post for the
quick and dirty blow up the image by a factor of 2...
Side Note: Would be nice if there were more options with the Zephyr camera support, for different resolutions and display ports, etc.
For example we have a modified version of your Arduino camera library that we did for the Teensy:
https://github.com/mjs513/Teensy_Camera Where we had a lot of resolutions defined, that included the sizes of
several of the displays we used, both rotated and not rotated,,,
Before that I would use a simple adapter board that rotated the camera 90 degrees.
iabdalkader commentedon Jun 12, 2025
Found an easier way to test VGA, I just crop the display buffer:
The performance is terrible, even with 6MHz and restarting DCMI, it's not keeping up. The H7 should be able to read & display ~30FPS VGA, so I'm not sure why it's so slow with Zephyr. Perhaps it's doing a lot of things in the background that disable IRQs, or maybe SDRAM isn't running as fast as possible (though it seems to be correctly configured).
iabdalkader commentedon Jun 14, 2025
This issue is not easily fixable. It boils down to bandwidth contention between the LTDC and DCMI. As soon as you enable the LTDC, it continuously accesses the SDRAM (to refresh the display), which blocks the DCMI, causing it to overrun and stop. If you use the DCMI alone, you can see that it's capable of streaming VGA just fine.
The Zephyr video driver is the main culprit here, as it transfers the frame directly to its buffers (which, in this case, reside in SDRAM). Our driver, on the other hand, uses a temporary SRAM-based buffer to read lines, and then copies those lines to SDRAM using MDMA (if available) or the CPU. This approach allows us to sustain 30+ FPS from DCMI to LTDC with this sensor.
Current solutions:
FWIW, I've checked and tried every conceivable thing (GPIOs, SDRAM timings, PLLs etc..), and tested all of the suggestions in AN4861, but nothing helps. Short of rewriting the Zephyr video driver to follow a similar approach (which also requires patches to the HAL) I don't see another fix. We're probably not going to do that, so I suggest we close this as wontfix, unless @facchinm has other thoughts.
KurtE commentedon Jun 14, 2025
Hi @iabdalkader - That is very unfortunate. Although maybe not much more you can do.
I know that on the MBED version, I believe their example reads in from the camera at 320x240 and then stretches the image
out to probably 640x480, which we can sort of do now with slower clock.
Wondering if this configuration if you get any benefits of using GC2146 over something like OV7675 which is slightly cheaper although $6 versus $9 is not overly significant for one or two of them...
mjs513 commentedon Jun 14, 2025
Yeah agree - but lets wait to see if @facchinm has anything to add to this.
mjs513 commentedon Jun 15, 2025
@iabdalkader - @facchinm - @KurtE
Just hooked up a OV7670 and basically seeing same performance for the GC2145 when running 12Mhz for the OV7640.
A couple of notes. In OV7670 have to change:
to
otherwise you get no images from camera!!!!
With the OV7670 running at 12Mhz and 640x480 resolution with screen rotation 1(landscape) @KurtE's sketch is showing: Avg display Time: 100088 fps:9.99 which is about the same as the GC2145 running at 6Mhz and same resolution!
At 320x240 with scaling= 2: Avg display Time: 50804 fps:19.68