I don't recall exactly where the clock frequency was found in the firmware, I may be able to track it down; but not sure when I will have time.
Understood Phil. Thanks.
Having said that, assuming the delay time slips occassionally, then both cameras will occasionally randomly slip at the same time and line up. That would produce a sync'd image. Which means that the number of cases of poor sync might be somewhat less than originally suggested because occasionally both cameras shoot early together.
Sorry if this sounds confusing. What this reduces to is that you can use a single camera to experiment until you always get the same delay after USB release. If you get variations then you will not always get sync between seperate cameras, even though the slips will sometimes align.
Thanks for comment.
I don’t fully understand that. Let me try to pinpoint some meaning by continuing the example with specific numbers that I hope are relevant.
On my A1200, the value is 0 in playback mode, sits at 103 in shooting mode until a half press changes it to 963 while focussing and 209 when focussed.
Say, at switch release, current count is 200 (i.e. within 10 of end of period count) then vnd’s:
while ((*(volatile int*)(GPIO_VSYNC_CURRENT) & 0xffff) >= cur_cnt) {}
loops until GPIO_VSYNC_CURRENT is less than 209 which occurs immediately at the beginning of the subsequent normal count.
vnd’s:
sync_period -= std_period;
calculates the extended period value as 3x209 – (209-200) – 1x209 = 409
vnd now attempts, in this new std period, to apply 409 to GPIO_VSYNC_MAX via:
(volatile int*)(GPIO_VSYNC_MAX) = sync_period; // write the length of the extended period to the register
but says that won’t happen until the end of this new std period, i.e:
0xC0F06000 - write 1 to apply values, the new value is applied at the end of current period, reading 0xC0F06000
So, normally at end of count at:
switch release + 9 + 209
then 409 is written to GPIO_VSYNC_MAX
i.e. 409 will be the maximum count of the next count.
vnd’s:
msleep(40)
then waits for 40ms into the extended period at which point Canon understands the current count is greater than a critical value. My understanding is that, if a critical fixed value is surpassed (it always is at 40ms) shooting occurs immediately at the end of the period following the extended period.
vnd resets this following period to the normal count of 209 via:
*(volatile int*)(GPIO_VSYNC_MAX) = std_period; // back to standard timing on next period
So, from switch release, the shot occurs at the following count quantity:
9 + 209 + 409 + 209 = 836 (i.e. 4 x std periods approx 132ms)
E.g.2
Say, at switch release, current count is 199 (i.e. 1 count before vnd’s 9 of end of period count) then vnd’s code to wait until the next period is skipped :
while ((*(volatile int*)(GPIO_VSYNC_CURRENT) & 0xffff) >= cur_cnt) {} – does not apply
Neither does vnd’s code subtract a std_period from the sync_period. Instead an immediate attempt to write an extended period of:
sync_period = 3x209 – (209-199) = 617
to GPIO_VSYNC_MAX occurs, again, via :
(volatile int*)(GPIO_VSYNC_MAX) = sync_period; // write the length of the extended period to the register.
If that is successful then at:
switch release + 10
the value 617 is written to GPIO_VSYNC_MAX
vnd’s code:
msleep(40)
then waits for 40ms into the extended period at which point Canon understand the current count is greater than a critical value. My understanding is that, if a critical fixed value is surpassed (it always is at 40ms) shooting occurs immediately at the end of the period folowing the extended period.
Vnd’s code reset this following period to the normal count of 209 via:
*(volatile int*)(GPIO_VSYNC_MAX) = std_period; // back to standard timing on next period
So, from switch release, the shot occurs at the following count quantity:
10 + 617 + 209 = 836 ( 4 x std period = 132ms)
My conundrum relates to vnd’s code:
if (std_period - cur_cnt < 10)
If vnd had not included this code to wait (for counts less than 10 from period end) until the beginning of the subsequent std period to attempt to apply an extended count to GPIO_VSYNC_MAX), is a count of 10 from end of period, significantly, any more likely to fail to update GPIO_VSYNC_MAX at the end of the period in which the switch release occurred compared to a count of 9 (or less)?
i.e. if the 10 count from end does not have enough time to have the extended count applied to GPIO_VSYNC_MAX in the count in which the switch release occurs then it seems likely it will be applied at the end of the subsequent std count and that the shot will occur, from switch release, at count:
10 +209 + 617 + 209 = 1045 ( 5 x std period = 165ms)
This does not happen.
If you could describe the circumstances in which a "slip" might happen (just referring to that on one camera) it would be appreciated.
Edit:
Which means that the number of cases of poor sync might be somewhat less than originally suggested because occasionally both cameras shoot early together.
I do get that - but not how both shots could occur at 99ms rather than at 165ms from switch release.