Except AWB and AGC are not run on the OV5647, they are run on the Broadcom ISP. So what is the OV5647 going to try and do to AGC during the flash images?
And on capture the Broadcom code is almost always going to stop and restart the sensor. It then expects the first frame to be corrupt (as it normally is), but if the OV5647 has dropped the frame, the first frame isn't corrupt, and the Broadcom code will drop the wanted frame. So that mechanism would need reworking.
This is why I have passed the issue over to the community.
If and only if someone comes up with a
proven workable register set, then I will investigate further and look at integrating it. Just reciting chunks from the datasheet is not sufficient.
There is already the GPIO based flash driver (
viewtopic.php?f=43&t=83484) which will almost provide what you want. It will assert a GPIO for the duration of the drop frame and the required frame (mainly as the GPU doesn't have accurate information as to when exposure starts), and drops it when the frame end occurs for the wanted frame. [1]
(Just looking at figure 4-10 of the OV datasheet, it almost looks like in LED 1 and LED2 the strobe line is set for LESS than the full exposure time - it comes on as the last line starts exposing, and goes off as the first line starts readout. Either that is a badly drawn diagram, or don't go trying to do flash captures with an exposure time less than the readout time. More fun things for the community to check out!)
[1] It also does a preflash to calibrate the AGC and flash power (should the flash driver have intensity control, which this doesn't) that will give a pulse on the GPIO, though I may look into whether I can shift that to an extra GPIO so that the main capture flash is on a unique GPIO.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.