I see values in str_list like JPEGBufferFull, JPEGBufferFullForMovie, and JPEGbuf.c, which suggest to me that software is involved somewhere along the line. It's possible I'm misunderstanding where str_list.txt originated.
As reyalp said, it's rather certain that jpeg, mjpeg, h264 are done outside the ARM core, inside the Digic. It may be a HW IP block or a programmable DSP, but either way the buffers (RAW and JPEG) are probably mapped and accessible for both the codec and the ARM core. So it's not at all surprising to find references to those in the ARM firmware -- after all it's responsible of triggering shooting, SD card writing etc.
In some (or all, I wouldn't know) firmwares there exists compressed code that has been guessed to be code for loading to DSP program memory at startup. AFAIK, little has been done to investigate this.
I also looked for documentation of an openshutter() call, but all I could find was open-shutter.bas, which doesn't seem like the same thing.
openshutter() is just a wrapper function defined in multiexp.lua. The required Canon firmware function (for shutter control) is different for dryos and vxworks (as are functions that initialize these functions as event procedures) so I did it that way -- at startup it checks which os the camera in question is running, initializes and defines the functions as
closeproc="CloseMShutter"
and openproc="OpenMShutter"
for vxworks or
closeproc="CloseMechaShutter"
and openproc="OpenMechaShutter" for dryos.
It then uses call_event_proc() to use call these eventprocs.
From my crash, my first guess (without taking a look at the disassembly) I'd guess that Canon's functions do some sanity checking before making things happen with the hardware, and a photo readout in progress seems like a good moment to deny this. If that's the case, the check could possibly be avoided by copying some code, removing sanity checking and executing it instead of OpenMShutter / OpenMechaShutter. Naturally it should be quite clear to everyone that skipping sanity checks is potentially unsafe for the health of the camera.
In a perfect world, PB would stand for "picture buffer", and I'd be on the right track. Can you burst my thought balloon?
In many cases (such as rec2pb) PB definitely stands for playback (play mode, as opposed to rec mode).
If you have a camera with no mechanical shutter (or manage to override it open in CHDK -- this might be possible as we are already replacing some shooting related ASM code with our own) you could build a sturdier external one or have exposure controlled by switching lights on/off (or a flash) in a dark book container box.
Assuming I did that, can you suggest how I'd get a picture from the CCD to the SD? Are existing CHDK commands up to that task, or are "click" and "press" the only things that can currently accomplish it?
No, you'd shoot as usual. Just use exposures long enough and dark enough not to expose anything when you aren't illuminating. And maybe trigger shooting externally to sync with our light sources, or use motion detection as a trigger.
