chdkptp - alternative ptp client - page 31 - General Discussion and Assistance - CHDK Forum  

chdkptp - alternative ptp client

  • 1106 Replies
  • 517578 Views
Re: alternative ptp client
« Reply #300 on: 20 / February / 2013, 14:07:38 »
Advertisements
Hi, I have installed chdkptp in windows 7 x64
But when I connect the camera and try to connect I get this error:
http://ubuntuone.com/3uQDZsU7zOfdcDiXIzUAYW

Any help?

Thanks

*

Offline srsa_4c

  • ******
  • 4451
Re: alternative ptp client
« Reply #301 on: 20 / February / 2013, 17:39:50 »
But when I connect the camera and try to connect I get this error:
http://ubuntuone.com/3uQDZsU7zOfdcDiXIzUAYW
You can get that error when CHDK is not running.

*

Offline lyzby

  • **
  • 52
Re: alternative ptp client
« Reply #302 on: 25 / February / 2013, 18:58:07 »
On April 1, 2012, in conjunction with headless linux use of chdkptp, I reported a problem (not chdkptp-related) with the use of zoom with an SX40HS.  I had successfully used chdkptp with an A590is, as documented here:

http://chdk.wikia.com/wiki/Chdkptp_in_headless_linux_Dockstar_-_remote_control

I just got back to the issue, and installed the latest chdk for the SX40HS on the SD card.  I went back to the dockstar and connected to the SX40HS, with no change in chdkptp.  Zoom now works, up to "lua set_zoom(250)" (although I haven't figured out how to focus at that zoom level--at a distance of only about a foot).  At "lua set_zoom(80)" it auto-focuses and takes good photos.  Sometimes the best thing to do is wait.

*

Offline srsa_4c

  • ******
  • 4451
Re: alternative ptp client
« Reply #303 on: 09 / March / 2013, 20:28:21 »
I'm having a strange problem with my s1is.

File upload to the camera uses a protocol where the first chunk starts with
[4 bytes] filename length
[n bytes] filename
[...] file data, first chunk
The start of the file data is passed to fwrite(). This works for every other camera, but not for this one. I get semi-random data corruption when the address passed to fwrite() is odd. I have tried doing several things, but the only one which helped was to change the PTP client (chdkptp) to pad the filename with NULs for 32bit-alignment.
I'm wondering whether this is something that's good practice anyway, since neither ARMv5 nor the (possibly involved) DMA controller is able to do efficient work on unaligned addresses. I know of course that the firmware routines can deal with this situation (except on my camera).


*

Offline reyalp

  • ******
  • 14082
Re: alternative ptp client
« Reply #304 on: 09 / March / 2013, 20:58:19 »
I'm wondering whether this is something that's good practice anyway, since neither ARMv5 nor the (possibly involved) DMA controller is able to do efficient work on unaligned addresses. I know of course that the firmware routines can deal with this situation (except on my camera).
On most cameras, fwrite should be OK, because each FILE * has an uncached (and presumably aligned if required) buffer that is used for the actual write(). As far as I know, it would always go through this buffer.
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4451
Re: alternative ptp client
« Reply #305 on: 09 / March / 2013, 21:14:05 »
On most cameras, fwrite should be OK, because each FILE * has an uncached (and presumably aligned if required) buffer that is used for the actual write(). As far as I know, it would always go through this buffer.
All other cameras should be ok, I've tried it on the Ixus30.
BTW, fwrite() is FWrite_Fut() on most cameras, except
ixus30, 40: fwrite(), there's no _Fut API.
s1is: fwrite() has horrible performance (~30kB/s, I have no idea how it could be that bad), so I've replaced all f* functions with wrapped open(), write() etc. The corruption is there, no matter fwrite() or write()...

*

Offline reyalp

  • ******
  • 14082
Re: alternative ptp client
« Reply #306 on: 09 / March / 2013, 21:28:52 »
On most cameras, fwrite should be OK, because each FILE * has an uncached (and presumably aligned if required) buffer that is used for the actual write(). As far as I know, it would always go through this buffer.
All other cameras should be ok, I've tried it on the Ixus30.
BTW, fwrite() is FWrite_Fut() on most cameras, except
ixus30, 40: fwrite(), there's no _Fut API.
s1is: fwrite() has horrible performance (~30kB/s, I have no idea how it could be that bad), so I've replaced all f* functions with wrapped open(), write() etc. The corruption is there, no matter fwrite() or write()...
I don't think null padding and aligning the name should hurt anything.

This reminds me of this problem: http://chdk.setepontos.com/index.php?topic=6730.msg76760#msg76760 ... in fact, my original workaround was to pad the filename data.
Don't forget what the H stands for.

*

Offline msl

  • *****
  • 1280
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: alternative ptp client
« Reply #307 on: 10 / March / 2013, 06:14:40 »
Live view on older cameras like the ixus60:

It seems the live view would not work properly on older cameras. Tests with an ixus 60 shows that only the bitmap overlay works conditionally. I think it is missing a few things in the source code.

A screenshot of a overlay example shows an artefact of an older displaying after a 'draw_clear()' command (red marked).

It would be very nice if there is a possibility, make live view  available for these older cameras.

msl
CHDK-DE:  CHDK-DE links


*

Offline blackhole

  • *****
  • 940
  • A590IS 101b
    • Planetary astrophotography
Re: alternative ptp client
« Reply #308 on: 10 / March / 2013, 07:02:01 »
Quote
It seems the live view would not work properly on older cameras. Tests with an ixus 60
To me on the A530 all work without a problem, it is a camera from the same era as the Ixus 60 , but I used an older version chdkptp client when I tried.

http://chdk.setepontos.com/index.php?topic=6231.msg83668#msg83668

*

Offline srsa_4c

  • ******
  • 4451
Re: alternative ptp client
« Reply #309 on: 10 / March / 2013, 12:18:12 »
It seems the live view would not work properly on older cameras.
This is true for those models where nobody implemented the additional functions needed for live view. There are exceptions (the list below may not be complete and is VxWoks only):
a540 with probably the most complete support code,
a410-420-430-450-460
ixus65

platform/model/sub/{revision]/lib.c and/or platform/{model}/lib.c needs to be changed, the attached diff (for ixus60) shows which functions need to be implemented. The above ports usually give a hint where to find specific memory addresses in the firmware.
This kind of work doesn't require assembly skills, all what's needed is to locate the addresses in the reference disassembly, and find the equivalent places in the other disassembly. The routines usually do not differ substantially, they can be compared visually.
Quote
A screenshot of a overlay example shows an artefact of an older displaying after a 'draw_clear()' command (red marked).
If this is only happening when using ptp live view, the attached patch should help (I can't test it, need feedback).

Also note that from r2614 on, the use of memPartInfoGet has been enabled for every VxWorks model, which should speed up ptp transfers considerably. http://chdk.setepontos.com/index.php?topic=650.msg97434#msg97434

 

Related Topics