CHDK PTP interface

yardleydobon

35

Re: CHDK PTP interface

« Reply #170 on: 31 / March / 2010, 19:56:47 »

Advertisements

I'd like to report that for my A590 IS with 1.01b:
lua post_levent_to_ui("PressRecButton")
lua shoot()
works for capturing images over PTP. Pressing the <Alt> button unlocks the other buttons and zoom.

I don't really know enough to comment knowledgeably on what the CHDK PTP interface should be. However, I think you've just laid out a very clear description of a clean and simple interface. Mode switching seems to be so varied between cameras I think it is best to leave that to a script. I think the interface should be easily built upon by other programs; for example I'd really like to see a remote capture GUI for Linux, and a CLI that has command history and can read and execute scripts saved as files.

I think it should definitely be in trunk. I sure don't get why the hell this thread is fading and CHDK PTP isn't getting more attention! Perhaps many people don't realize that this effectively adds computer control to CHDK.

Logged

reyalp

14080

Re: CHDK PTP interface

« Reply #171 on: 31 / March / 2010, 20:51:04 »

Agree with mweerden.

I don't personally see any reason to add ubasic support. If you restrict yourself to doing the things that ubasic can do, an equivalent lua script isn't really more complicated.

Executing ubasic shouldn't be too hard, but you'd need to do something about the one statement per cycle business (so you'd need a loop running ubasic_run until it finished). The PTP handler should probably just pass a message to the kbd task to run the script in the normal way, otherwise we will run into problems with long running scripts, not to mention things running in a different task than they expect to.

A further (somewhat OT) thought I've had on scripting is to allow PTP to communicate with an already running script, rather then sending a full script to be executed each time. If you also added a way to send messages back, you'd have a very flexible interface with very little code required.

Logged

Don't forget what the H stands for.

an0n

152

Re: CHDK PTP interface

« Reply #172 on: 01 / April / 2010, 04:26:50 »

Logged

A720IS.

JMD

34

Re: CHDK PTP interface

« Reply #173 on: 01 / April / 2010, 15:31:43 »

I have a question about adding code to the trunk. When you add code to the trunk, is there a policy that all of the cameras that support the new code have to be updated? i.e. Does someone need to go in and modify all of the platforms and all of the firmware versions within the trunk, or will that be done piece meal? Just curious.

Logged

reyalp

14080

Re: CHDK PTP interface

« Reply #174 on: 01 / April / 2010, 15:54:39 »

Quote from: JMD on 01 / April / 2010, 15:31:43

I have a question about adding code to the trunk. When you add code to the trunk, is there a policy that all of the cameras that support the new code have to be updated?

No, features can be only enabled for certain cameras. Extra long exposures are and example.

Of course, the goal is to support each feature on every camera capable of supporting it.

Logged

Don't forget what the H stands for.

JMD

34

Re: CHDK PTP interface

« Reply #175 on: 01 / April / 2010, 18:19:17 »

Thanks reyalp

I posted this a couple of weeks ago and didn't get a response, do you have any insight as to how I could make this application work more efficiently.

Quote

Special application and some general observations. I have attached my SX1 via a USB cable to an ethernet to USB server. That way I can make my SX1 part of my local network. I have actually tried two different kinds of ethernet to USB servers, the results were different, but similar.

1) The frame rate and network utilization is different between the two servers
2) If I turn off the "live image" and the "overlay" the CPU usage of ChdkCam jumps way up. With one of the servers the network utilization stayed very high even without the live feed. With the other server the network utilization dropped to close to 0, but the CPU utilization was higher.

I'm guessing that this behavior is do to the delay in the ethernet to USB server. Obviously, I am not getting as fast of a connection as I do when the camera is connected directly to the USB port on my computer. Perhaps ChdkCam is polling the camera on a regular basis, but with a very short time out. When it doesn't get a response in time it keeps polling, chewing up CPU cycles and ethernet bandwidth. It would appear that ChdkCam needs a bit more optimization for this type of application to work well.

Ewavr, I think I can compile ChdkCam. Do you have any suggestions on what I might change in the code to make this work better.

Thank you.

Logged

mweerden

194

Re: CHDK PTP interface

« Reply #176 on: 01 / April / 2010, 20:09:08 »

Quote from: mweerden on 31 / March / 2010, 12:53:51

..., I noticed that there is a file size limit to the files that can be downloaded with my original patch/download functionality. I got a maximum of 251312 while experimenting, which seems to relate to USB packet sizes of 256k.

Quote

Regarding downloads and file size limits, there are two options: either use ewavr's method of repeatedly getting parts of the file or, and this would be much nicer if possible, figuring out how the send_data function really works to enable repeated calls (similar to how uploading works).

Today I intercepted a firmware handler to see how send_data is normally used. It turns out that of the two "size" parameters the first should be the size of the block that is sent with a given call and the second should be the total size. This isn't surprising and I'm pretty sure I tried it, but the trick is that the second size should only be given with the first call (and it should be 0 afterwards). With this it is now possible to nicely download big chunks of data.

B.t.w., I haven't checked it explicitly, but the file size limit I encountered is more likely due to the fact that malloc fails. The code suggest that this should result in a different error code, but it seems that either USB or the libptp2 code doesn't pass it on.

The two parameters after size appear to be a function/data pointer pair. In the case I tested the function was at 0xff8d222c, which basically consists of a call to GiveSemaphore. I guess it is called when the transfer is finished. I haven't looked into this any further.

Quote from: reyalp on 31 / March / 2010, 20:51:04

I don't personally see any reason to add ubasic support. If you restrict yourself to doing the things that ubasic can do, an equivalent lua script isn't really more complicated.

Perhaps we can just implement the PTP_CHDK_ExecuteScript and only support LUA at first. This only adds a simple if and if the need for uBASIC really arises it can be added then.

Quote

A further (somewhat OT) thought I've had on scripting is to allow PTP to communicate with an already running script, rather then sending a full script to be executed each time. If you also added a way to send messages back, you'd have a very flexible interface with very little code required.

I've also tried to find a way to send back events today, but was not entirely successful. I did find a function that almost certainly is used for sending events, but I couldn't get it to work. I found it by searching for 0x0000c008. For my IXUS870IS (1.01a) it's at 0xff9f138c. It can also be found by picking the right PTP handler; for example at the end of the PTP_OC_SendObjectInfo (0x100C) handler.

The first parameter is most likely the "Event DataSet" (with 4-byte code): struct { int code, sess_id, trans_id, param1, param2, param3; }. The second parameter seems to hold flags; the two least significant bits each result in a specific function call if set. I've seen the values 2 and 3 for this parameter (mostly 2).

Truly OT: Why aren't we using a DVCS

Logged

mweerden

194

Re: CHDK PTP interface

« Reply #177 on: 05 / April / 2010, 06:15:36 »

I made an initial attempt for the minimal CHDK PTP interface. In addition to the suggestions I made previously I also added a way to request a version to be able to ensure both parties understand each other. Apart from one thing, I think it is already something that could be included in the trunk. The "one thing" is the name of the new Lua function switch_mode; as there already seem to be functions to switch mode under normal conditions, this name should probably reflect its USB-connection requirement.

As I'm playing with git and GitHub, I've made it available on the latter. You can view the changes here (unfortunately not (yet) downloadable as patch; if anyone wants it, just ask).

The thing that remains is script feedback. There are two parts, I think. One is getting the "console" output (like in ewavr's tool) and the other is getting return values of a script. I think the first would be excellent for events, if we can figure those out. Until that time I'd suggest getting the info (i.e. all text, a single line or a pointer to memory) using Lua.

For the return values I was thinking about the following. Use a PTP parameter for flags and include the flags "wait for script termination" and "store (first) return value in TempData" (the latter requiring the first). Do the same for the PTP_CHDK_TempData command for the flags "download" (instead of the current upload) and "remove/free data".

With the storing of the return value you'd return the type of the data put in TempData (no data, nil, boolean, number, string; the rest I'd ignore for now) and possibly its size. I only talk about one return value (instead of the arbitrary number of values that might be available) because I'm assuming that this is almost always what you need. It also makes things a bit easier (e.g. making TempData point to the const char* returned by Lua for strings).

Logged

Microfunguy

4037

Re: CHDK PTP interface

« Reply #178 on: 05 / April / 2010, 08:36:19 »

I did play with this a few months ago with the A620 and SDM but have been concentrating on other features since then.

I am not sure what percentage of users will actually use this, clever though it is.

I am certainly not adding Lua support, that will terrify SDM users.

How much does the filesize increase with this compile-option enabled ?

David

Logged

mweerden

194

Re: CHDK PTP interface

« Reply #179 on: 05 / April / 2010, 14:01:48 »

Quote from: Microfunguy on 05 / April / 2010, 08:36:19

I am not sure what percentage of users will actually use this, clever though it is.

What I'd expect is that "normal" users would be interested in:

a download tool (or, more generic, a remote file management program and especially when they don't have easy or any access to a card reader),
a "webcam" tool/driver/whatever and
a remote control tool (when they use their camera for more than just snapping some pictures; your target audience in specific).

This interface makes these tools possible.

Quote

I am certainly not adding Lua support, that will terrify SDM users.

And you have every right not to. However, adding Lua support doesn't mean people have to use it themselves or that they can't use uBASIC (assuming support for it is implemented at some stage).

Especially with the possibility to obtain the return values, I believe the Lua support is ideal for tool makers. I don't know if the same would hold for uBASIC, simply because I know nearly nothing about it.

Quote

How much does the filesize increase with this compile-option enabled ?

This is what I get when building for the IXUS870IS:

	`DISKBOOT.BIN`	`PS.FI2`
full support	259337	153424
no CHDK PTP (undef in camera.h)	258097	152528
no CHDK PTP and no support in platform	257865	152448
clean (i.e. current CHDK trunk)	257633	152320

That's +0.66% for DISKBOOT.BIN and +0.72% for PS.FI2 when you compare clean vs. full support.

Logged