CHDK PTP interface - page 69 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 ... 64 65 66 67 68 [69] 70 71 72 73 74 ... 125   Go Down

CHDK PTP interface

  • 1244 Replies
  • 532871 Views
*

Offline asmodyne

  • **
  • 50
Re: CHDK PTP interface
« Reply #680 on: 22 / February / 2012, 17:53:47 »
Advertisements
Quote from: ntstatic on 20 / February / 2012, 00:54:56

 unless it breaks the vb runtime specifically, i don't see y it would not break the same utility written in C or C++ too.


Okay, that one's easy : because C++ runtimes are still maintained on x64 platform by MS, whereas VB runtime aren't.  :blink:
As to know why... well... VB7 is .Net, and .Net is obviously still maintained.

Quote from: ntstatic on 20 / February / 2012, 00:54:56
i hardly see the logic in writing a small utility in .net and then expecting for someone to download and install the framework (you would not believe how great of a percentage of my clients still use XP)

There's no more logic in installing the .Net Framework than installing MinGW, Cygwin, or even AutoIT. And as regards coders laziness, I think I've listed in increasing order.  :haha

Quote from: Microfunguy on 20 / February / 2012, 05:25:02

I really hate this lazy reliance on the .Net framework.


Lazy reliance ? It's not laziness, it's pragmatism.

Quote from: Microfunguy on 20 / February / 2012, 05:25:02
It makes it easier for the developer but inconvenient for many users.

Not as much as Cygwin did when I had to install it on a CE platform !!!!  :blink:

Quote from: Microfunguy on 20 / February / 2012, 05:25:02
I prefer to do development on an old PC because it is connected to a large-screen TV and is easier to view than my modern system.

Seriously ? Each an every PC I use in my workshop are old junks picked from the scrapyard and refurbished by yours truly, and they still run on XP. What is this PC of yours ? a 386 ?

Quote from: Microfunguy on 20 / February / 2012, 05:25:02
There are a number of applications I will not run because of the bloat the .Net framework would add.

  ??? seriously ???
A bloat ?

Quote
Quote

 (you would not believe how great of a percentage of my clients still use XP)


I believe it, I do.


I believe it, and see it everyday too. I even repaired a PC running on 98SE last month...  :D
No kidding, I did ! It's a remote area here, many people still use Win98.

And, I think their main reason is the same as Microfunguy's, who said :

Quote from: Microfunguy on 20 / February / 2012, 05:25:02

I see no reason to change, it does not cause me any problems, just the opposite.


Well, that's a point of view, not a unalienable truth. Thing is, you can't rely on a old TECHNOLOGY because the new one is more TECHNOLOGIC. Doesn't make sense.
VB7 over VB6 is an improvement.
iPhone over PockedPC is a commercial scam.
Win7 over WinXP is a "$hIt, my 10 yo trident graphic card's burnt, are those nVidia things compatible with ISA bus" ? ... see what I mean ?  ::)



Fact is, I don't encounter much .Net apps when it comes to applications targeting wide audiences (except for most of the XBox Live indies).
But I do when it's "by coders for coders" stuffs, and proprietary industrial automation. Again, pragmatism : MS platform now have the .Net framework embedded into it.


« Last Edit: 22 / February / 2012, 17:57:21 by asmodyne »
Logged
*

Offline reyalp

  • ******
  • 14125
Re: CHDK PTP interface
« Reply #681 on: 22 / February / 2012, 23:04:42 »
Please take this discussion of VB, XP etc somewhere else. This thread is for discussion of the PTP extension.

Getting back on topic:
I've finally got live view working enough in chdkptp that I can work on the protocol. The CHDK side of this is in a branch http://trac.assembla.com/chdk/browser/branches/reyalp-ptp-live but will probably move it back to the trunk once I've got a few things sorted out. This is based on philmoz work from http://chdk.setepontos.com/index.php?topic=4338.570

If you want to play with it, you can build chdkptp with CD_SUPPORT=1 and LIVEVIEW_SUPPORT=1 defined in config.mk (and the CD libraries in place). I'll put up a binary build of this soon. This is still very rough, it should generally display something, bit it will probably break on screen layouts different form my cameras. It currently only supports the style of bitmap palette used on a540.

Some initial thoughts:
- I think GetHandler is redundant. We need a well known number to identify the handler, and all the handler is to the client is an opaque number. So just use the well known number to start with.
- There seems little value in differentiating the "fixed" data (LV_TFR_CORE_DETAILS) vs the per frame data. If you are fetching 200kb framebuffer, having a few extra ints in there isn't going to make much difference. Forcing clients to be prepared for anything to vary frame-to-frame will help us if any of the stuff that we thought was fixed turns out to be variable on some camera. 
- The frame buffer parameters need some work. More on this in another post, I'm still trying to get my head around it...
Logged
Don't forget what the H stands for.
*

Offline Pier

  • ***
  • 128
Re: CHDK PTP interface
« Reply #682 on: 23 / February / 2012, 06:22:20 »
@reyalp,
I don't understood whether above link and all the files there are related to CHDKPTP in
this tread http://chdk.setepontos.com/index.php?topic=6231.0 or not.
Can't find in the ziped files/folders/files  CD_SUPPORT=   and LIVEVIEW_SUPPORT=   to try with my SX130.
Maybe this is only for developers.I can't get along build with CHDK-SHELL if there in core folder are Modules.Diskboot.bin is not complete..I think..?? Pls excuse me - nooby in programming..
I made short test- CHDKPTP with Gui and cli r160 and it's doing well on this stage.
« Last Edit: 23 / February / 2012, 06:25:13 by Pier »
Logged
*

Offline asmodyne

  • **
  • 50
Re: CHDK PTP interface
« Reply #683 on: 23 / February / 2012, 16:12:27 »
Quote from: reyalp on 22 / February / 2012, 23:04:42

I've finally got live view working enough in chdkptp that I can work on the protocol.

 
Sweet !  :)

Quote from: reyalp on 22 / February / 2012, 23:04:42

The CHDK side of this is in a branch http://trac.assembla.com/chdk/browser/branches/reyalp-ptp-live but will probably move it back to the trunk once I've got a few things sorted out.


Does this mean your code only concern the A540 platform ?  ;)

I can't wait to see a new set of Chdk PTP subcommand to request a live PTP feed (even if it will be rough to achieve it without an isochronous endpoint.) The trunk would need to implement something bigger than the tiny 64 bytes bulk endpoints I see on the A430  :haha). But anything different from bulk would make us step out of the PTP domain, right ?

[addendum]

So far, the open-source library stem I'm implementing has its "ChdkDevice" objects implementing two separate interfaces, namely : IPtpDevice, which sticks to the PIMA 15740 USB variation by offering the basic PIMA15470 opcodes set, and IChdkDevice which offers CHDK-specific methods, such as "SwitchMode()", "ExecuteLuaScript()" or "InstantSnap()", etc...
So I'm eager to read about your future work.



« Last Edit: 23 / February / 2012, 16:20:32 by asmodyne »
Logged
*

Offline asmodyne

  • **
  • 50
Re: CHDK PTP interface
« Reply #684 on: 23 / February / 2012, 16:22:24 »

I should post a class hierarchy graph from my current work progress in the next few weeks... if anyone is interested ?  :-X
Logged
*

Offline reyalp

  • ******
  • 14125
Re: CHDK PTP interface
« Reply #685 on: 23 / February / 2012, 16:29:00 »
Quote from: Pier on 23 / February / 2012, 06:22:20
Maybe this is only for developers.
Exactly. CD_SUPPORT and LIVEVIEW_SUPPORT are makefile variables in the chdkptp source, not files anywhere.

As I said before, I'll try to put a binary build of chdkptp soon.

Quote from: asmodyne on 23 / February / 2012, 16:12:27
Does this mean your code only concern the A540 platform ?  ;)
Most of it is generic, but there will be platform specific issues, and some code will need to be added to most CHDK ports for full functionality.

Quote
The trunk would need to implement something bigger than the tiny 64 bytes bulk endpoints I see on the A430  :haha). But anything different from bulk would make us step out of the PTP domain, right ?
As I explained before, this is a low level detail outside of the scope of anything CHDK interacts with or modifies. Whatever reason mweerdens code checked it is not directly related to this functionality. If file download works, then we can transfer framebuffer data too, there's no difference as far as the low level USB stuff goes.

It looks like the a430 might be USB 1.x, rather than USB 2.0. That might explain the difference in the endpoint size (IIRC USB 2.0 requires a certain minimum size). If this is the case, then the maximum frame rate will be lower, and CHDK certainly cannot change this.
Logged
Don't forget what the H stands for.
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: CHDK PTP interface
« Reply #686 on: 23 / February / 2012, 16:33:32 »
Quote from: asmodyne on 23 / February / 2012, 16:12:27
I can't wait to see a new set of Chdk PTP subcommand to request a live PTP feed

As a matter of interest, what application do you have that requires the live feed ?
Logged
*

Offline asmodyne

  • **
  • 50
Re: CHDK PTP interface
« Reply #687 on: 23 / February / 2012, 18:13:17 »
Quote from: Microfunguy on 23 / February / 2012, 16:33:32

As a matter of interest, what application do you have that requires the live feed ?


I have no specific application to use live feed in (I don't even own a Canon device that would handle it). I'm just thinking that adding this functionality to the existing CHDK PTP extension subcodes would be the best way to have uniform live-feed implementation over every platform supporting USB 2.0, rather than distinct implementations and protocols for each platform.
Logged
*

Offline reyalp

  • ******
  • 14125
Re: CHDK PTP interface
« Reply #688 on: 23 / February / 2012, 23:17:31 »
Quote from: asmodyne on 23 / February / 2012, 18:13:17
I have no specific application to use live feed in (I don't even own a Canon device that would handle it).
Does CHDK file download work on your camera ?

If you actually can't run live view, then I certainly don't see how you'd successfully develop a client library.
Quote
I'm just thinking that adding this functionality to the existing CHDK PTP extension subcodes would be the best way to have uniform live-feed implementation over every platform
This has always been the plan. However, getting the appropriate data for each camera necessarily requires some new code in the ports. There's no way around that, Canon has used different frame buffer layouts etc on different cameras.
Quote
supporting USB 2.0, rather than distinct implementations and protocols for each platform.
USB 2.0 is irrelevant. As I've repeatedly tried to tell you, CHDK PTP code know doesn't or care about anything at that level.
Logged
Don't forget what the H stands for.
*

Offline asmodyne

  • **
  • 50
Re: CHDK PTP interface
« Reply #689 on: 25 / February / 2012, 08:03:33 »
Quote from: reyalp on 23 / February / 2012, 23:17:31
Quote from: asmodyne on 23 / February / 2012, 18:13:17
I have no specific application to use live feed in (I don't even own a Canon device that would handle it).
Does CHDK file download work on your camera ?

Okay, I have 24 pics on the A430, let me test it... ptpCam gets it @390 kB/s and chdkptp...gets them...ish
(it stops randomly depending on what I do to the GUI though).



Quote from: reyalp on 23 / February / 2012, 23:17:31

If you actually can't run live view, then I certainly don't see how you'd successfully develop a client library.


Well I do have an A2000IS at hand, but I got it for 5€ for it has broken lens and misses a focus cogwheel, so I'll have to wait for the replacement optics to be delivered. I have good hope that the A2000IS and its Digic 3 will allow live view,  :'( ... it's still a hope though.  :-X

Quote from: reyalp on 23 / February / 2012, 23:17:31
Quote
I'm just thinking that adding this functionality to the existing CHDK PTP extension subcodes would be the best way to have uniform live-feed implementation over every platform
This has always been the plan. However, getting the appropriate data for each camera necessarily requires some new code in the ports. There's no way around that, Canon has used different frame buffer layouts etc on different cameras.

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.
You may also consider extending the Ptp events with some Chdk cases, for synchronisation purposes.
Shame is, I didn't had/take the time to dwell into the CHDK code deeply enough to do it myself, 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.


Quote from: reyalp on 23 / February / 2012, 23:17:31
Quote
supporting USB 2.0, rather than distinct implementations and protocols for each platform.
USB 2.0 is irrelevant. As I've repeatedly tried to tell you, CHDK PTP code know doesn't or care about anything at that level.

So, the endpoints MaxPacketSize(s) are platform-dependant ? Nothing the CHDK can fiddle with ?
Logged
Pages: 1 ... 64 65 66 67 68 [69] 70 71 72 73 74 ... 125   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal