testing sync among more cameras - page 3 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 2 [3] 4 5 6 7 8 ... 13   Go Down

testing sync among more cameras

  • 121 Replies
  • 54686 Views
*

Offline waterwingz

  • ******
  • 12138
    • Waterwingz
Re: testing sync among more cameras
« Reply #20 on: 15 / July / 2012, 18:21:19 »
Advertisements
Quote from: reyalp on 15 / July / 2012, 18:08:31
I know I did some testing related to those posts, but now I'm wonder if my methodology was flawed. From memory (I don't seem to have kept notes, or lost them, bad reyalp  :() I came to the conclusion that scheduling was not normally preemptive: that is, if you put a task in a tight loop, no other task will run. However, it's possible I was doing this in startup before regular scheduling was set up.

I did some testing more recently which seemed to imply context switches to physw task even when spytask wasn't yielding.
The code in dev for sync delay is a tight set of loops - no system calls.  When I set the delay to the max value ( 9 secs) I could see my blinker task still flashing the power switch LED on my G10  (which was why I added the blinker task during debugging originally).

So my vote is that things are context switching without the cooperation of the individual tasks.

Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: testing sync among more cameras
« Reply #21 on: 15 / July / 2012, 18:47:32 »
It is late and I cannot access the USB drive that has the disassembled code  for SX230HS 101b until tomorrow.
For now, take my word that testing took us to address sub_FF002EEC.

I said this to the tester  :-

"Before we go any further please explain exactly what you did with the code  at  sub_FF002EEC and did the camera shoot or not."

He replied :-

Code: [Select]
asm volatile(
" STMFD SP!, {R4-R6,LR}\n"
" MOV R6, R1\n"
" BICS R1, R2, #4\n"
" MOV R5, R2\n"
" BEQ loc_FF002F08\n"
//" MOVL R0, 0xFFFFFFFF\n"
"           MVN   R0, #0\n"                      //MOVL
" LDMFD SP!, {R4-R6,PC}\n"
"loc_FF002F08:\n"
" MRS R4, CPSR\n"
" ORR R1, R4, #0x80\n"
if i put wait code here, camera doesn't shoot until switch  released.

Code: [Select]
" MSR CPSR_c, R1\n"

if i put wait code here, camera shoots without switch  released.

Code: [Select]
" BL sub_FF007340\n"
" CMP R0, #0\n"
" MSREQ CPSR_c, R4\n"
" BEQ sub_FF002F00\n"
" MOV R2, R5\n"
" MOV R1, R6\n"
" BL sub_FF0074F8\n"
" MSR CPSR_c, R4\n"
" MOV R0, #0\n"
" LDMFD SP!, {R4-R6,PC}\n"
);
}
« Last Edit: 15 / July / 2012, 18:50:40 by Microfunguy »
Logged
*

Offline reyalp

  • ******
  • 14003
Re: testing sync among more cameras
« Reply #22 on: 15 / July / 2012, 19:23:30 »
If I'm reading this correctly the MSR CPSR_c, R1 is masking interrupts. This suggests that the USB bit doesn't update when interrupts are disabled.

edit:
Or... something like that. hmm.

edit:
Thinking about this a bit more, it shouldn't be a big surprise if the USB power generates an interrupt. This should be fairly easy to verify, make the wait for usb code disable interrupts and see whether it still works.

Assuming it does, the one approach would be to look for an MMIO that reflects the USB power state. Investigating the interrupt handler might shed light on this. Investigating _kbd_read_keys_r2 might also be productive.

It would also raise the question of whether older cams do it this way. My guess is not, because it appears many of them get the entire physw_status state direct from MMIOs. Again, it wouldn't be surprising if the older (slower) USB controllers on these cams were less sophisticated.

edit:
One further thought. If the above is correct (don't bet on it!), then hacking a hardware remote in place of one of the simple MMIO based switches might offer a solution. E.g. replace the battery door switch with a remote wire, masking the original function in software.
« Last Edit: 16 / July / 2012, 01:13:42 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline Alarik

  • **
  • 83
Re: testing sync among more cameras
« Reply #23 on: 17 / July / 2012, 06:26:11 »
I made a long test session and published the results (that may be interesting to see)
it shows difference between shots taken with or without script, at differente shutter speed.
We used CHDK build 1950.
We also tried SDM but it was impossible for us to sync the flash...

http://www.experience-3.com/PROJECTS/timefly/neorTest.html

Logged
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: testing sync among more cameras
« Reply #24 on: 17 / July / 2012, 17:29:49 »
Quote from: Alarik on 17 / July / 2012, 06:26:11

We also tried SDM but it was impossible for us to sync the flash...

SDM flash sync is very good.

Anyway, use CHDK.
Logged
*

Offline vnd

  • *
  • 36
Re: testing sync among more cameras
« Reply #25 on: 23 / October / 2012, 05:14:43 »
Hi,

I tried to log what happens in taskCreateHook (which is something like a context switch hook, according to http://chdk.setepontos.com/index.php?topic=6262.0) after end of wait_until_remote_button_is_released().

This is what I got from 1s exposure:
Code: [Select]
_ImageSensorTask
SsgMainTask
_ImageSensorTask
SsgMainTask
SsgPeriodTask
SsgMainTask
TgTask
SsgMainTask
_ImageSensorTask
CaptSeqTask
ISMainTask
ISComTask
ISMainTask
PhySw
ShutterSoundTask
ISComTask
ShutterSoundTask
ISComTask
ShutterSoundTask
ISComTask
ShutterSoundTask
ISComTask
ShutterSoundTask
PhySw
CtrlSrv
PhySw
CtrlSrv
PhySw
CtrlSrv
ISComTask
CtrlSrv
ISComTask
CtrlSrv
ISComTask
CtrlSrv
ISComTask
CtrlSrv
SsgMainTask
CtrlSrv
SsgPeriodTask
SsgMainTask
CtrlSrv
ISComTask
CtrlSrv
ISComTask
ISMainTask
ShutterSoundTask
CtrlSrv
PhySw

It seems that increasing priority of CaptSeqTask will not help because the real work is done in other tasks.

But the SsgPeriodTask or TgTask look promissing. They seem to be started for each shot (at least they do not appear in ShowAllTaskInfo called over ptp) so it should be easy to hook the sync code at the beginning. Does anybody have some idea what these tasks do?

Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: testing sync among more cameras
« Reply #26 on: 23 / October / 2012, 08:15:18 »
Quote from: vnd on 23 / October / 2012, 05:14:43
I tried to log what happens in taskCreateHook (which is something like a context switch hook, according to http://chdk.setepontos.com/index.php?topic=6262.0) after end of wait_until_remote_button_is_released().

This is what I got from 1s exposure
Try to record timestamps (tick count) too, including the time when wait_until_remote_button_is_released() finishes.

Quote
But the SsgPeriodTask or TgTask look promissing. They seem to be started for each shot (at least they do not appear in ShowAllTaskInfo called over ptp) so it should be easy to hook the sync code at the beginning. Does anybody have some idea what these tasks do?
SSG and TG are both related to sensor timing. When a still image is captured, the sensor is switched from continuous scan to another operating mode, and then back when the exposure(s) is/are finished.
Logged
*

Offline vnd

  • *
  • 36
Re: testing sync among more cameras
« Reply #27 on: 23 / October / 2012, 16:56:09 »
I have added timestamps and found that I had logged only the beginning.

Here is the complete log. Exposure time is 1s, log lasts 2s.
Logged
*

Offline vnd

  • *
  • 36
Re: testing sync among more cameras
« Reply #28 on: 23 / October / 2012, 17:04:59 »
And it seems that it is possible to move the wait_until_remote_button_is_released() call directly to taskCreateHook. For S95 100h the code looks like this:

Code: [Select]
void taskCreateHook(int *p)
{
        p-=17;

        if (p[0] == 0xFF88322C)
                p[0] = (int) capt_seq_task;

        if (p[0] == 0xFF98642C)
                p[0] = (int) movie_record_task;

        if (p[0] == 0xFF8A0AA0)
                p[0] = (int) init_file_modules_task;

        if (p[0] == 0xFF8CF1A8)
                p[0] = (int) exp_drv_task;

        if (p[0] == 0xFF865894)
                p[0] = (int) JogDial_task_my;

        if (strcmp((char *) p[6], "TgTask") == 0)
                _wait_until_remote_button_is_released();
}

At the moment I can't test it with CRT, so I don't know how it helps with sync.
Logged
*

Offline waterwingz

  • ******
  • 12138
    • Waterwingz
Re: testing sync among more cameras
« Reply #29 on: 23 / October / 2012, 18:55:39 »
Quote from: vnd on 23 / October / 2012, 17:04:59
And it seems that it is possible to move the wait_until_remote_button_is_released() call directly to taskCreateHook. For S95 100h the code looks like this:
<snip>
At the moment I can't test it with CRT, so I don't know how it helps with sync.

@microfunguy :  its this something you could try with your setup ?  Possibley using one of the newer cameras with "lousy" sync.  I can probably patch the assembler files for you if they don't follow the task hook convention that vnd is using.

Logged
Ported :   A1200    SD940   G10    Powershot N    G16
Pages: 1 2 [3] 4 5 6 7 8 ... 13   Go Up
« previous next »
 

Related Topics