supplierdeeply

The \core\kbd.c\kbd_process() function

  • 14 Replies
  • 2737 Views
Re: The \core\kbd.c\kbd_process() function
« Reply #10 on: 08 / July / 2011, 16:32:22 »
Advertisements
I'm not sure the current code actually has a mode that fires as soon as the USB signal goes high ?
No, it is only in SDM.

Quote
anything "we" do should consider the "gent" devices - the have some very nice toys - especially for kite photography.

Yes, this was developed with them : http://www.gentles.ltd.uk/clickpan/sdm.htm

Re: The \core\kbd.c\kbd_process() function
« Reply #11 on: 09 / July / 2011, 14:11:12 »
So where does this go from here ?    Should we attempt to agree on what CHDK remote should support in the way of devices and functions and then delete the current code and implement something more understandable and maintainable ?  I think that getting agreement on what to do might be harder than the actual coding (I'll code it if nobody else volunteers although I think either philmoz or reyalp would do a better job faster).

How about this for a start :

1) move the Remote Parameters menus out from under the  scripting menu into its own menu under the root menu (or Extra Photo Operations or Miscellaneous Stuff)
2) decide if we need the synchable stuff ?  is this really only useful for SDM ?
3) decide on shooting modes (menu selectable) :  I think we need :
     i)  one pulse mode - half shoot on application of 5V USB power,  full shoot on removal of 5V USB power
    ii)  two pulse mode - half shoot on first 5V USB power pulse,  full shoot on second 5V USB power pulse (pulse width configurable ?)
   iii) remote zoom ?>  (how does that work)
4) pick devices that will be supported (menu selectable) :
   i) homebrew 5V USB power via a switch (or commercial versions of the same)
   ii) Ricoh switch unit
   iii)  gentle device(s)  - which ?
      (I'll think about buying whatever we decide on - or see if gentle's will lend us a used unit for development ?)

I suppose we need to think about backwards compatibility.  Fixing the old code seems dangerous.  We could leave it in the way it is, add new code and then add a setup parameter to tell CHDK which code to use (old mode / new mode).  Or just change it a see if anybody cares.  

Other thoughts ?


« Last Edit: 09 / July / 2011, 14:13:16 by waterwingz »
Ported :   A1200    SD940   G10    Powershot N    G16

Re: The \core\kbd.c\kbd_process() function
« Reply #12 on: 09 / July / 2011, 16:16:43 »
   iii)  gentle device(s)  - which ?
      (I'll think about buying whatever we decide on - or see if gentle's will lend us a used unit for development ?)

There is no need to do anything.
The fact that USB pulse-width is measured in \platform\kbd.c is sufficient :-

http://www.gentles.ltd.uk/gentwire/chdk_sdm/index.htm

*

Offline reyalp

  • ******
  • 11514
Re: The \core\kbd.c\kbd_process() function
« Reply #13 on: 09 / July / 2011, 16:27:04 »
So where does this go from here ?    Should we attempt to agree on what CHDK remote should support in the way of devices and functions and then delete the current code and implement something more understandable and maintainable ?  I think that getting agreement on what to do might be harder than the actual coding (I'll code it if nobody else volunteers although I think either philmoz or reyalp would do a better job faster).
I don't have the time at the moment.

Quote
1) move the Remote Parameters menus out from under the  scripting menu into its own menu under the root menu (or Extra Photo Operations or Miscellaneous Stuff)
It currently appears in two places - under script and Miscellaneous stuff. This may depend on some confusing #ifdefs...
Quote
2) decide if we need the synchable stuff ?  is this really only useful for SDM ?
There is no reason CHDK shouldn't support this, but if no one is actually using it there's no need to keep it. Ditto if it doesn't actually work.

It might be worth looking into starting from the current SDM code.

The "synchable remote" setting right now is a the conf.ricoh_ca1_mode setting, which is (if I understand correctly) is not directly tied to the wait_until_remote_button_is_released stuff that lets you fire with predictable delay (although that has it's own cases for ricoh_ca1)

As an aside, it would be neat to give wait_until_remote_button_is_released to the ability to wait for other conditions too. Specifically, to shoot on a particular tick of the tick counter, set earlier by script or code. This would allow shooting via PTP with a repeatable delay, and also continuous shooting intervalometer discussed here http://chdk.setepontos.com/index.php?topic=6605.0

Another possible condition would be camera accelerometer/gyro data.
Quote
3) decide on shooting modes (menu selectable) :  I think we need :
     i)  one pulse mode - half shoot on application of 5V USB power,  full shoot on removal of 5V USB power
    ii)  two pulse mode - half shoot on first 5V USB power pulse,  full shoot on second 5V USB power pulse (pulse width configurable ?)
   iii) remote zoom ?>  (how does that work)

Should consider what of this actually needs to be in core code and what can be done with a script. If someone wants to come up with some standard lua libraries to support more complex interactions, I would be happy to include them in the distribution.
Quote
4) pick devices that will be supported (menu selectable) :
   i) homebrew 5V USB power via a switch (or commercial versions of the same)
   ii) Ricoh switch unit
   iii)  gentle device(s)  - which ?
      (I'll think about buying whatever we decide on - or see if gentle's will lend us a used unit for development ?)
I would hope that the gentle usb input is not camera specific.
Quote
I suppose we need to think about backwards compatibility.  Fixing the old code seems dangerous.  We could leave it in the way it is, add new code and then add a setup parameter to tell CHDK which code to use (old mode / new mode).  Or just change it a see if anybody cares. 
Cleaning up/getting rid of the existing mess would be my main motivation for getting this done, so I don't like the idea of keeping it around for compatibility. #ifdef optional stuff suffers code rot, especially when it's a mess.
Don't forget what the H stands for.


Re: The \core\kbd.c\kbd_process() function
« Reply #14 on: 09 / July / 2011, 16:42:34 »
Cleaning up/getting rid of the existing mess would be my main motivation for getting this done, so I don't like the idea of keeping it around for compatibility. #ifdef optional stuff suffers code rot, especially when it's a mess.
I wasn't thinking of a compile time choice -that's pretty much useless to the average CHDK user.  It needs to be something you select from the CHDK menu as enabled or not and a big if (newmode)... else (oldmode)... endif put around the old and new code sections I think.
Ported :   A1200    SD940   G10    Powershot N    G16

 

Related Topics