Glad to see the continued activity here.
As a result of yardleydobon trying to get CHDK PTP to work on his camera (and specifically him not being able to download JPEGs), I noticed that there is a file size limit to the files that can be downloaded with my original patch/download functionality. I got a maximum of 251312 while experimenting, which seems to relate to USB packet sizes of 256k. As I couldn't find any other mentioning of it, I figured I'd add it here. I guess ewavr also noticed it, seeing his PTP patch.
One additional thing about this: given
Microfunguy's post it seems as if this limit does not hold for his camera (or perhaps VxWorks). Or perhaps he just had a pretty small photo?
As for
the discussion whoever tried to start (and sort of started
later), I would suggest adding CHDK PTP to the trunk in a minimal form. Having a central "standard" interface should avoid too much divergence in patches and tools as well as increase visibility, usage and improvements.
The main question then becomes "what is this minimal form?" Which I'd split into the following questions (mainly based on the patches of ewavr and myself).
Add upload/download?This seems to me as one of the essentials as it provides functionality that isn't available through the firmware PTP on many cameras and is one of the main reasons to extend PTP.
Edit: Regarding downloads and file size limits, there are two options: either use ewavr's method of repeatedly getting parts of the file or, and this would be much nicer if possible, figuring out how the send_data function really works to enable repeated calls (similar to how uploading works).
Add script execution?As this instantly provides access to a great part of CHDK functionality, this also seems a no-brainer. There are two additional questions here, though. First of all, LUA or uBASIC? I'd originally did LUA because it seemed to be the easiest to make and I got the impression that LUA is preferred. However, I've been told that uBASIC is easier for "non-hackers". If someone knows (or makes) a easy way to execute a string containing uBASIC, then I'd think it's easy and cheap to allow both (change
PTP_CHDK_ExecuteLUA to
PTP_CHDK_ExecuteScript and use
param2 to indicate the language).
The other question is regarding the output. Is having it scroll over the camera screen sufficient or do you want to be able to read it out via PTP? In case of the latter, do you store all output in camera memory first or do you send a PTP event for every line (should be nicest, but haven't looked at such functionality).
Add "debugging" features?This includes reading/writing memory, remote calling of functions (by address) and retrieval of props and params. I'm in favour of at least keeping the first two. Both for actual debugging and possibly providing tools with an easy way to extend functionality not available otherwise without having to change CHDK itself (albeit camera specific, unless we have/add a way to resolve function names). For the other two see "Add specific functionality" below.
Add mode switching?I'm not entirely sure about this one, but I suspect it is also covered under the "Add specific functionality" part below.
Add shutdown/reboot?See "Add specific functionality."
Add video settings retrieval?See "Add specific functionality."
Add directory reading?See "Add specific functionality."
Add specific functionality?To minimise extending CHDK PTP indefinitely with more and more useful functionality, I think it is preferable to only do this when there is absolutely no other way. I'm hoping that most of these things can be better implemented as LUA functions and accessed as such via PTP. I think this is at least the case for things like mode switching, shutdown/reboot and directory access.
The only downside to doing things via scripts is that values have to be constantly converted to and from strings. On the other hand, how much data does one expect to be transferred in this way? Big chucks of memory can better be obtained using CHDK PTP "get memory" functionality (meaning some script functions should return pointers).
When should CHDK PTP be enabled?I think the amount of code is pretty small and the code is only used when specific CHDK PTP commands are received. The only side effects are an extra short task at initialisation and one extra entry in the PTP handlers list. I don't really see any objection to having it enabled all the time. That is, as long as it's supported by the camera, which means controlling its addition with defines in
camera.h.
Also, I'd suggest ensuring that CHDK PTP can be enabled with a minimal amount of effort. For example by just adding add_ptp_handler and the one define in
camera.h. The rest of the camera specifics could be covered by trivial default wrappers that just return something such that CHDK PTP knows the functionality isn't implemented. I think this might also be very helpful when porting; one of the first things you do is add the CHDK PTP task and you can already remotely inspect memory and call functions. Add file-operation stubs and you can easily upload new CHDK images without constantly removing and inserting cards.
Well.. that's a bit more text than I anticipated..
To summarise: I'd suggest adding CHDK PTP to the trunk, enabled via
camera.h and consisting of just upload/download, read/write memory, function call and script execution (LUA and uBASIC and preferably with per line output PTP events). The rest (e.g. mode switching, video conf) I'd move to LUA and/or uBASIC.
