PTP and other tasks. - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: [1] 2   Go Down

PTP and other tasks.

  • 10 Replies
  • 4293 Views
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
PTP and other tasks.
« on: 25 / September / 2011, 06:49:25 »
Advertisements
In PTP, when a request for data has been received does the camera have to
respond within a certain time ?

If so, and it does not, would you expect it to simply send an error response
rather than crash ?

For other CHDK tasks, do all operations have to be completed within 10 msecs
?

If they do not complete, is the state of the task saved or does it start
again from the beginning ?

In the latter case, I guess you have to split the operation into phases and
save the phase number in a static local variable.


David
Logged
*

Offline waterwingz

  • ******
  • 12092
    • Waterwingz
Re: PTP and other tasks.
« Reply #1 on: 25 / September / 2011, 10:06:15 »
Quote from: Microfunguy on 25 / September / 2011, 06:49:25
In PTP, when a request for data has been received does the camera have to respond within a certain time ?

If so, and it does not, would you expect it to simply send an error response rather than crash ?

For other CHDK tasks, do all operations have to be completed within 10 msecs ?

If they do not complete, is the state of the task saved or does it start again from the beginning ?

In the latter case, I guess you have to split the operation into phases and save the phase number in a static local variable.

Can't answer the PTP question but from what I've seen the error handling is not very robust in the curent CHDK implemenation. 

As to your other question, as far as I can tell there is no general "requirement" for CHDK talks (or any DryOS task) to finish in 10 mSec.   However,  if a task hogs the system for longer than that, it tends to slow down everything else such that buttons and the display start becoming unresponsive.   So good programming practice in any "non-preemptive" OS is to structure your code so that you can periodically yield and resume later.

I have read on the forum that there may be a hardware watchdog timer on at least some cameras, but I don't know how long a task can hog the system before the watchdog kicks in and resets the camera.

Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: PTP and other tasks.
« Reply #2 on: 25 / September / 2011, 10:14:13 »
Quote from: waterwingz on 25 / September / 2011, 10:06:15
good programming practice in any "non-preemptive" OS

So, which of the following is VxWorks/Dryos ? :-

http://www.keil.com/support/man/docs/rlarm/rlarm_ar_schedopt.htm

On another application, I wonder if it is possible to delay the start of the movie task in an attempt to bring two cameras into synch ?
« Last Edit: 25 / September / 2011, 10:16:55 by Microfunguy »
Logged
*

Offline waterwingz

  • ******
  • 12092
    • Waterwingz
Re: PTP and other tasks.
« Reply #3 on: 25 / September / 2011, 10:54:20 »
Quote from: Microfunguy on 25 / September / 2011, 10:14:13
So, which of the following is VxWorks/Dryos ? :-
http://www.keil.com/support/man/docs/rlarm/rlarm_ar_schedopt.htm
Based on that link, I'd say its closest to Cooperative Mulit-Tasking.  However, DryOS tasks can have different prioities - that decides who goes next when the current task yields.   (FWIW : this is just my understanding - i could be wrong)

Quote
On another application, I wonder if it is possible to delay the start of the movie task in an attempt to bring two cameras into synch ?
Should be -  except the movie task starts when the camera does.  I think what you want is to delay recording once the shutter button is pressed ? So how would you communicate a synchronization signal between the two cameras ?  Or would you just want a user selectable delay and let someone play with that until its "good enough" (e.g. when you are using two different cameras that take much different amounts of time to begin recording ) ?

Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: PTP and other tasks.
« Reply #4 on: 25 / September / 2011, 11:06:28 »
Quote from: waterwingz on 25 / September / 2011, 10:54:20
the movie task starts when the camera does.

In theory, if the cameras are powered-up at the same time the system clocks should be in close synch.
A test by someone suggests they are not (but 'same time' may be difficult to achieve).

Another option is to momentarily change the clock frequency of whichever of three timers the movie task is driven from.
It is certainly possible to do that generally, it depends if the clock used by movie task will permit it.
It is assumed that comparing the time-difference of the field-synch pulses on A/V output gives an indication of synch.
This has not been proven yet.

Regarding my original question, I am off to do some tests .....
Logged
*

Offline reyalp

  • ******
  • 13456
Re: PTP and other tasks.
« Reply #5 on: 25 / September / 2011, 16:40:05 »
Quote from: Microfunguy on 25 / September / 2011, 06:49:25
In PTP, when a request for data has been received does the camera have to
respond within a certain time ?
Probably. The old implementation of lua return values (before I implemented the message system) would block until the script ended and this caused issues if they ran too long. IIRC the camera should shut down with an assert, but I"m not sure.

Quote
For other CHDK tasks, do all operations have to be completed within 10 msecs
?
No. There is no hard limit.

Quote
If they do not complete, is the state of the task saved or does it start
again from the beginning ?
If they do not yield (with msleep or a similar function), then they just keep running. Possibly an interrupt could result in a context switch if a higher priority task becomes ready to run. Eventually you will run into problems because some task critical to the OS didn't get enough CPU cycles. Tasks never spontaneously restart at the beginning, the only thing that starts a task at the beginning is CreateTask.

Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 13456
Re: PTP and other tasks.
« Reply #6 on: 25 / September / 2011, 16:44:26 »
Quote from: Microfunguy on 25 / September / 2011, 11:06:28
Quote from: waterwingz on 25 / September / 2011, 10:54:20
the movie task starts when the camera does.

In theory, if the cameras are powered-up at the same time the system clocks should be in close synch.
Not really, especially if you are loading a binary from SD card, as in CHDK. The startup behavior even on a single camera is no-deterministic (think about the startup file handle bug, you can start 3 times in a row, crash in two of them and successfully start on the third, without changing any data on the camera)

In any case, the start time of the task isn't going to help you synchronize recording.
Logged
Don't forget what the H stands for.
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: PTP and other tasks.
« Reply #7 on: 25 / September / 2011, 18:33:12 »

Quote from: Microfunguy on 25 / September / 2011, 11:06:28

In theory, if the cameras are powered-up at the same time the system clocks should be in close synch.

Not really

Are you saying that startup of the clocks is not a purely electronic function but is  determined by a software enable ?

Logged
*

Offline reyalp

  • ******
  • 13456
Re: PTP and other tasks.
« Reply #8 on: 25 / September / 2011, 18:52:46 »
Quote from: Microfunguy on 25 / September / 2011, 18:33:12
Are you saying that startup of the clocks is not a purely electronic function but is  determined by a software enable ?
I'm not sure which clocks you are referring to (have you actually identified them ? How ?), but I would expect most of the hardware is configured by software at boot time.
Logged
Don't forget what the H stands for.
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: PTP and other tasks.
« Reply #9 on: 25 / September / 2011, 19:32:28 »
Quote from: reyalp on 25 / September / 2011, 18:52:46

I'm not sure which clocks you are referring to

I am hoping it is one of the three clocks that we know there are firmware functions for changing frequency.

Quote
have you actually identified them ?

Not yet.

Quote
How ?

I will look at the frame-synch pulses on the A/V output and see how they are affected by a software change of frequency.

I agree that the boot process must set the working parameters of a number of chips.
It depends if the relevant oscillator just starts up and then software changes its properties or its startup is actually enabled by software.

It is the great unsolved problem of stereo movie shooting with affordable cameras.
Logged
Pages: [1] 2   Go Up
« previous next »
 

Related Topics