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

CHDK PTP interface

  • 1227 Replies
  • 372863 Views
*

Offline srsa_4c

  • ******
  • 4426
Re: CHDK PTP interface
« Reply #950 on: 08 / April / 2013, 21:24:56 »
Advertisements
I would like to "land" the remote cap branch fairly soon.
Would it make sense to implement querying/reporting camera related quirks, so that the client can take appropriate measures to avoid known problems?
I'm thinking about
- the USB transfer size related bugs (this is not really remote capture related)
- this (the a470 seems not to be affected for example):
I've also had weirdness / failed connections when the camera goes into powersave mode.
- when the camera can't tolerate remote shooting in too fast succession (ixus870)
- ...

*

Offline reyalp

  • ******
  • 13393
Re: CHDK PTP interface
« Reply #951 on: 18 / May / 2013, 17:53:00 »
Moved from the chdkptp thread

FWIW, one of my long term ideas for PTP is to expose file operations like read(), write() etc directly in the PTP protocol (without lua). This should make write a FUSE (and/or gvfs) module for CHDK cameras quite easy, which would allow linux systems to effectively mount the entire filesystem. If anyone wants to have a go at this, I have some ideas...

from some discussion in irc
the way I imagine the chdk side working is there would be ptp opcodes for the basic operations fuse expects. I'm not totally sure what those are, but I guess open, read, write etc
open / close present some problems because of the limited number of filehandles available on the cam
you'd probably want to store your own structure on the cam and only open when needed


A further issue is that there can only be one connection to a camera, so if the fuse module talked ptp directly to the camera, you would not be able to use other clients. The "right" solution to this would probably be a daemon that handles all the PTP communicaton, and the fuse module and clients would talk to the daemon.

The low level file operations would be useful even without the fuse portion.
« Last Edit: 18 / May / 2013, 17:57:21 by reyalp »
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4426
Re: CHDK PTP interface
« Reply #952 on: 19 / May / 2013, 10:47:07 »
A few potential PTP issues:

- PTP (or the whole USB subsystem) gets shut down somehow when the number of "camera objects" grows beyond a certain limit. This might be related to that "communication error" message which is mentioned in the manual (I personally have not seen it yet). This is not directly file system related, I managed to trigger it by doing 8k shots with JPEG disabled. (a410, the camera could not even start the "erase all" operation in the Canon menu afterwards).

- at least on DryOS cameras, a certain amount of exmem (1MB in cases I've seen) gets allocated when usb is connected which may or may not interfere with record mode.

In a separate note, recent trunk changes can't be easily merged into the v3 remote capture branch. I was able to - sort of - merge it into current trunk code, with the exception of platform *.S files, but I would need a full rebuild with all fw dumps to correct it. The usual "cherry-picking" method seems more painful.

For fuse, there's this: http://www.gphoto.org/proj/gphotofs/

*

Offline reyalp

  • ******
  • 13393
Re: CHDK PTP interface
« Reply #953 on: 19 / May / 2013, 15:22:07 »
- PTP (or the whole USB subsystem) gets shut down somehow when the number of "camera objects" grows beyond a certain limit. This might be related to that "communication error" message which is mentioned in the manual (I personally have not seen it yet).
Yes, I saw the "communication error" when I was chasing the Lua bug. It's annoying, would be nice if we could block the camera from whatever triggers this. I guess building the list of PTP objects?

Quote
- at least on DryOS cameras, a certain amount of exmem (1MB in cases I've seen) gets allocated when usb is connected which may or may not interfere with record mode.
Yes, EXMEM_COM is in the firmware exmem view output.

At a minimum, the cameras that have quality issues when CHDK is in exmem will probably suffer the same problem. Worse if CHDK is already in exmem.

I wonder if video recording clobbers the EXMEM_COM section like it does CHDK allocations? If not, maybe we can figure out how. And if it does, I assume PTP will become very unreliable if you try to record video
Quote
In a separate note, recent trunk changes can't be easily merged into the v3 remote capture branch.
Yeah, would be good to land this branch soon. I'll try to have a look at updating.

Quote
For fuse, there's this: http://www.gphoto.org/proj/gphotofs/
Yes, this sort of thing is what brought up the discussion in the first place. The idea is to expose the full filesystem, vs what is already accessible via regular PTP. Also, as I mentioned earlier it would be a lot more flexible than the current options. However, this isn't something I think is urgent to do now, it's just an idea that I've had kicking around for a while. I posted it here because nafraf expressed some interest in working on it.
Don't forget what the H stands for.


*

Offline srsa_4c

  • ******
  • 4426
Re: CHDK PTP interface
« Reply #954 on: 19 / May / 2013, 16:27:06 »
Yes, I saw the "communication error" when I was chasing the Lua bug. It's annoying, would be nice if we could block the camera from whatever triggers this. I guess building the list of PTP objects?
I don't know how these object representations are related (the camera's internal list of its known files vs the same for ptp). If my memory is correct, the camera hasn't even shown up as USB device when plugged in, so it got overwhelmed before any ptp connection attempt.
Unfortunately this part of the firmware seems rather complex (lots of related tasks). I have only one idea that could provide some help in certain cases: if that "erase all" routine is found, it could be run once for like every few hundred images - only usable if remote shooting OR when the saved files are redirected (in filewritetask) to a path the camera doesn't know.
Quote
Yes, EXMEM_COM is in the firmware exmem view output.

At a minimum, the cameras that have quality issues when CHDK is in exmem will probably suffer the same problem. Worse if CHDK is already in exmem.

I wonder if video recording clobbers the EXMEM_COM section like it does CHDK allocations? If not, maybe we can figure out how. And if it does, I assume PTP will become very unreliable if you try to record video
PTP acts unstable on certain cameras (regardless of movie recording), but I have no clue why, I can never reproduce.
Quote
I'll try to have a look at updating.
Not too important at the moment, I mentioned it as a hint why I haven't done the update.

*

Offline reyalp

  • ******
  • 13393
Re: CHDK PTP interface
« Reply #955 on: 19 / May / 2013, 16:31:11 »
If my memory is correct, the camera hasn't even shown up as USB device when plugged in, so it got overwhelmed before any ptp connection attempt.
When I got the "communication error" it appeared when plugging the camera in, and the camera was not recognized at all on USB.

I think one time when I left it running (taking 10k shots) while plugged into ptp it also died (without showing communication error), but I don't remember the exact symptom  :-[
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3332
    • Photos
Re: CHDK PTP interface
« Reply #956 on: 31 / May / 2013, 21:31:49 »
In a separate note, recent trunk changes can't be easily merged into the v3 remote capture branch. I was able to - sort of - merge it into current trunk code, with the exception of platform *.S files, but I would need a full rebuild with all fw dumps to correct it. The usual "cherry-picking" method seems more painful.

The attached patch should bring the branch up to the trunk-2822 revision.

It builds for all cameras, and runs on my G1X; but I haven't implemented the ptp-remote extensions so I can't test that part.

I was able to build for all cameras using GCC 4.6.2 (on Windows).
However on the Linux environment I have set up with hacki's 4.4.3 toolchain it fails on some cameras. For example the A495 capt_seq.c file gives the error below:
Code: [Select]
/tmp/ccxjW2Jc.s: Assembler messages:
/tmp/ccxjW2Jc.s:166: Error: invalid literal constant: pool needs to be closer
/tmp/ccxjW2Jc.s:175: Error: invalid literal constant: pool needs to be closer
/tmp/ccxjW2Jc.s:176: Error: invalid literal constant: pool needs to be closer
make[2]: *** [capt_seq.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [batch-zip-complete] Error 1

I suspect the source file is too big and will need to be split up.

Phil.
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)

*

Offline reyalp

  • ******
  • 13393
Re: CHDK PTP interface
« Reply #957 on: 31 / May / 2013, 22:12:14 »
a .pool in the ASM will probably resolve that error. http://sourceware.org/binutils/docs/as/ARM-Directives.html

You will have to arrange to jump over it if it's in the normal flow of code.

edit:
and thank you very much for doing that.
« Last Edit: 31 / May / 2013, 22:13:53 by reyalp »
Don't forget what the H stands for.


*

Offline srsa_4c

  • ******
  • 4426
Re: CHDK PTP interface
« Reply #958 on: 01 / June / 2013, 21:13:10 »
I don't get these "pool needs to be closer" errors using my 4.5.1 and 4.6.4 toolchains. Is this 4.4.3 toolchain available somewhere?

and thank you very much for doing that.
+1

BTW, it might be my fault, but patch generated 0 sized files instead of removing those. I've removed all CRs from the patch before applying, maybe that's why.

Re: CHDK PTP interface
« Reply #959 on: 01 / June / 2013, 22:06:06 »
Ported :   A1200    SD940   G10    Powershot N    G16

 

Related Topics