When you start working 24 hours a day, 7 days a week, then feel free to start demanding responses to threads at weekends.
You posted this at 6pm Saturday evening GMT. A private message 11am Sunday morning is an unreasonable demand, and particularly as my sig includes the line "Please don't send PMs asking for support - use the forum.". You then also felt the need to request an update via an unrelated thread.
I may respond to some threads in the evening or over the weekend, but don't take that as any obligation on my part.
Technically forum support isn't even part of my job.
One person so far has ended up on my "foes list" so all their posts get hidden. Be reasonable or you are likely to end up there too.
I see you would probably dont like to see the driver "being abused" for other things
but from what I read I get the expression that it may be usable for me actually... because if I do not use flash there will be no difference on 1st and 2nd frame (preflash) and the AE should meter correctly for such scenario (thinking that the flash is too weak to be noticed at all)? Can you agree with this?
Kozuch wrote:Also regarding general driver operation - once the GPIO pins are set by updating the VideoCore device tree blob than the GPIOs are live regardless of how the camera is used (picamera, raspistill ...)?
Define "live". They'll be configured as outputs so driven high or low based on whatever the driver last told it to do.
Kozuch wrote:Also you say indicator/privacy light GPIO goes on AFTER exposure - do you know more precise timing? Is this same as CAPTURE_STARTED event? Also, can the privacy light be used WITHOUT flash (I suppose so once you enable the indicator GPIO only)?
Yes, privacy light can be used without the flash. It is delayed so that the indiicator doesn't affect the captured frame. IIRC Timing is when the first lines of output have been produced, but I'm not going to bother following the code through.
Kozuch wrote:Before I found this flash driver I was also about to ask about if it is possible to detect the exposure moment from software (meaning raspistill.c)... I see you told sinc about the various MMAL events above - considering this type of detection (besides the flash driver) what is the best precision that can be achieved with these events? I want to go very low (goal is usec level). You say CAPTURE_ENDED has a 30 ms delay - way too long for me. What about using CAPTURE_STARTED with realtime Linux kernel?
usec is crazy resolution. 100mph = 44.7m/s, so even if you're 100ms out you'll be looking at 4.4m. The rolling shutter smears your capture over 66ms, so that's 3m. If you're moving then anything is going to be out. If you're not moving then that level of accuracy doesn't matter.
CAPTURE_STARTED is just after the request is made to the camera pipeline, so probably around 40ms early.
There is no signal that is more accurate. There is something that may help, but it's not a priority so don't pester over it.
Next topic - this one has gone crazy.
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.