CHDK PTP interface

  • 1149 Replies
  • 174795 Views
Re: CHDK PTP interface
« Reply #20 on: 10 / October / 2009, 19:14:37 »
Advertisements
So I guess VxWorks really only supports one session at a time.

How about disable "Canon Camera Access Library" service (and in extreme case, WIA service) in services applet?
Is there any way the ptpcam code can do that  ?
I think so (see here), but I'm not sure it's the right place. Why not just use a command like 'sc' to do it?

Then again, I'm not sure what the (CHDK extension of) ptpcam is supposed to be. For me it was just a quick and easy way to get something to work. I've been thinking that for a serious interface it is probably better to just link the library functions (in ptp.c) to something like python. This way you are way more flexible and even get a free and advanced interactive prompt.

Re: CHDK PTP interface
« Reply #21 on: 10 / October / 2009, 19:14:46 »
I have looked at the changes for ixus870 101a, they do not look too bad.

Time for bed ... so I will try to add A620 later.

Re: CHDK PTP interface
« Reply #22 on: 10 / October / 2009, 19:22:22 »
p.s. For a710 NHSTUB(add_ptp_handler, 0xFFE59FE4) - and transfer works!
Great!

Quote
But uploading/downloading of files fails - ptpcam reports about unexpected result code, then camera shuts down.
Hmm.. If the code is something like 0x2ff it usually means the camera has crashed; 0x2002 means a less critical error (e.g. alloc failed). Perhaps the functions passed to the handler work a bit different for VxWorks. I deduced their workings by looking at how they were used by handlers for things like PTP_OC_GetObject.

*

Offline ewavr

  • ****
  • 1057
  • A710IS
Re: CHDK PTP interface
« Reply #23 on: 10 / October / 2009, 19:29:41 »
--deleted--
« Last Edit: 11 / October / 2009, 15:30:23 by ewavr »


*

Offline ewavr

  • ****
  • 1057
  • A710IS
Re: CHDK PTP interface
« Reply #24 on: 11 / October / 2009, 15:36:48 »
Hmm.. If the code is something like 0x2ff it usually means the camera has crashed; 0x2002 means a less critical error (e.g. alloc failed). Perhaps the functions passed to the handler work a bit different for VxWorks. I deduced their workings by looking at how they were used by handlers for things like PTP_OC_GetObject.

It was my stupid error - remote filename must begin with 'A/' (not with 'a/') ;)
 

Re: CHDK PTP interface
« Reply #25 on: 11 / October / 2009, 15:52:17 »
It was my stupid error - remote filename must begin with 'A/' (not with 'a/') ;)
Yeah, I fell for that one too... However, it shouldn't really cause a crash. It is likely a problem caused by the fact that one side still expects to send/receive data. Interestingly enough I found that in these cases another function (that comes after get_data_size in ptp_data) than send_resp is used in the A620 firmware (and not in the IXUS 870 IS firmware, as far as I can tell). This might be a solution, but I haven't tried anything out yet.

*

Offline ewavr

  • ****
  • 1057
  • A710IS
Re: CHDK PTP interface
« Reply #26 on: 11 / October / 2009, 16:24:38 »
Yeah, I fell for that one too... However, it shouldn't really cause a crash. It is likely a problem caused by the fact that one side still expects to send/receive data.

No, in my a710
FILE* f=fopen("a/1.txt","wb");
really crashes the camera (and "A/1.txt" not).

Re: CHDK PTP interface
« Reply #27 on: 11 / October / 2009, 16:36:29 »
On my A620 this worked :-

download A/DCIM/100CANON/IMG_0002.jpg    F:/TEST.JPG



Re: CHDK PTP interface
« Reply #28 on: 11 / October / 2009, 16:47:26 »
No, in my a710
FILE* f=fopen("a/1.txt","wb");
really crashes the camera (and "A/1.txt" not).
Ah.. I guess that is the same with my camera then. I think I assumed adding NULL checks would fix it and didn't actually check. I didn't consider the possibility that fopen actually crashes stuff. Perhaps it would be a good idea to add some check in its definition so it behaves more naturally.

*

Offline RaduP

  • *****
  • 890
Re: CHDK PTP interface
« Reply #29 on: 11 / October / 2009, 17:19:28 »
Yeah, I fell for that one too... However, it shouldn't really cause a crash. It is likely a problem caused by the fact that one side still expects to send/receive data.

No, in my a710
FILE* f=fopen("a/1.txt","wb");
really crashes the camera (and "A/1.txt" not).

On my SD980, anything not starting with A/ crashes the camera. That's why I modified open() in wrappers.c to be like this:
Code: [Select]
int open (const char *name, int flags, int mode )
{
if(name[0]!='A')return -1;//on the SD980, it will crash if a file path doesn't start with A
    return _Open(name, flags, mode);//hmm
}

 

Related Topics