CHDK PTP interface - page 31 - General Discussion and Assistance - CHDK Forum

CHDK PTP interface

  • 1244 Replies
  • 532827 Views
*

Offline ultimA

  • ***
  • 137
Re: CHDK PTP interface
« Reply #300 on: 29 / November / 2010, 14:21:54 »
Advertisements
If I want to implement new PTP-query in the camera that returns only a single number or two, is my understanding of the code correct that I only need to do the following?

1) Add a new enum value to ptp_chdk_command
2) Extend the switch in handle_ptp(...)
3) Write ptp.num_param/.param1/.param2 with the return value
4) Do nothing else. PTP will return the params in the ptp structure "automatically" because of the data->send_resp( data->handle, &ptp ); line at the end of the function.

Re: CHDK PTP interface
« Reply #301 on: 29 / November / 2010, 17:34:43 »
For windows, the easiest route is this one (I'm not 100% sure if this matches proposal patch version functionally):
http://www.mweerden.net/download/chdk-ptp/libptp2-chdk-win32.zip
I'm pretty sure it doesn't match. I can't quickly build a new version at the moment, but let me know if it's needed. I'm guessing that others have more up-to-date versions.

If I want to implement new PTP-query in the camera that returns only a single number or two, is my understanding of the code correct that I only need to do the following?
It seems so, yes.

*

Offline rudi

  • ***
  • 129
  • A590IS_101B, SX260HS_100B
Re: CHDK PTP interface
« Reply #302 on: 29 / November / 2010, 18:28:19 »
Thanks for your informations, but I would give only a hint for return value of the lua-api function. I think the current implementation is wrong. We can't get the success result from "switch_mode_usb()". Sorry for my bad description.

For your information: We had on CHDK-DE version some problems with download/upload files (eg. on IXUS100 and A610). The reason is the constant buffersize. CHDKLover have written a solution. He calculate the max. RAM-buffersize. 50% from that is the ptp-buffersize. He found also a solution to make all vxworks-cams ptp-ready incl. mode-switching (see DE-Trunk 465 and up). But OPT_LUA_CALL_NATIVE is required.

EDIT:
I think, I found the answer for "switch_mode_usb()"-result. It is a tricky tri-state result (mode-val on stack for switching ok and nil for any error at switching). Is that correct?

rudi
« Last Edit: 30 / November / 2010, 11:15:01 by rudi »

*

Offline reyalp

  • ******
  • 14125
Re: CHDK PTP interface
« Reply #303 on: 19 / December / 2010, 17:06:32 »
Some ptp changes here http://chdk.setepontos.com/index.php?topic=5793.msg58335#msg58335

I've attached a win32 build of ptpcam, along with source patches. This isn't really useful as is but it shows how to use the new commands.

edit:
patches are against mweerdens github source.
« Last Edit: 19 / December / 2010, 18:34:04 by reyalp »
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14125
Re: CHDK PTP interface
« Reply #304 on: 19 / December / 2010, 18:41:50 »
I think, I found the answer for "switch_mode_usb()"-result. It is a tricky tri-state result (mode-val on stack for switching ok and nil for any error at switching). Is that correct?
Seems so.

I think switch_mode_usb should not exist. set_record should know if PTP is active, and call C code switch_mode_usb if needed. Many older cameras don't need any special code.

(I agree set_record is a bad name, but I didn't want to confuse with shooting modes which already had get_mode and set_capture_mode...)
Don't forget what the H stands for.

*

Offline rudi

  • ***
  • 129
  • A590IS_101B, SX260HS_100B
Re: CHDK PTP interface
« Reply #305 on: 20 / December / 2010, 12:57:41 »
Hello,

for mode-switching in ptp (mode-command) we use for VxWorks the canon event functions. Can we this also use for DryOS-cams?

successful tested with A590:
Code: [Select]
//equal levent_set_record();
<conn> lua post_levent_to_ui("PressRecButton");post_levent_to_ui("UnpressRecButton")

//for example make a shoot
<conn> lua shoot()

//equal levent_set_play();
<conn> lua post_levent_to_ui("PressPBButton");post_levent_to_ui("UnpressPBButton")

The best is, all cams use only one routine. We don't need to find entrypoints for set_control_event, PB2Rec and Rec2PB on DryOS-cams. I think the two methods are a little bit different and the event-method is a better way (feel stable on tests).
The downside is OPT_LUA_CALL_NATIVE is required for OPT_PTP, but for VxWorks-cams it is already required.

rudi

*

Offline ultimA

  • ***
  • 137
Re: CHDK PTP interface
« Reply #306 on: 20 / December / 2010, 15:18:54 »
@reyalp: I saw the changes you made to the patch. While implementing, at first I also thought of using a bitfield. But the reason I didn't do that, and why I think it is not a good option right now, is that in my oppinion it complicates code for no foreseeable benefit. I understand that this theoretically makes adding new scripting languages possible, but as I have seen (I think it was this thread earlier) there is really no interest in adding UBasic support to PTP. And I also see no realistic chance of adding a third scripting language later on.

The reason it complicates code so much is that because you start supporting "scripting interfaces", as noted in the code comments. So to truely stay correct and open to future additions in the future, for every script-related PTP command you would need to supply a "target interface" as an argument (=an argument to state which scripting interface you are communicating to). This adds a lot of related problems, like what if there are multiple interface targets specified, how do you handle returning different errors in these cases and so on. And as stated, I cannot foresee supporting a scripting language in PTP other than LUA at the moment. So is this all worth it?

A relatively unrelated note: Maybe it would be better, instead of a ScriptSupport command, to have a general FeatureQuery command, that could return supported features of the current CHDK & camera in a bitfield. Not only for scripting, but games/zoom/native_calls/and other features.

*

Offline reyalp

  • ******
  • 14125
Re: CHDK PTP interface
« Reply #307 on: 20 / December / 2010, 16:37:24 »
The best is, all cams use only one routine. We don't need to find entrypoints for set_control_event, PB2Rec and Rec2PB on DryOS-cams. I think the two methods are a little bit different and the event-method is a better way (feel stable on tests).
The downside is OPT_LUA_CALL_NATIVE is required for OPT_PTP, but for VxWorks-cams it is already required.
I don't understand why native call is required, you can use without levent native call.

It looks like the code you are using is identical to lua set_record, which doesn't work on (most ?) dryos cameras when USB is connected. I know I tried a bunch of things on D10 and couldn't get it to switch using levent.

@ultimA it seemed to me there was some interest in ubasic support, there are already some constants there for it. ExecuteScript already takes a type option (which is just a constant, not a bitfield) PTP_CHDK_SL_LUA

One reason to use ubasic is cameras with very little memory. Once your scripting optional stuff is done, people will have the option of ubasic only, and might still want ptp.

The way things are now, the "supported" bit will be (1<< (executescript number)). I thought about changing ExecuteScript to use the bitmask values, but as you say it doesn't make sense to pass more than one.

I would assume that if multiple script interfaces are supported, you can only use one at a time, at least until a major protocol change.
Don't forget what the H stands for.

*

Offline hwntw

  • ***
  • 162
Re: CHDK PTP interface
« Reply #308 on: 20 / December / 2010, 17:13:18 »
Deleted by a craven coward
« Last Edit: 28 / January / 2011, 18:09:44 by hwntw »
Ixus 95 IS Ixus 30 izoom Powershot S80 S100 S200


Windows 10

*

Offline ultimA

  • ***
  • 137
Re: CHDK PTP interface
« Reply #309 on: 20 / December / 2010, 22:20:37 »
One reason to use ubasic is cameras with very little memory. Once your scripting optional stuff is done, people will have the option of ubasic only, and might still want ptp.
But this argumentation is only valid if OPT_LUA_CALL_NATIVE is not made a requirement for OPT_PTP.

The way things are now, the "supported" bit will be (1<< (executescript number)).
What is "executescript number"?

 

Related Topics


SimplePortal © 2008-2014, SimplePortal