PTP and other tasks.

  • 10 Replies
  • 1220 Views
  • Publish
    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

  • Publish
    Re: PTP and other tasks.
    « Reply #1 on: 25 / September / 2011, 10:06:15 »
    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.


  • Publish
    Re: PTP and other tasks.
    « Reply #2 on: 25 / September / 2011, 10:14:13 »
    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 »

  • Publish
    Re: PTP and other tasks.
    « Reply #3 on: 25 / September / 2011, 10:54:20 »
    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 ) ?



  • Publish
    Re: PTP and other tasks.
    « Reply #4 on: 25 / September / 2011, 11:06:28 »
    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 .....

    *

    Offline reyalp

    • ******
    • 9957
  • Publish
    Re: PTP and other tasks.
    « Reply #5 on: 25 / September / 2011, 16:40:05 »
    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.

    Don't forget what the H stands for.

    *

    Offline reyalp

    • ******
    • 9957
  • Publish
    Re: PTP and other tasks.
    « Reply #6 on: 25 / September / 2011, 16:44:26 »
    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.
    Don't forget what the H stands for.

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


    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 ?



    *

    Offline reyalp

    • ******
    • 9957
  • Publish
    Re: PTP and other tasks.
    « Reply #8 on: 25 / September / 2011, 18:52:46 »
    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.
    Don't forget what the H stands for.

  • Publish
    Re: PTP and other tasks.
    « Reply #9 on: 25 / September / 2011, 19:32:28 »

    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.

     

    Related Topics