CHDK PTP interface - page 97 - General Discussion and Assistance - CHDK Forum

CHDK PTP interface

  • 1244 Replies
  • 546765 Views
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #960 on: 07 / June / 2013, 17:18:25 »
Advertisements
Is this 4.4.3 toolchain available somewhere?
https://www.box.com/s/2bs0i77srru9d68cy6j5
Thanks. Unfortunately it's x86-64, so I can't currently use it. Can you show the output of
arm-elf-objdump -v
and
arm-elf-gcc -v
?
I wonder whether a toolchain with these binutils and gcc versions will act the same as the autobuild's...

Re: CHDK PTP interface
« Reply #961 on: 07 / June / 2013, 19:41:20 »
arm-elf-objdump -v
Code: [Select]
[build]$ arm-elf-objdump -v
GNU objdump (GNU Binutils) 2.18
Copyright 2007 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

Quote
arm-elf-gcc -v
Code: [Select]
[build]$ arm-elf-gcc -v
Using built-in specs.
Target: arm-elf
Configured with: ../configure --target=arm-elf --prefix=/home/hacki/newenv/ --enable-languages=c --disable-shared --disable-newlib --disable-libssp
Thread model: single
gcc version 4.4.3 (GCC)
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 14128
Re: CHDK PTP interface
« Reply #962 on: 07 / June / 2013, 21:24:18 »
Thanks. Unfortunately it's x86-64, so I can't currently use it.
FWIW, I have a x64 system and a similar generation toolchain I built, so I should be able to check on the pool issue.
Don't forget what the H stands for.

Re: CHDK PTP interface
« Reply #963 on: 07 / June / 2013, 22:04:54 »
I wonder whether a toolchain with these binutils and gcc versions will act the same as the autobuild's...
FWIW ... the values I posted are from the toolchain that hacki uses for the autobuild - or at least they were when he shared them with me.
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #964 on: 08 / June / 2013, 08:32:27 »
I managed to build a 4.4.3 toolchain (thx WW for the config data), and it does show the same pool issue. Looks like it will be a must to use it before committing code that will end up in autobuild.

*

Offline reyalp

  • ******
  • 14128
Re: CHDK PTP interface
« Reply #965 on: 08 / June / 2013, 17:09:47 »
I tried to apply phils patch using tortoise. It didn't really work, there are rejects and files that end up "missing" rather deleted, things that should be added that aren't, and where things are added they of course show up as new files rather copies, so the history will be lost and make a further mess if we try to do merges later. I'm going to try an alternate approach of making a new branch from the trunk and merging over the remote capture changes.

This whole remote capture branch has been a disaster. I am unsure what to do about it. IMO, the current implementation is too much of a mess to accept as is, it should not be in the trunk. It needs significant work both in the protocol and on the client side. However, maintaining an invasive change like this in parallel to other invasive reorganizations in the trunk is wasting a large amount of our time and making the whole thing so frustrating I'm not motivated to work on it. On the rare occasions I actually have a large enough chunk of free time to actually do something, I end up spending it trying to get it up to date rather than working on the actual code.
Don't forget what the H stands for.

Re: CHDK PTP interface
« Reply #966 on: 08 / June / 2013, 18:49:14 »
This whole remote capture branch has been a disaster. I am unsure what to do about it. IMO, the current implementation is too much of a mess to accept as is, it should not be in the trunk. It needs significant work both in the protocol and on the client side.
Easy for me to say this,  but sometimes its just worth chucking the code and using the knowledge gained to start again cleanly?
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 14128
Re: CHDK PTP interface
« Reply #967 on: 08 / June / 2013, 19:21:45 »
Easy for me to say this,  but sometimes its just worth chucking the code and using the knowledge gained to start again cleanly?
I don't think that's the case here. The code we have is stuff we need, there is just more to be done.

The new branch is merge seems to have worked pretty well, I should have it checked in shortly.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14128
Re: CHDK PTP interface
« Reply #968 on: 08 / June / 2013, 20:11:56 »
https://tools.assembla.com/svn/chdk/branches/ptp-remote-capture-test4

This should bring the remotecap stuff fully up to date with the trunk, including the dng changes.

I tested this on my cams and it seems to be working. I rebuilt all the cams with file write hook.

Two minor changes were needed from the test3 branch:

In generic/capt_seq.c fwt_lseek I changed _Lseek to _lseek. This was needed to get a810 to build, since Lseek is marked as unused. On a810 (and from a quick look, most if not all dryos cams), Lseek and lseek are identified with the same address, so this should be OK.

In modules/dng.c I removed fill_gama_buf since it no longer exists in the new dng code.

edit:
Seems I've broken something with DNG capture, works on a540 but on d10 just returns framebuffer dump without header ???

Oops, DNG_SUPPORT went away, didn't actually work on a540, just irfanview was just able to load the framebuffer raw...
« Last Edit: 08 / June / 2013, 21:02:57 by reyalp »
Don't forget what the H stands for.

*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #969 on: 08 / June / 2013, 22:20:08 »
Some thoughts.

CHDK side:
I agree that most of the rc related code looks like an unorganized mess, and is certainly not ready for inclusion. This is mostly a result of my work - I haven't done much beyond changing stuff to make it work.
Some things that I would do to make the mess a little less:
- Remove functionality that is unneeded at this point: YUV. I was going to say DNG too, since the RAW/DNG code has always been file-centered, and I had to butcher an existing DNG function (done in January(?), many things have happened since) to make DNG available for rc.
- Split every possible piece of rc related code into separate files - looks like choosing capt_seq.c for holding the additional code was a bad idea.
- The rc related variables may need reorganization.
- Remove the usage of event procedures. It's AFAIK not needed for rc to work.
- ...?

Client side:
The problem is, any advanced usage of Lua is beyond me, which prevents me from doing any useful work on CHDKPTP.

Seeing the turbulent changes in CHDK trunk, it makes me wonder whether it would have been a better idea to continue development on the stable 1.1 codebase.

I still think that this kind of remote capture support is much better than retrieving the most recently shot image from the card.

 

Related Topics


SimplePortal © 2008-2014, SimplePortal