Hello, any idea what could be the issue here? It just doesn’t recognise that a sensor is connected
Hi, the camera driver is not enabled on the board.
You can fork our github, enable github actions for it to be built in the cloud, and enable the camera module here: https://github.com/openmv/openmv/blob/master/src/omv/boards/ARDUINO_GIGA/omv_boardconfig.h#L50
Can you post a link to the product?
1 Like
Thank you, I will try to do this.
The product I am using is Overview | Adafruit OV5640 Camera Breakout | Adafruit Learning System
Mmm, it may make sense to enable that for the board. Can you send a PR with that bit flipped to 1?
Thanks!
1 Like
So I have changed it to 1 and added the clock settings that were not defined, copying them from openmv 4 cam, as I believe the clock should be changed after the divider is applied which happens at the beggining. However the software still does not recoginze the camera. Apart from enabling ov5640 for it to compile I had to add the lines;
#define OMV_OV5640_XCLK_FREQ (24000000)
#define OMV_OV5640_PLL_CTRL2 (0x64)
#define OMV_OV5640_PLL_CTRL3 (0x13)
#define OMV_OV5640_REV_Y_CHECK (1)
#define OMV_OV5640_REV_Y_FREQ (25000000)
#define OMV_OV5640_REV_Y_CTRL2 (0x54)
#define OMV_OV5640_REV_Y_CTRL3 (0x13)
The Portenta H7 has the same hardware clock freqs as the giga. The camera should work on it:
Please copy from it’s settings.
I’ll give it a try soon. Do I only need to copy over the settings with ov5640 in name, or something else too?
The Giga runs at full 480MHz, so the closest board is OpenMV4-Plus not the Portenta. We don’t have this OV breakout to test it, there’s not much else we can do, if it works let us know and I’ll enable it.
1 Like
I have tried openmv4 one but unfortunately it didn’t work.
In terms of ov5640 breakouts, there also seems to be a second option, waveshare ov5640 board.
I’ll let you know if I figure it out and please let me know if you have any updates too.
Like I said there’s not much we can do. Have you checked the pinout and made sure it’s compatible ? Can you try an i2c bus scan maybe this breakout is hardwired to use a different I2C address ? Can’t remember if the OV5640 could do that, but some of the sensor support it. Also seems to mention internal/external clock option with a bridge, I’d make sure the internal OSC is disabled.
I will try to do so. I have also ordered https://www.amazon.co.uk/gp/r.html?C=139N1T2SKF371&K=2NALFGS9WUFYX&M=urn:rtn:msg:2023112008135954ca60910d1b4e95b1791b328790p0eu&R=22PNO5HUMVVI5&T=C&U=https%3A%2F%2Fwww.amazon.co.uk%2Fdp%2FB078MLQ5RN%2Fref%3Dpe_27063361_485629781_TE_item&H=QPZEFFCAFJ0A4KNCA0AUGDKHZLSA&ref_=pe_27063361_485629781_TE_item
To test out if this one works, and since it has auto focus which seems like a nice feature. But it’s gonna take a week or so for it to arrive so can’t test it out yet.
Different i2c address would certainly explain this, so I’ll definitely have a look.
In terms of clock its external rn, and the pinout seems correct
Hello,
Great news,
I just received the module from waveshare and it gets recognised and works very well!! I’ll soon be submitting a pull request with the support added.
Hello, I am sending a pull request that I confirmed works;
One small issue I have noticed is a very occasional stutter but I am not sure what causes this.
However apart from that it works very well.
After saving to board this stopped happening on board side but still happened on the computer side. However it doesn’t happen on board side with grayscale, it’s weird, possibly a vsync issue, however I think this is not giga specific and the pull request is safe to let through
That may be a memory bandwidth issue.
We are pushing the STM32 harder than ST envisioned. You have camera in, lcd out, and JPEG compression all happening at the same time using SDRAM. So, the screen maybe having issues is because of fifo underflows when it’s updating the display.
I found a partial fix if you edit the firmware to relocate the screen buffer to its own SDRAM bank… but, it doesn’t 100% solve the issue but reduces it greatly. To do this though requires wasting 2MB of memory to fix buffer alignments. I can show you the line of code to change to do this if you want.
…
If you see it in the computer display it’s not the above issue I just mentioned. FIFO underflows only affect the lcd screen. The jpeg images sent to the PC should be perfect.
I can indeed see it on the PC - more than on the screen, I will test with OV7670 again today if it’s camera specific.
Interestingly enough the OpemMV4-Plus settings made it fully stutter with artefacts over screen and the speed clearly not matching.
Mmm, it’s probably memory bandwidth. I don’t have the giga, only the pure thermal, it has more memory bandwidth so the camera side of things always captures images without issues. However, there’s nothing stopping camera data capture from hitting bandwidth issues too.
To checkout what happens if you move the screen to different memory bank:
Add fb_alloc(2*1024*1024, FB_ALLOC_CACHE_ALIGN);
After this line: https://github.com/openmv/openmv/blob/master/src/omv/ports/stm32/modules/py_display.c#L339
This will push the lcd frame buffer into another sdram bank.
1 Like
Hello, I tried this but unfortunately, there’s still occasional stuttering, though only on display side now not on my computer.
Using Interupt sensor.snapshot surprisingly didn’t help.
Further, this unfortunately also happens with lower resolutions so it won’t be that.