CHDK PTP interface - page 17 - General Discussion and Assistance - CHDK Forum supplierdeeply

CHDK PTP interface

  • 1227 Replies
Re: CHDK PTP interface
« Reply #160 on: 11 / February / 2010, 16:02:06 »
Helo. I am camera a590IS. Test chdkcam.exe. Problem connecting camera WinXP to random.
Stop in the control panel scanner and camera connecting ok 100%.
Seems malfunctioning stabilizer.


Offline JMD

  • *
  • 34
Re: CHDK PTP interface
« Reply #161 on: 17 / February / 2010, 12:32:05 »
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.

Re: CHDK PTP interface
« Reply #162 on: 26 / February / 2010, 09:25:04 »

 I'm very interested in making PTP working on G9, but I'm stuck on the mode switching. I'm using 100g version fw. I've tried all 3 methods I found, i.e. the one with set_control_event, method with sending a disconnect event via post event and even ForceQuitPTPMode. None of them does really work, the posting of event disconnects camera, while the set_control_event simply blocks camera and the only way to get out of the state is to remove a camera battery.

Here are the function locations I've extracted.

NHSTUB(add_ptp_handler, 0xFF8D897C) // via ptp handler table
NHSTUB(set_control_event, 0xFF872C2C) // via eventproc_export_IsControlEventActive (last call)
NHSTUB(PB2Rec, 0xFF876664) // via aAcPb2rec
NHSTUB(Rec2PB, 0xFF875024) // via aAcRec2pb

NHSTUB(ForceQuitPTPMode, 0xFF83ED10)
NHSTUB(RefreshUSBMode, 0xFF83EC8C)

I've double checked outputs of "magic" transformation for set_control_event and the results are same as for the other cameras (0x902, 0x8........902).

Does anybody have an idea what else I could try in order to switch the mode?

Thank you

Re: CHDK PTP interface
« Reply #163 on: 26 / February / 2010, 10:15:03 »
Please read my post a few pages back. Switchting mode is very tricky on G9. I'm currently reverse engineering the whole shooting process to set up an own mode switch. Until now I can run out the lens, activate the image system, set properties and start shooting. But somewhere inside the shooting process the camera comes into panic mode and switches off. I think I missed some preparating call and I did not find all the correct calls until now.

Re: CHDK PTP interface
« Reply #164 on: 26 / February / 2010, 10:53:21 »
Please read my post a few pages back. Switchting mode is very tricky on G9. I'm currently reverse engineering the whole shooting process to set up an own mode switch. Until now I can run out the lens, activate the image system, set properties and start shooting. But somewhere inside the shooting process the camera comes into panic mode and switches off. I think I missed some preparating call and I did not find all the correct calls until now.

Thank you for your feedback. It seems you made a good progress so I'll hope you'll crack the problem. Let me know if you have some particular problem I may help you, though I'm not really fluent in ARM assembly, so I'm quite slow in reading the code.

Re: CHDK PTP interface
« Reply #165 on: 03 / March / 2010, 00:43:27 »
I was wondering if A460 and/or IXUS 960 will be supported by PTP?

Re: CHDK PTP interface
« Reply #166 on: 04 / March / 2010, 05:40:50 »
Does anybnody has haad anyprolem with the Zoom on the SX200IS usig PTP ?  he camera after some zooing shutdown.

Re: CHDK PTP interface
« Reply #167 on: 13 / March / 2010, 02:07:44 »
I will say this about PTP it is great for debugging.  Thx for doing the initial implementation.  I added it to the SD780 and love it.

Canon Models - SD300, SD780, & SX210

Re: CHDK PTP interface
« Reply #168 on: 28 / March / 2010, 18:28:32 »
I'm using Debian Lenny. I installed libusb-0.1.8 from source in /usr/lib. I patched and installed libptp2-1.1.10 from source.
I'm using the CHDK PTP build for A590 1.01b from ewavr's site. When I try ptpcam I keep getting:
ERROR: Could not open session!

I've tried using ptpcam --bus=BUS-NUMBER --dev=DEV-NUMBER with bus-number and dev-number taken from lsusb. I still get the same error.

I also have the libusb.0.1-4 installed that's part of Debian.

Could someone tell me what's going wrong?

Mweerden helped me figure out the problem was that my camera was talking to the Debian libusb and not the libusb I installed from source, which libptp was dependent on. Uninstalling libusb-0.1.8 and installing the Debian package libusb-dev, then recompiling and reinstalling libptp got everything working.

Here are step by step instructions for getting a patched version of libptp going on Debian Lenny:
$ su -c "apt-get install libusb-dev"

$ mkdir libptp_chdk
$ cd libptp_chdk
$ wget

download libptp2-1.1.10.tar.gz from:
and save it in libptp_chdk

$ tar xvzf libptp2-1.1.10.tar.gz
$ patch -p0 < libptp-chdk.patch
$ cd libptp2-1.1.10/
$ ./configure
$ make
$ su -c "make install"

I had to run ldconfig so ptpcam could see libptp2.
To see if ptpcam can find libptp2 run this: $ ldd `which ptpcam`
If it says "not found", run:
$ su -c "ldconfig"

« Last Edit: 29 / March / 2010, 22:34:58 by yardleydobon »

Re: CHDK PTP interface
« Reply #169 on: 31 / March / 2010, 12:53:51 »
Glad to see the continued activity here.

As a result of yardleydobon trying to get CHDK PTP to work on his camera (and specifically him not being able to download JPEGs), 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. As I couldn't find any other mentioning of it, I figured I'd add it here. I guess ewavr also noticed it, seeing his PTP patch.

One additional thing about this: given Microfunguy's post it seems as if this limit does not hold for his camera (or perhaps VxWorks). Or perhaps he just had a pretty small photo?

As for the discussion whoever tried to start (and sort of started later), I would suggest adding CHDK PTP to the trunk in a minimal form. Having a central "standard" interface should avoid too much divergence in patches and tools as well as increase visibility, usage and improvements.

The main question then becomes "what is this minimal form?" Which I'd split into the following questions (mainly based on the patches of ewavr and myself).

Add upload/download?
This seems to me as one of the essentials as it provides functionality that isn't available through the firmware PTP on many cameras and is one of the main reasons to extend PTP. Edit: 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).

Add script execution?
As this instantly provides access to a great part of CHDK functionality, this also seems a no-brainer. There are two additional questions here, though. First of all, LUA or uBASIC? I'd originally did LUA because it seemed to be the easiest to make and I got the impression that LUA is preferred. However, I've been told that uBASIC is easier for "non-hackers". If someone knows (or makes) a easy way to execute a string containing uBASIC, then I'd think it's easy and cheap to allow both (change PTP_CHDK_ExecuteLUA to PTP_CHDK_ExecuteScript and use param2 to indicate the language).

The other question is regarding the output. Is having it scroll over the camera screen sufficient or do you want to be able to read it out via PTP? In case of the latter, do you store all output in camera memory first or do you send a PTP event for every line (should be nicest, but haven't looked at such functionality).

Add "debugging" features?
This includes reading/writing memory, remote calling of functions (by address) and retrieval of props and params. I'm in favour of at least keeping the first two. Both for actual debugging and possibly providing tools with an easy way to extend functionality not available otherwise without having to change CHDK itself (albeit camera specific, unless we have/add a way to resolve function names). For the other two see "Add specific functionality" below.

Add mode switching?
I'm not entirely sure about this one, but I suspect it is also covered under the "Add specific functionality" part below.

Add shutdown/reboot?
See "Add specific functionality."

Add video settings retrieval?
See "Add specific functionality."

Add directory reading?
See "Add specific functionality."

Add specific functionality?
To minimise extending CHDK PTP indefinitely with more and more useful functionality, I think it is preferable to only do this when there is absolutely no other way. I'm hoping that most of these things can be better implemented as LUA functions and accessed as such via PTP. I think this is at least the case for things like mode switching, shutdown/reboot and directory access.

The only downside to doing things via scripts is that values have to be constantly converted to and from strings. On the other hand, how much data does one expect to be transferred in this way? Big chucks of memory can better be obtained using CHDK PTP "get memory" functionality (meaning some script functions should return pointers).

When should CHDK PTP be enabled?
I think the amount of code is pretty small and the code is only used when specific CHDK PTP commands are received. The only side effects are an extra short task at initialisation and one extra entry in the PTP handlers list. I don't really see any objection to having it enabled all the time. That is, as long as it's supported by the camera, which means controlling its addition with defines in camera.h.

Also, I'd suggest ensuring that CHDK PTP can be enabled with a minimal amount of effort. For example by just adding add_ptp_handler and the one define in camera.h. The rest of the camera specifics could be covered by trivial default wrappers that just return something such that CHDK PTP knows the functionality isn't implemented. I think this might also be very helpful when porting; one of the first things you do is add the CHDK PTP task and you can already remotely inspect memory and call functions. Add file-operation stubs and you can easily upload new CHDK images without constantly removing and inserting cards.

Well.. that's a bit more text than I anticipated.. ;) To summarise: I'd suggest adding CHDK PTP to the trunk, enabled via camera.h and consisting of just upload/download, read/write memory, function call and script execution (LUA and uBASIC and preferably with per line output PTP events). The rest (e.g. mode switching, video conf) I'd move to LUA and/or uBASIC.
« Last Edit: 31 / March / 2010, 13:03:27 by mweerden »


Related Topics