Quote from: philmoz on 09 / November / 2012, 03:12:39In your period_synch.patch file how did you find the address 0x00406014You can find the RAM base address by looking inside the EngDrvOut function (it's exposed as an event procedure).
In your period_synch.patch file how did you find the address 0x00406014
In the example calculation of fps that funnel gave, regA x RegB = 60,000,000.In our example, 0x110 x 0x1215 = 1,259,088 decimal.
The clock frequency in the firmware table on the S95/G12 is 38MHz.
Quote from: Microfunguy on 04 / November / 2012, 09:00:27The synch period is therefore either less than three standard periods or less than two standard periods.By delaying 40 msec we ensure we are in the lower half of either synch period.Yes, correct.
The synch period is therefore either less than three standard periods or less than two standard periods.By delaying 40 msec we ensure we are in the lower half of either synch period.
Quote from: philmoz on 09 / November / 2012, 16:13:38The clock frequency in the firmware table on the S95/G12 is 38MHz.I am not sure where the firmware table is, that is why I asked 'vnd' :-"On 100H, does the code associated with Fldspec.c contain a reference to RAM address 0xA83C and does that contain a pointer to 0xFFC3BEAC ?"
Strange that the standard period varies with lighting level.
If I understand correctly the camera delays shooting until the end of the current live view frame which at 30fps will be every 1/30th of a second.
The line: while (*(volatile int*)(0xC0F06000)) {}; // wait until the new value is appliedwill wait until the start of the next synch period - potentially up to 33ms in a tight spin loop.Now since the camera is already at the start of the synch period the msleep(40) seems redundant to me.
The clock frequency in the firmware table on the S95/G12 is 38MHz.So fps = 38000000 / (0x110 x 0x1215) = 30.18
It is a bit more complicated. If the shooting starts with counter value between 0 and 0xe0, it starts immediately.
msleep(40) waits for the second part of the period when the counter value is higher than 0xe0.
Quote from: philmoz on 09 / November / 2012, 16:50:43If I understand correctly the camera delays shooting until the end of the current live view frame which at 30fps will be every 1/30th of a second.It is a bit more complicated. If the shooting starts with counter value between 0 and 0xe0, it starts immediately. With value between 0xe1 and 0x110 it waits for the next period. 0xe0 is the value of register 0xC0F0713C.I don't know what is the reason for this behavior and if it is the same on other cameras.This also explains why the synch worked well in more than 50% of cases.
Started by Microfunguy CHDK Releases
Started by Blooper « 1 2 » Creative Uses of CHDK
Started by David Ripple « 1 2 ... 6 7 » General Discussion and Assistance
Started by koshy « 1 2 ... 8 9 » General Discussion and Assistance
Started by cameraman Creative Uses of CHDK
