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

testing sync among more cameras

  • 121 Replies
  • 54700 Views
*

Offline waterwingz

  • ******
  • 12138
    • Waterwingz
Re: testing sync among more cameras
« Reply #10 on: 15 / July / 2012, 09:13:45 »
Advertisements
Quote from: Microfunguy on 15 / July / 2012, 09:06:21
For the sake of putting it on the record, I can post more details if you wish.
As I did a little playing around with this (testing whether hooking into exp_drive_task rather than capt_seq_task would work better) I would be quite interested in seeing what else had been tried.  I know philmoz mentioned that he went down the code tree a bit too.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline reyalp

  • ******
  • 14003
Re: testing sync among more cameras
« Reply #11 on: 15 / July / 2012, 14:46:25 »
Quote from: waterwingz on 15 / July / 2012, 09:13:45
Quote from: Microfunguy on 15 / July / 2012, 09:06:21
For the sake of putting it on the record, I can post more details if you wish.
As I did a little playing around with this (testing whether hooking into exp_drive_task rather than capt_seq_task would work better) I would be quite interested in seeing what else had been tried.  I know philmoz mentioned that he went down the code tree a bit too.
You could try disabling interrupts for the wait. Doing this for a long time is probably not a good idea ;)

Alternately, as I suggested earlier on IRC, a possible approach would be to work backward from something that happens closer to actual moment of shooting. My suggestion was OpenMechaShutter, although I'm not 100% sure the mechanical shutter in P&S really is necessarily very close. In D10, the OpenMechaShutter eventproc is a thin wrapper that calls another function in MechaShutterDriver_c (sub_FF9295F8). There is at least one code path which calls this from capt_seq_task (via sub_FF863540).
Logged
Don't forget what the H stands for.
*

Offline waterwingz

  • ******
  • 12138
    • Waterwingz
Re: testing sync among more cameras
« Reply #12 on: 15 / July / 2012, 15:15:46 »
Quote from: reyalp on 15 / July / 2012, 14:46:25
You could try disabling interrupts for the wait. Doing this for a long time is probably not a good idea ;)
Do you know if that is as simple as a single ARM instruction or is there some fancy interrupt controller that needs to be stroked ?
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline reyalp

  • ******
  • 14003
Re: testing sync among more cameras
« Reply #13 on: 15 / July / 2012, 16:08:58 »
Quote from: waterwingz on 15 / July / 2012, 15:15:46
Quote from: reyalp on 15 / July / 2012, 14:46:25
You could try disabling interrupts for the wait. Doing this for a long time is probably not a good idea ;)
Do you know if that is as simple as a single ARM instruction or is there some fancy interrupt controller that needs to be stroked ?
See A2.5 Program status registers, A4.1.38 MRS, A4.1.39 MSR in ARM Architecture Reference Manual

From D10
Code: [Select]
disable
MRS     R1, CPSR
AND     R0, R1, #0x80
ORR     R1, R1, #0x80
MSR     CPSR_cf, R1

restore
MRS     R1, CPSR
BIC     R1, R1, #0x80
AND     R0, R0, #0x80
ORR     R1, R1, R0
MSR     CPSR_cf, R1
Note that disable returns the previous status, and restore expects that value in r0.

The last time I dug around the shutter stuff I thought I ran into something I interpreted as a reference to high precision timers, but I can't seem to find it now.

edit to add:
IMO, playing with interrupts is probably not going to be a productive approach. Working backwards from the actual shooting event and moving the wait as close a possible to that seems like a better approach.
« Last Edit: 15 / July / 2012, 16:25:39 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline waterwingz

  • ******
  • 12138
    • Waterwingz
Re: testing sync among more cameras
« Reply #14 on: 15 / July / 2012, 16:24:28 »
Quote from: reyalp on 15 / July / 2012, 16:08:58
The last time I dug around the shutter stuff I thought I ran into something I interpreted as a reference to high precision timers, but I can't seem to find it now.
Has anyone figured out if DryOS tasks run at different priorities ?  Bumping capt_seq_task might help narrow the range of sync variation if so.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline reyalp

  • ******
  • 14003
Re: testing sync among more cameras
« Reply #15 on: 15 / July / 2012, 16:30:00 »
Quote from: waterwingz on 15 / July / 2012, 16:24:28
Quote from: reyalp on 15 / July / 2012, 16:08:58
The last time I dug around the shutter stuff I thought I ran into something I interpreted as a reference to high precision timers, but I can't seem to find it now.
Has anyone figured out if DryOS tasks run at different priorities ?  Bumping capt_seq_task might help narrow the range of sync variation if so.
Priority is a parameter to createtask, but having it run at higher priority all the time is likely to have side effects.

You could try twiddling the TCB (used in the "task hook" routine, structure found in includes/dryos*.h)

Or search for "change a priority of task" which will lead you to the dryos shell command that does this.
Logged
Don't forget what the H stands for.
*

Offline waterwingz

  • ******
  • 12138
    • Waterwingz
Re: testing sync among more cameras
« Reply #16 on: 15 / July / 2012, 17:05:48 »
Quote from: reyalp on 15 / July / 2012, 16:30:00
Priority is a parameter to createtask, but having it run at higher priority all the time is likely to have side effects.

You could try twiddling the TCB (used in the "task hook" routine, structure found in includes/dryos*.h)

Or search for "change a priority of task" which will lead you to the dryos shell command that does this.
It would be nice to know if the sync variability was an issue with capt_seq_task not seeing the USB remote voltage release fast enough or if its a question of the downstream processing taking a variable amount of time.  Experimenting with interrupt disable might answer that.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: testing sync among more cameras
« Reply #17 on: 15 / July / 2012, 17:23:00 »
The above interrupt code looks familiar.
I think it is at the 'dead end' that I reached.
The capture seemed to be 'outside' any code that I had followed deeper and deeper.
I will post the details when I can.

Who decided the priority for the CHDK tasks or are they just the same as Canon assign for same task ?

Logged
*

Offline waterwingz

  • ******
  • 12138
    • Waterwingz
Re: testing sync among more cameras
« Reply #18 on: 15 / July / 2012, 17:33:04 »
Quote from: Microfunguy on 15 / July / 2012, 17:23:00
Who decided the priority for the CHDK tasks or are they just the same as Canon assign for same task ?
Unlike the stack setup, I don't believe I've seen any code that changes the defaults.
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline reyalp

  • ******
  • 14003
Re: testing sync among more cameras
« Reply #19 on: 15 / July / 2012, 18:08:31 »
Quote from: Microfunguy on 15 / July / 2012, 17:23:00
Who decided the priority for the CHDK tasks or are they just the same as Canon assign for same task ?
For replaced tasks, they are the same. Spytask is 0x19, which is higher (lower priority) than PhySw and captseq (0x17), no idea how the original value arrived at, but presumably to keep it from starving important ones.

Using  chdkptp (on cams with uart redirection and native call enabled build) you can get a list of tasks and priorities like this
Code: [Select]
=require('uartr').start('A/TEST.LOG')
=return call_event_proc('ShowAllTaskInfo')
=require('uartr').stop()
d TEST.LOG

Previous related discussion
http://chdk.setepontos.com/index.php?topic=6617.msg70113#msg70113
http://chdk.setepontos.com/index.php?topic=6879.msg73439#msg73439

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.

edit:
here's task lists from d10 in playback and record mode, both with PTP connected
« Last Edit: 15 / July / 2012, 18:24:03 by reyalp »
Logged
Don't forget what the H stands for.
Pages: 1 [2] 3 4 5 6 7 ... 13   Go Up
« previous next »
 

Related Topics