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

CHDK PTP interface

  • 1244 Replies
  • 546554 Views
Re: CHDK PTP interface
« Reply #690 on: 25 / February / 2012, 08:37:46 »
Advertisements

I think the CHDK Ptp extension needs a few new subcodes
I didn't had/take the time to dwell into the CHDK code deeply enough to do it myself, but if I did

aaahhhh  .... yes ... of course you would.

Re: CHDK PTP interface
« Reply #691 on: 25 / February / 2012, 12:08:18 »

I think the CHDK Ptp extension needs a few new subcodes
I didn't had/take the time to dwell into the CHDK code deeply enough to do it myself, but if I did

aaahhhh  .... yes ... of course you would.

Are you Is he always this denigrating and condescending to others ?  :blink:

*

Offline Pier

  • ***
  • 128
Re: CHDK PTP interface
« Reply #692 on: 25 / February / 2012, 12:56:21 »
asmodyne,
Do not you think it is time to dwell into the CHDK code deeply enough, as you said.
And then came back and be so kind to tell us what you did.
10x

Re: CHDK PTP interface
« Reply #693 on: 25 / February / 2012, 13:34:46 »
Are you Is he always this denigrating and condescending to others ?  :blink:
actually,  you caught him on a good day ::)
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline reyalp

  • ******
  • 14128
Re: CHDK PTP interface
« Reply #694 on: 25 / February / 2012, 15:13:09 »
I'm aware of that. As a matter of fact, I think the CHDK Ptp extension needs a few new subcodes, something like :
  • GetFrameBufferDesc which would return a frame buffer structure and layout description structure as a ptp data payload.
  • BeginLiveView (or whichever name you give it), which start the VF stream
  • AbortLiveView (note : same as above), which stops the feed.
If you want to contribute to this in a meaningful way, you'll need to familiarize yourself with what is actually being done. FWIW, one of the complications is the that the frame buffer characteristics change at runtime depending what the camera is doing. That's why many of them are included in each frame (and I'm leaning to just sending them all every frame)

Begin and Abort are meaningless, for reasons described below...
Quote
Shame is, I didn't had/take the time to dwell into the CHDK code deeply enough to do it myself
This limits your ability to meaningfully participate in the discussion.
Quote
, but if I did, things like Script execution status or memory exchange controls would be implemented as device's ptp EVENTS, not polled commands. As far as I know, ptpCam doesn't even USE the interrupt endpoint, although can MUST have it implemented on every device, meeting protocol standards.
If you reverse engineer the camera stack enough to do this, we certainly might be interested. At the moment, we don't have this capability, and polling is good enough.

Keep in mind that if your implementation requires new entry points or other addresses in the firmware, they need to be found for >100 camera variants.
Quote
So, the endpoints MaxPacketSize(s) are platform-dependant ? Nothing the CHDK can fiddle with ?
Nothing that CHDK currently fiddles with. We use the cameras PTP stack, we don't talk to the low level USB stuff. It might be doable, but there's no obvious need... if your camera is USB 1.1, changing the packet size isn't going to help your transfer rate that much.
Don't forget what the H stands for.

Re: CHDK PTP interface
« Reply #695 on: 25 / February / 2012, 15:33:32 »
asmodyne,
Do not you think it is time to dwell into the CHDK code deeply enough, as you said.
And then came back and be so kind to tell us what you did.
10x

I would have though the strength of a community's workforce is the eclecticism of its members area of knowledge (work compartmentalization, anyone ?).
I've seen enough references about selfish uses of CHDK-DE in this forum to know that me, diving into the trunk implementation, won't bring anything more to the CHDK circle.
Beside, I already obtained what it needed from the PTP interface two day ago: quick instant snapshots in an easy-to-read format, the whole thing using LibUsbDotNet and C#.
Since reyalp is working on the live view implementation and is willing as I am to have it working in the trunk, I don't see why I wouldn't offer some time to implement a managed API to access it.

I said I would have made the scripts status report through the interrupt ep. Would.
The CHDK ptp 2.0 is working fair enough as it is, so we move on. For now, I'm following reyalp's workline, and implement a managed library around what's already existing and will appear as a generic feature on the trunk.


One last bit of information, since some lads enjoy poking my pride : I've already worked on ARM7 and ARM9 cores in asm and C.
ARM7 was for the time I developped GameBoy Advance game. ;)
Now, I'm using a mini2440 (ARM920T) in os'less mode as a PLC, since its 1.3MP camera interface was what made me decide to buy it. But experimentations brough me to the conclusion that 1.3MP are too small a resolution, and those nasty pinhole lenses made me wonder for pictures a bit more...sharp and exposed  :'(. Hence my interest in CHDK. See the path I took here ?
So please, do know I'm sorry if I take your advice about "dwelling into the CHDK code" as mere attempt to boast.  :-X

Quote
    Shame is, I didn't had/take the time to dwell into the CHDK code deeply enough to do it myself
This limits your ability to meaningfully participate in the discussion.

I know. But having read the whole PIMA-15740 2000 and its USB implementation in the pass past
2 weeks make me a bit dizzy for now. :blink:
I'll dive in, promise  :P
(where should I start reading if I want to understand you live-view code btw ? The A540 sub in the repository link you gave earlier,  is that it ?)

Quote
So, the endpoints MaxPacketSize(s) are platform-dependant ? Nothing the CHDK can fiddle with ?
Nothing that CHDK currently fiddles with. We use the cameras PTP stack, we don't talk to the low level USB stuff. It might be doable, but there's no obvious need... if your camera is USB 1.1, changing the packet size isn't going to help your transfer rate that much.

Eyup. The bottleneck would be the bitrate itself.
I see. So it solely relies on the mechanism mweerden describes: registering extraneous/extern handlers to ptp commands, right ?
Thus the immuable device's USB config. Makes sense.

*

Offline reyalp

  • ******
  • 14128
Re: CHDK PTP interface
« Reply #696 on: 25 / February / 2012, 15:55:23 »
where should I start reading if I want to understand you live-view code btw ? The A540 sub in the repository link you gave earlier,  is that it ?)
The chdk side is currently in http://trac.assembla.com/chdk/browser/branches/reyalp-ptp-live

The PC side is in http://trac.assembla.com/chdkptp/browser/trunk

It is not A540 specific, although obviously I'm working with the cameras I have before worrying too much about others. The basic live view should work on most cameras. Getting things like the UI overlay and exactly the right display and aspect rations etc will require additional work on most cameras.

Quote
I see. So it solely relies on the mechanism mweerden describes: registering extraneous/extern handlers to ptp commands, right ?
Exactly. You need to appreciate that CHDK is hack. It's based on reverse engineering and manipulating the internals of a completely undocumented system. So often the approach taken is not the one you would think is "best" in normal design terms or based on reading specifications. Furthermore, as I mentioned before there is a very large number of platforms, so even if a "better" way is discovered, it may not be pursued if implementing requires a lot of work on each camera.
Don't forget what the H stands for.

Re: CHDK PTP interface
« Reply #697 on: 25 / February / 2012, 16:39:48 »

It is not A540 specific, although obviously I'm working with the cameras I have before worrying too much about others. The basic live view should work on most cameras. Getting things like the UI overlay and exactly the right display and aspect rations etc will require additional work on most cameras.


Okay then. What made me think your work on live view was relying on A540 was the "reyalp-ptp-live" and "live view ...smtg  :-[" in the "comments/description" column of the repository browser. I (stupidly) assumed you were using platform-dependant hardcoded offsets as where to fetch the frame buffer.
But that was before I fully read mweerden's work on ptp handler's registration.
I'll try to fetch download and compile it as soon as the Assembla's 503 error page's gone (it's maintenance time  ::) ).

« Last Edit: 25 / February / 2012, 16:41:59 by asmodyne »

*

Offline reyalp

  • ******
  • 14128
Re: CHDK PTP interface
« Reply #698 on: 25 / February / 2012, 16:48:42 »
Okay then. What made me think your work on live view was relying on A540 was the "reyalp-ptp-live" and "live view ...smtg  :-[" in the "comments/description" column of the repository browser. I (stupidly) assumed you were using platform-dependant hardcoded offsets were to fetch the frame buffer.
Of course I am, the offsets *are* platform dependent, and since they are found by reverse engineering, they are generally hardcoded somewhere, or pulled from variables in the camera which are themselves platform dependent. See platform/<camera>/lib.c, platform/camera_platform.h and platform/<camera>/sub/<version>/lib.c

However, the basic frame buffer addresses and characteristics are already known for all complete ports, since they are required for histogram, zebra, md etc. There are some additional characteristics and special cases required for live view which that are *not* already in the code, and these will have to be added for each camera to enable full functionality. There is no way around this.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 14128
Re: CHDK PTP interface
« Reply #699 on: 26 / February / 2012, 03:05:18 »
As I said before, I'll try to put a binary build of chdkptp soon.
This is done, see here http://chdk.setepontos.com/index.php?topic=6231.45

Note that this currently requires a CHDK build from my branch.
Don't forget what the H stands for.

 

Related Topics


SimplePortal © 2008-2014, SimplePortal