I started to move code from generic/capt_seq.c to core/remote_capture.c in a temporary repo
( https://subversion.assembla.com/svn/chdk-s1.remotecapture/ ).
I started doing something similar when I tried to put the init stuff in Lua cleanly, ran into similar issues and ran out of time before I got to the point of having anything to check in.
I changed some from static to volatile (to be able to access them from multiple source modules), and I created "setter" and "getter" functions for some others.
I'd say getters/setters is probably cleaner, neither one is really safe to communicate across tasks, but for simple state variables it should be OK. Overall, the current code (in remote-capture-test) is quite convoluted with the different globals and statics. I think it can be made much more modular, but it's a bit tricky.
I'm not completely sure about naming the new file "remote_capture.c", because the filewritetask hook could possibly be used for more.
Agreed. The direction I was going was to have minimal filewrite_main_hook in capt_seq.c which currently just called into the remote capture code, but could have other stuff later.
To do the separation, I had to move the declaration of the struct "cam_ptp_data_chunk" into platform_camera.h. As platform_camera.h only holds #define's in current CHDK code, this looks pretty ugly to me.
"cam_ptp_data_chunk" may turn out to be the same in a large number of camera generations, but this is only a suspicion.
If there is only one known variant, it might be better to just start out assuming it's always that way, and deal with it later if it turns out not to be. If there are only a few variants, they are likely to correspond to DryOS revs (old vxworks like a410 and more recent like a540 seem to be the same), so you could just have a few different ones using existing DryOS ifdefs.
In my code, started putting in a function to copy from the platform defined one into the generic one in generic/capt_seq.c
My later plan includes using the dng module to get the CHDK exif (optionally).
I'm not sure it's even worth making this optional, if the client doesn't want it they can just throw it out.
On question does arise, if you do a sub-image, what dimensions go in the header ?
Another thing I noticed trying to work on the init stuff is that startline, numlines could have different possible values for raw vs YUV (raw buffer being a bit bigger than max size jpeg, and jpeg potentially being lower res.)
Have you found / verified that a YUV buffer is actually available ? If not, maybe V1 should just be jpeg and raw, and not worry about any of the YUV stuff for now.