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

chdkptp - alternative ptp client

  • 1106 Replies
  • 513825 Views
Re: chdkptp - alternative ptp client
« Reply #960 on: 14 / April / 2017, 05:44:15 »
Advertisements
There isn't any build on the assembla site! Could someone upload the latest windows build?

=> https://app.assembla.com/spaces/chdkptp/documents
Sorry i changed the browser and now i can see the builds

Re: chdkptp - alternative ptp client
« Reply #961 on: 14 / April / 2017, 08:06:12 »
Is it possible to shut down  the lcd with a command?
« Last Edit: 14 / April / 2017, 08:30:35 by eric »

*

Offline srsa_4c

  • ******
  • 4451
Re: chdkptp - alternative ptp client
« Reply #962 on: 14 / April / 2017, 08:21:52 »
Is it possible to shut down lcd retroillumination with a command?
If you mean the LCD altogether or its backlight, see the following script commands:
set_lcd_display
set_backlight
See the chdkptp manual documentation or its help command for details on how to run a script on camera.

*

Offline reyalp

  • ******
  • 14080
Re: chdkptp - alternative ptp client
« Reply #963 on: 14 / April / 2017, 13:19:30 »
Sorry i changed the browser and now i can see the builds
Which browser gave you problems?
Don't forget what the H stands for.


Re: chdkptp - alternative ptp client
« Reply #964 on: 18 / April / 2017, 11:25:14 »
Sorry i changed the browser and now i can see the builds
Which browser gave you problems?
Opera Beta 44.0.2510.73

*

Offline reyalp

  • ******
  • 14080
Re: chdkptp - alternative ptp client
« Reply #965 on: 24 / April / 2017, 00:24:57 »
GetMemory discussion split to https://chdk.setepontos.com/index.php?topic=4338.msg132332#msg132332

(leaving a link here because I linked the original thread in the commit message :()
Don't forget what the H stands for.

*

Offline axman

  • ***
  • 145
Re: chdkptp - alternative ptp client
« Reply #966 on: 17 / June / 2017, 20:07:47 »
In the SX260 porting thread,

Please check what the underlying mkdir (=MakeDirectory_Fut stub) function returns on success and failure. The lua code assumes 0 on success.

If the canon code returns something different on these cameras, the wrapper should be adjusted with a DRYOS_R... #ifdef so the chdk sees the expected return value.

You can test this on an affected camera with chdkptp, by looking up the stub address and using return call_func_ptr(address,"dirname",-1)

Note the CHDK wrapper code passes -1 as the second (unknown) param to mkdir, but it looks like for the sx260, the canon firmware passes 1 or 0.

How exactly to do this with chdkptp?  Trying to debug ixus175_elph180 filewrite failure.

I could use a pointer to a script or other info source, to learn how to invoke this specific test.  Thanks in advance.

edit: actually insert quoted text, clarified where quote came from.
« Last Edit: 17 / June / 2017, 20:12:44 by axman »

*

Offline reyalp

  • ******
  • 14080
Re: chdkptp - alternative ptp client
« Reply #967 on: 17 / June / 2017, 20:56:13 »
How exactly to do this with chdkptp?  Trying to debug ixus175_elph180 filewrite failure.
What I meant in that thread was
1) Look up the address of MakeDirectory_Fut in stubs_entry.S (or stubs_entry_2.S if defined there)
2) Use
=return call_func_ptr(... the address you got above...,"A/TESTDIR",-1)

where A/TESTDIR could be any valid path that doesn't exist. Native calls must be enabled in the CHDK menu to use call_func_ptr.

However, the above was specifically to check the return value. If the stub were wrong, regular os.mkdir in chdk Lua would crash or fail. You can use the llibtst.lua script in CHDK/SCRIPTS/TEST to test this and many other functions.
Don't forget what the H stands for.


Re: chdkptp - alternative ptp client
« Reply #968 on: 21 / June / 2017, 19:55:48 »
Speaking of debugging, how about (possibly dumbed-down) gdbserver? This was the latest attempt that I could find.
Author of CHIMP, Canon Hack Installation and Management Platform

*

Offline reyalp

  • ******
  • 14080
Re: chdkptp - alternative ptp client
« Reply #969 on: 21 / June / 2017, 22:44:32 »
Speaking of debugging, how about (possibly dumbed-down) gdbserver? This was the latest attempt that I could find.
If someone wants to write it, sure... however, I suspect it would be rather difficult, and the biggest difficulties would be in implementing the debugger part rather than the communication part.

The thread you linked mentions using the DryOS console. This can be done using the physical UART or the patches in https://chdk.setepontos.com/index.php?topic=11029.30 (I'm still slowly tinkering with getting that code into the trunk)

Another thing I've considered is adding a way to watch arbitrary ranges of memory using in the chdkptp GUI. It would also be relatively easy to implement a memory browser that gives you a hex-editor style window.
Don't forget what the H stands for.

 

Related Topics