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

CHDK PTP interface

  • 1167 Replies
  • 240282 Views
*

Online reyalp

  • ******
  • 11791
Re: CHDK PTP interface
« Reply #790 on: 18 / June / 2012, 00:53:41 »
Advertisements
If there are no objections, I'm going to commit the live view stuff in the trunk tomorrow. I did a merge and batch build today, there were a few issues with the merge but I think I got it all sorted out.

There's still lots to be done to get everything working on the individual cameras, but we can do that over time. The basic functionality should work on pretty much every camera, the additional work is just to handle the frame buffer size variations and get the bitmap stuff right.

I'm not completely happy with the protocol but it should do the job, and I need to stop dithering about it.
Don't forget what the H stands for.

Re: CHDK PTP interface
« Reply #791 on: 18 / June / 2012, 01:11:16 »
If there are no objections, I'm going to commit the live view stuff in the trunk tomorrow.
I'm excited !!!   Are the host clients ready ?
Ported :   A1200    SD940   G10    Powershot N    G16

*

Online reyalp

  • ******
  • 11791
Re: CHDK PTP interface
« Reply #792 on: 18 / June / 2012, 23:33:47 »
Checked in trunk changeset 1921
Are the host clients ready ?
The most recent snapshot of chdkptp should work.

Some general notes

The following ports should have pretty much full support:
a540, d10 g12, g1x, sx40hs, g10, a590, ixus310_elph500hs

Other are mostly missing some combination of viewport dimensions and offsets, active bitmap and palette.

There are several ways to obtain some of these values. Where possible, I'd like to try to use the same method across ports. Early in the process, I ported over some of the palette and viewport stuff from ewavrs original live view code. The viewport stuff was done by directly accessing variables. I've since added eventprocs to the sigfinder that return these values (GetVRAM*PixelsSize) for all dryos cameras. This should be used in preference to accessing the variables directly. I will add the functions to vxworks as well.

Supporting stitch (done in some of the ports mentioned above) requires some logic in each lib.c. Before putting this in every single platform, I'd like to find a way to make it mostly generic. As mentioned earlier, I don't think having this show up correctly in ptp is very urgent.

Where possible, I'd like to move the stuff that is common to all firmwares of a given camera to the common lib.c rather than the sub lib.c. See g12 for an example.

The sig finder finds bitmap and palette stuff for recent dryos. It would be worthwhile to do the same for the older versions.

Protocol documentation is in ptp.h and live_view.h
« Last Edit: 18 / June / 2012, 23:54:43 by reyalp »
Don't forget what the H stands for.

*

Offline philmoz

  • *****
  • 3071
    • Photos
Re: CHDK PTP interface
« Reply #793 on: 18 / June / 2012, 23:52:26 »
Checked in trunk changeset 1921
Huge round of applause - nice job :)

Quote
The following ports should have pretty much full support:
a540, d10 g12, g1x, sx40hs, g10, a590, ixus310_elph500hs
The SX30 works as well.

Quote
The sig finder finds bitmap and palette stuff for recent dryos. It would be worthwhile to do the same for the older versions.
Would be good; but I wasn't able to see any usable patterns for finding this stuff in older DryOS versions.

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)


*

Online reyalp

  • ******
  • 11791
Re: CHDK PTP interface
« Reply #794 on: 19 / June / 2012, 00:04:35 »
Would be good; but I wasn't able to see any usable patterns for finding this stuff in older DryOS versions.
I think the ones I'm using on d10 shouldn't be too hard (especially the bitmap one), but when I was looking at it, I though I found code equivalent code on newer cameras that gave different addresses from what your method is using (or found code equivalent to the new cameras on d10, I don't remember exactly.) I haven't had a chance to look into it further yet.
Not urgent in any case.

edit:
A few more odds and ends
a540 (and presumably some other cameras from the same era) have bitmap 352 (704) width bitmap and viewport. This is treated as 360/720 in most chdk code, and currently the bitmap size returned for live uses the main CHDK value, so the bitmap doesn't line up perfectly.

In the merge, sx200 ended up with duplicate definitions of vid_get_bitmap_active_palette, I removed one. Someone should check that it's still OK

sx220 and sx230 also ended up with conflicting values in stubs_min.S vs stubs_entry.S. I used the stubs_entry ones.
« Last Edit: 19 / June / 2012, 01:02:46 by reyalp »
Don't forget what the H stands for.

*

Online reyalp

  • ******
  • 11791
Re: CHDK PTP interface
« Reply #795 on: 20 / June / 2012, 00:15:30 »
In trunk changeset 1928, I used find_eventproc to add GetVRAM*PixelsSize for all autobuild enabled vxworks cameras except for
a410
a610
ixus40_sd300
ixus50_sd400
ixus700_sd500
ixus750_sd500
ixusizoom_sd30
s2is

I didn't go through and verify all the found values, but they are likely to be OK.
Don't forget what the H stands for.

*

Offline msl

  • *****
  • 1255
  • A720 IS, SX220 HS 1.01a
    • CHDK-DE links
Re: CHDK PTP interface
« Reply #796 on: 20 / June / 2012, 10:52:17 »
Checked in trunk changeset 1921

The following ports should have pretty much full support:
a540, d10 g12, g1x, sx40hs, g10, a590, ixus310_elph500hs

Thanks for that great work! This is a big step for CHDK.

a720 & sx220 work well.

There is a little problem with ptpCamGui. The Gui don't know the new PTP version 2.3 and will not start. Not a big thing. We must add one line. But rudi and me are in vacation. When you need ptpCamGui, use the stable CHDK version. In some days we will update the ptpCamGui.

msl
CHDK-DE:  CHDK-DE links

*

Online reyalp

  • ******
  • 11791
Re: CHDK PTP interface
« Reply #797 on: 20 / June / 2012, 13:10:59 »
a720 & sx220 work well.
Thanks for the report.
Quote
There is a little problem with ptpCamGui. The Gui don't know the new PTP version 2.3 and will not start. Not a big thing. We must add one line. But rudi and me are in vacation. When you need ptpCamGui, use the stable CHDK version. In some days we will update the ptpCamGui.
Minor versions (like 2.0 to 2.3) are supposed to be backward compatible, so it should be safe for ptpCamGui to start if the minor version is greater than what it knows about.

Don't forget what the H stands for.


*

Offline openuas

  • **
  • 57
  • OpenUAS
    • OpenUAS
Re: CHDK PTP interface
« Reply #798 on: 25 / June / 2012, 14:03:18 »
WOW, impressed.  :o One year of no time to be busy with CHDK and now returning to look at changelogdiscovering this improvment is a really pleasant surprise, big thanks to all who work(ed) on this PTP improvement for CHDK  8)

*

Online reyalp

  • ******
  • 11791
Re: CHDK PTP interface
« Reply #799 on: 30 / June / 2012, 17:14:27 »
From philmoz
Quote
Here's a weird one for you.

If I use chdkptp to upload files to the camera (in this case the compiled module files), and the module file length is 5592 bytes, and the filename+path is 24 bytes then the PTP upload crashes the PTP code in the camera. The total data size sent is 5592+24+4 = 5620 bytes.

One byte shorter or longer on the filename and it works fine.

The PTP code gets the correct data_size value but gets the wrong value for fn_len (gets 8 instead of 24).

I've tried using umalloc instead of malloc in the PTP code; but the result is the same.

I've tested this on the G12, SX40 and G1X all give the same result.

Any ideas?
I've reproduced this on a540 and d10. As expected, it also happens with ptpcam.

PTP hangs because the file error (due to incorrect length) is generated before the data phase is complete. If we consumed all the rest of the data, it would probably work OK [edit: no, looks like it already does that]. If you fully reset the connection, it's usable again (try to connect once, it will fail, then connect again). I believe this is mostly a deficiency in error handling in the client code.

I don't yet understand why the length is incorrect... chdkptp is definitely putting the right value in the buffer to send.

edit:
This isn't specific to file upload

Code: [Select]
con> !return con:exec('msg_shell:run()',{libs='msg_shell'})
=true
con> putm exec msg_shell.default_cmd=function(msg) write_usb_msg(msg) end
con 1> !con:write_msg('\24\0\0\0'..string.rep('x',5592+24))
... hangs ...
unexpected return code 0x2ff
con 1> !chdk.reset_device({dev="\\\\.\\libusb0-0002--0x04a9-0x311b",bus="bus-0"})
reset_device: dev \\.\libusb0-0002--0x04a9-0x311b       bus bus-0
Device status OK
___> c
con> getm
... returns message, intact ??? ...
con> !con:write_msg('\24\0\0\0'..string.rep('x',5592+25))
... no hang ...
con> getm
... returns message...
con> !con:write_msg('\24\0\0\0'..string.rep('x',5592+23))
... ok ..
con>  !con:write_msg('\24\0\0\0'..string.rep('x',5592+24))
... hangs ...
:blink:

edit:
the 24 isn't needed,
!con:write_msg(string.rep('x',5592+28))
also fails
« Last Edit: 30 / June / 2012, 18:08:22 by reyalp »
Don't forget what the H stands for.

 

Related Topics