Well it seems to work with the following line commented out*(volatile int*)(GPIO_VSYNC_MAX) = std_period; // back to standard timing on next period
And syncs quite nicely, with an average error of about 0.1ms, no greater than 0.3ms. As it is with the other cameras, so I'd say this problem is solved.
Should I expect any weird behavior if that address isn't set back to normal after each shot? It appears to work fine though. Was that line really even necessary, or just as a precaution?
Did you leave this line in ? *(volatile int*)(GPIO_VSYNC_MAX) = sync_period; // write the length of the extended period to the registerIt's writing to the same address.
void _wait_until_remote_button_is_released(void){ int tick; if ( ( conf.remote_enable ) // menu : USB remote enabled - bracket everything in this function && ( conf.synch_enable ) // menu : Sync enabled - tells us to wait for USB to disconnect && ( usb_sync_wait ) ) // only sync when USB remote is active - don't trap normal shooting { usb_remote_status_led(1); // indicate to user we are waiting for remote button to release - this happens every time the camera takes a picture tick = get_tick_count(); // timestamp so we don't hang here forever if something goes wrong int std_period = _EngDrvRead(GPIO_VSYNC_MAX); int sync_time = std_period * 3; // schedule the end of extended period at t = t(synch pulse) + sync_time do { } while( get_usb_bit() && ((int)get_tick_count()-tick < DELAY_TIMEOUT)); int cur_cnt = *(volatile int*)(GPIO_VSYNC_CURRENT) & 0xffff; // get the counter state at the time of sync int sync_period = sync_time - (std_period - cur_cnt); if (std_period - cur_cnt < 10) { // too close to overflow, wait for the next period sync_period -= std_period; while ((*(volatile int*)(GPIO_VSYNC_CURRENT) & 0xffff) >= cur_cnt) {}; } *(volatile int*)(GPIO_VSYNC_MAX) = sync_period; // write the length of the extended period to the register *(volatile int*)(GPIO_VSYNC_UPDATE) = 1; while (*(volatile int*)(GPIO_VSYNC_UPDATE)) {}; // wait until the new value is applied //now we are at the beginning of extended period// *(volatile int*)(GPIO_VSYNC_MAX) = std_period; // back to standard timing on next period *(volatile int*)(GPIO_VSYNC_UPDATE) = 1; msleep(40); sync_counter++ ; usb_sync_wait = 0 ; usb_remote_status_led(0); // alert the user that we are all done}}
How did you measure this? And what does it look like without the precision sync patch when measured the same way?
Yes - from what I understand about how this works, you will have changed the video sync timing. But you are probably not pointed at the right register. It is definitely needed.
did you end up trying the precision sync code with the S110 yet?
A friend of mine has just tested it.38% of shots are 1/40,000 second or less.100% of shots are 1/1400 second or less.Median value is 1/23,000 second.These are typical results for recent cameras.
So is the problem just isolated to me and my two S110's then?
Also, as the value at this address (on both the S110 and SX40) goes back to zero after the shot,
int std_period = _EngDrvRead(GPIO_VSYNC_MAX);
BTW, I just remembered that there is already another thread about using the precision sync on the S110. mr.burns, if you're reading this, did you end up trying the precision sync code with the S110 yet?
how do I enable / disable precision sync for my S110?
Started by ledelectronics Script Writing
Started by yasop General Discussion and Assistance
Started by endo3 Creative Uses of CHDK
Started by pigeonhill Feature Requests
Started by Stuart_H General Help and Assistance on using CHDK stable releases
