..., 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.
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).
Today I intercepted a firmware handler to see how send_data is normally used. It turns out that of the two "size" parameters the first should be the size of the block that is sent with a given call and the second should be the total size. This isn't surprising and I'm pretty sure I tried it, but the trick is that the second size should only be given with the first call (and it should be 0 afterwards). With this it is now possible to nicely download big chunks of data.
B.t.w., I haven't checked it explicitly, but the file size limit I encountered is more likely due to the fact that
malloc fails. The code suggest that this should result in a different error code, but it seems that either USB or the libptp2 code doesn't pass it on.
The two parameters after size appear to be a function/data pointer pair. In the case I tested the function was at
0xff8d222c, which basically consists of a call to
GiveSemaphore. I guess it is called when the transfer is finished. I haven't looked into this any further.
I don't personally see any reason to add ubasic support. If you restrict yourself to doing the things that ubasic can do, an equivalent lua script isn't really more complicated.
Perhaps we can just implement the PTP_CHDK_ExecuteScript and only support LUA at first. This only adds a simple
if and if the need for uBASIC really arises it can be added then.
A further (somewhat OT) thought I've had on scripting is to allow PTP to communicate with an already running script, rather then sending a full script to be executed each time. If you also added a way to send messages back, you'd have a very flexible interface with very little code required.
I've also tried to find a way to send back events today, but was not entirely successful. I did find a function that almost certainly is used for sending events, but I couldn't get it to work. I found it by searching for
0x0000c008. For my IXUS870IS (1.01a) it's at
0xff9f138c. It can also be found by picking the right PTP handler; for example at the end of the
PTP_OC_SendObjectInfo (
0x100C) handler.
The first parameter is most likely the "Event DataSet" (with 4-byte code):
struct { int code, sess_id, trans_id, param1, param2, param3; }. The second parameter seems to hold flags; the two least significant bits each result in a specific function call if set. I've seen the values 2 and 3 for this parameter (mostly 2).
Truly OT:
Why aren't we using a DVCS
