CHDK PTP interface

hwntw

Deleted by a craven coward

reyalp

hwntw
No, no, no, bad conclusion: if we are going to end up with more memory from this exmem thingy, then use it for compiled PTP (and better zebra for Ixus 95). CHDK is for photographers, scripting is for programmers

I disagree completely with this, but it's off topic to this thread. Feel free to start a new one in general discussion about CHDK development directions.

If I have any say in the matter, scripting will remain a core part of CHDK, and PTP will be enabled by default as soon as it can be cleanly supported across cameras.

ultimA

In my oppinion PTP is just as much a power-user feature as scripting, not much point in arguing which is more for photographers.

But to stay on the topic, I do agree to keep PTP-functionality minimal. However, I would add just two more commands: 1) shooting a picture and 2) transferring a single frame from the live buffer. Note that I'm NOT proposing webcam-like streaming or anything that would require real-time transfer rates. Merely a request to send over a single frame from the current live buffer. I'd propose these in addition to what is already there to be available without scripting, rest to be scripted. Reason is that then the PTP feature set would be enough and adaquate for basic computer controlled camera without the overhead of scripts.

fudgey

ultimA
But to stay on the topic, I do agree to keep PTP-functionality minimal. However, I would add just two more commands: 1) shooting a picture and 2) transferring a single frame from the live buffer. Note that I'm NOT proposing webcam-like streaming or anything that would require real-time transfer rates. Merely a request to send over a single frame from the current live buffer. I'd propose these in addition to what is already there to be available without scripting, rest to be scripted. Reason is that then the PTP feature set would be enough and adaquate for basic computer controlled camera without the overhead of scripts.

If PTP must be kept somehow useful without scripting, then instead of a shooting command I'd go with access to half+full shutter press/release (or even better, to the entire keyboard). But my vote would go against that.

IMO there's no point in making PTP that doesn't require scripting, because UBASIC is small (11.6 KiB according to https://chdk.setepontos.com/d/5793/1, probably hasn't changed immensely after the recent patches). AFAIK, CHDK PTP doesn't currently support UBASIC, but that's not the only thing that's not quite there yet -- Lua is just so much more powerful that it hasn't made any sense to use anything but it so far.

My understanding is that most users who do not want scripting at all don't want it because it complicates camera usage, mainly because of the alt+shutter shortcut which is sort of a trap for beginners and those that don't know CHDK is running on the camera someone gave them. For those users, disabling the script start and menu shortcuts (and optionally menu entries) suffices. This is something that should be easy for a developer to disable for a custom build, but in the long run is solved by user settable shortcut key mapping.

So basically my vote would go for using scripting for all PTP commands that make sense to be implemented as scripts. In a PC side application, use UBASIC commands internally whenever possible since Lua may not be available. Users will not know they are running tiny scripts all over when clicking buttons on a PC GUI and shouldn't care either as long as the camera zooms and shoots as commanded. And if it happens that we really do get some RAM for CHDK on all cameras using that new EXMEM stuff and can use it to solve memory issues, then my vote changes to requiring Lua for PTP.

As for live view, ewavr already implemented it in real time (more or less, depending on USB speed). If my memory serves, the main obstacle for adding that to the trunk CHDK PTP is that it needs some work to make it more generic across cameras with different sorts of live view buffers, resolutions and colors -- something that probably doesn't become much easier even if it's not in real time.

reyalp

fudgey
If PTP must be kept somehow useful without scripting, then instead of a shooting command I'd go with access to half+full shutter press/release (or even better, to the entire keyboard). But my vote would go against that.

As I said, it would be quite easy (almost trivial) to add "action stack" and/or levent support. I'm pretty tempted to do this, just because it would be a tiny amount of code, and would allow basic camera control natively.

One useful part that is missing, and would also be non-trivial to do in ubasic is directory listing. With directory listing, we can make a nice gui for file transfer, which will really help people getting DNG off of multi-paritition cards and similar scenarios. Directory listing can be done in lua, but if we are going to offer non-lua functionality, it seems like this should be included.

AFAIK, CHDK PTP doesn't currently support UBASIC, but that's not the only thing that's not quite there yet -- Lua is just so much more powerful that it hasn't made any sense to use anything but it so far.

Agreed.

My understanding is that most users who do not want scripting at all don't want it because it complicates camera usage, mainly because of the alt+shutter shortcut which is sort of a trap for beginners and those that don't know CHDK is running on the camera someone gave them.

The other issue is memory. Excluding lua could allow some cameras that experience memory related shutdowns to operate normally (although at least some of these have turned out to be coding errors and there's more fat that can be trimmed without losing lua). Ubasic is small enough that it doesn't really matter, IMO.

As for live view, ewavr already implemented it in real time (more or less, depending on USB speed). If my memory serves, the main obstacle for adding that to the trunk CHDK PTP is that it needs some work to make it more generic across cameras with different sorts of live view buffers, resolutions and colors -- something that probably doesn't become much easier even if it's not in real time.

It has always been my intention to add this back. This is one of the main reasons I've started a new gui tool.

sironitomas

@asm1989 The bracketing features still don't work if you shoot with the "Custom Timer" option.

Strange, because they work if you shoot with the "Drive Mode" set in continuous, but that is not wanted in some cases because you must have your finger in the shutter.

waterwingz

reyalp
This adds the necessary functions for mode changing on most dryos cameras. I haven't turned it on in camera.h, but this should give us what we need to support PTP out of the box on almost all cameras.

@reyalp So at this point do I simply need to use the latest trunk release, add #define CAM_CHDK_PTP in the appropriate spot in camera.h, enable the OPT_PTP box in the CHDK-Shell compile options, rebuild and start testing ?

reyalp

waterwingz

reyalp
This adds the necessary functions for mode changing on most dryos cameras. I haven't turned it on in camera.h, but this should give us what we need to support PTP out of the box on almost all cameras.

@reyalp So at this point do I simply need to use the latest trunk release, add #define CAM_CHDK_PTP in the appropriate spot in camera.h, enable the OPT_PTP box in the CHDK-Shell compile options, rebuild and start testing ?

Probably. The entry points for the various functions may not have been identified correctly on your camera, but most should be OK.

Edit:
If people can report which cameras have been tested successfull (including mode switching through PTP) that would be helpful.

A540 and D10 work correctly. Most vxworks cameras should be fine, since they don't need extra functions to switch.

msl

reyalpIf people can report which cameras have been tested successfull (including mode switching through PTP) that would be helpful

Successfully tested on A495, A590, A610 (VxWorks), A650, A720, Ixus95, Ixus 100 (not clearly), Ixus970, S5, SX200.

waterwingz

reyalp
If people can report which cameras have been tested successfull (including mode switching through PTP) that would be helpful.

No luck for the SD940 with just enabling CAM_CHDK_PTP. Camera is detected by PC but crashes as you try to open folders.

ROMLOG.TXT attached if that helps any.

EDIT : Hmmmm ... CreateTask_init_chdk_ptp() exists in some copies of boot.c. Time to see what that's all about.

ROMLOG.TXT

4.17KB

reyalp

waterwingz
EDIT : Hmmmm ... CreateTask_init_chdk_ptp() exists in some copies of boot.c. Time to see what that's all about.

It should be removed from any boot.c it exists in, started from spytask now.

waterwingz

reyalp
It should be removed from any boot.c it exists in, started from spytask now.

Thanks. One less thing to worry about. Its commented out in the g12 and sx30 of the current trunk.

jrkblo

Hi all
I'm trying to use PTPCAM whit a A495 and 'm getting the following error

c:\Ptpcam-chdk-1005>ptpcam --chdk
unexpected return code 0x2005
error: cannot get camera CHDK PTP version; either it has an unsupported version
or no CHDK PTP support at all
<conn>

Does anyone know what can be that?

reyalp

jrkblo
Hi all
I'm trying to use PTPCAM whit a A495 and 'm getting the following error

c:\Ptpcam-chdk-1005>ptpcam --chdk
unexpected return code 0x2005
error: cannot get camera CHDK PTP version; either it has an unsupported version
or no CHDK PTP support at all
<conn>

Does anyone know what can be that?

What ptpcam binary are you using ? What a495 build are you using ?

I think this one is in CHDKDE, so you might want to use their build.

Bernd R

>Edit:
>If people can report which cameras have been tested successfull (including mode switching through PTP) >that would be helpful.

I test Ixus 1000 HS

C:\Users\pc>e:\chdk\ptpcam --chdk="mode 1"

The command move out the lens and Camera switch off with lens out.no image see, seem crash.later commands with ptpcam give same error message as no camera is connect

I use trunk 1023.maybe this is too old ?

upload and download files and lua reboot work over ptpcam

reyalp

Bernd R
The command move out the lens and Camera switch off with lens out.no image see, seem crash.later commands with ptpcam give same error message as no camera is connect

I use trunk 1023.maybe this is too old ?

More likely some entry points (pb2rec, rec2pb, set_control_event) are wrong.

Bernd R

The address of PB2REC is find in that function that stand this text

AC😛B2REC

I verify that and seem ok.

I add shutdown after _PB2Rec

_PB2Rec();
shutdown();

Now lens do not move out and camera display get dark earlier.

seem the function return immidiate.

So i add a msleep(2000); (see below)

then lens move out and camera shutdown without move in the lens.

Do you know if shutdown() command move in the lens if it is out ?

if yes then camera is crash in function _Rec2PB();

_set_control_event

// Best match: 93%
NSTUB(set_control_event, 0xff89bfe4)

seem a good find.do you know if this work all on S95 ?
If so i can compare the asm source with that, maybe there is something really wrong.

int __attribute__((weak)) switch_mode_usb(int mode)
{
#ifdef CAM_CHDK_PTP
if ( mode == 0 ) {
_Rec2PB();
_set_control_event(0x80000902); // 0x10A5 ConnectUSBCable
} else if ( mode == 1 ) {
_set_control_event(0x902); // 0x10A6 DisconnectUSBCable
_PB2Rec();
msleep(2000);
shutdown();
} else return 0;
return 1;
#else
return 0;
#endif // CAM_CHDK_PTP

Bernd R

I have now remove

//_set_control_event(0x902); // 0x10A6 DisconnectUSBCable
_PB2Rec();
msleep(4000)

and camera crash too as soon the optic is out of camera correct.

what happen on other cam when _set_control_event is not execute ?
maybe the value is wrong for new camera.

or maybe you can tell me a test, to see if _set_control_event work ok.

rudi

reyalp
More likely some entry points (pb2rec, rec2pb, set_control_event) are wrong.

I confirm manual PB2REC and REC2PB for each cam in trunk. For SET_CONTROL_EVENT I make some spot tests, because the code is equal (finsig works fine for that).

@Bernd R
I would use for IXUS1000_100d this addresses:
PB2REC: 0xFF89F73C
REC2PB: 0xFF89DFE4
set_control_even: 0xFF89BFE4

rudi

Bernd R

>PB2REC: 0xFF89F73C
>REC2PB: 0xFF89DFE4
>set_control_even: 0xFF89BFE4

yes, this addresses the IX1000 D Port use

stubs_entry_2.s

NHSTUB(PB2Rec, 0xFF89F73C) // search "AC😛B2Rec"
NHSTUB(Rec2PB, 0xFF89DFE4) //"AC:Rec2PB"

and in stubs_entry.s file

// Best match: 93%
NSTUB(set_control_event, 0xff89bfe4)

but it not work.

« Previous Page Next Page »