why the buffer in mpu_recv_log() is updated by mpu_recv() after the buffer is already decoded?
Shouldn't it be updated in advance to log the current msg?
In Canon code, this function is called indirectly (a pointer to it - mpu_recv_cbr - is stored to RAM) whenever a message is received from the MPU, so we have replaced that pointer with one to our own function (mpu_recv_log). Our function prints the message in Canon's log file, then calls Canon's function to process the message. So, it keeps the original functionality (whatever Canon code is supposed to do with each message from the MPU) and it logs each call. The protocol is
documented here.
And is there a reason why the argument "size" of mpu_recv_log() is not used, but the [-1]-Hack to get the size, although at [ 0 ] is always the encoded size, or is this not always the case?
From the above link, mpu_recv gets a pointer to payload_size (second char in the message), so it happens that buf[-1] is still available for reading. It's not really necessary to capture it though; payload_size is enough to interpret the messages. The logging code was written before we understood the message format (it was adapted from
here), and it was done that way to match the format from mpu_send (which receives a "full" message, with two size arguments).
But you are right, message_size can be dropped without any loss of information (now that we know the the first two parameters are always redundant). It would require updating
mpu.c (to add logic for message_size, rather than just replaying it),
extract_init_spells.py and any other scripts that parse this kind of logs, though. And, of course, a script for updating any old logs to the new format.
BTW - nice to see others reading the low-level code and trying to understand what's going on.
Forgot to mention - since the code from the digic6-dumper branch is now able to dump the RAM while running Canon firmware, here's an easy coding task: find the image buffer addresses (Canon menus, overlays, LiveView image) in the RAM dump.
I didn't look into it yet, so can't give many hints right now, but I'm pretty sure the image buffers should be somewhere in RAM, and CHDK folks already documented the image format.
