On A710 approx 17 Mbytes without camera crash, but all camera operation at such low memory are very-very slow 
.
Wow. This could be very useful for other things too.
If I understand you correcly (I'm not sure about this even with Google translate ), I tried something like this long time ago, but total time remains the same.
write() waits until write is complete, but I think the actual write is done by SD controller with DMA, so you should be able to use the CPU while it is writing. Since reversebytes takes less time than writing raw, we should be able to reverse some bytes, start those writing, and reverse more while the write is going on. Total time should be almost the same as normal raw.
vxworks has asynchronous IO functions, but I'm not sure if canon implements them or does their own thing.
With "delayed raw" user can review image or prepare next shoot while RAW is written, for serial shooting this option is useless.
Agree, this is a good improvement for general shooting.
For greater speed and to avoid extra code in the camera, it would be better if a separate programme could run on the PC that reversed the bytes and created the headers (and did bad-pixel repair).
I don't think I know enough about programming to do that, certainly not with a GUI.
This should be quite simple compared to most CHDK code. PC is fast enough you don't need special ASM to reverse the bytes, so it's just read CRW, reverse bytes, fix zero pixels (you can re-use the CHDK readpixel/writepixel code) read header info, write everything. I can post code for this if it would be helpful.
For GUI, there are some simple frameworks that do most of this for you.
I have one really irritating problem with the modified CHDK code ..
I am using a previously commented-out entry (number 34) in the conf_info[] array of ConfInfo structures.
This entry is NEVER remembered after turning the camera off.
In trunk CHDK, 34 was renamed, the value is still used:
// CONF_INFO( 34, conf.ns_enable_memdump, CONF_DEF_VALUE, i:0, NULL),
CONF_INFO( 34, conf.debug_shortcut_action, CONF_DEF_VALUE, i:0, NULL), // backwards compatible
Basically 34 was a boolean for +/- dumping memory. I added another option (+/- pages through props/params), but because 0-1 are still valid values that have the same meaning (0 = do nothing, 1 = dump), it didn't need a new conf item. I just renamed the variable to make things clearer.
A batch files would run the reversal command and then join the files to the headers
Yes, you can do this. The reasons I don't like separate headers:
1) 2x the number of files. If you have a lot of files (very long timelapse for example) this affect the camera performance and available memory a lot. Maybe not if you store them outside of the DCIM tree.
2) transfer over PTP becomes more difficult, because you need 2 extension/prefix combinations that work.
3) More risk of losing one part, renaming or deleting one but not the other etc.
BTW, I'm not saying you shouldn't use this, just explaining why I don't like it for CHDK.
