Is there a way (in compiled C inside CHDK) to determine when it is safe to use the raw buffer as temporary memory?
I remember using exmem several years ago, and I remember it being a pain... is it still?
On the sx530hs, I really need space for at least TWO copies of a live view frame which is 1080x480, or 518,400 bytes. So, I need about 1MB.
Yick. I really want a solution that will just work for any CHDK-capable camera.Although my primary target right now is the sx530hs, I'm also using fleets of elph 160, N, elph 115is, a4000is, and about 6 other models. I don't see exmem support on any of them. I suppose I/my students could add exmem support to all of them, but that still wouldn't take care of the model we don't have. (I believe the exmem support I added years ago was in an A620, and I don't think that the exmem mods ever made it into the regular distribution of CHDK.) The exmem stuff is also a long way to go for 1-3MB; it would be so much nicer to borrow that 24MB raw buffer... which I suppose is also why the Canon firmware does precisely that. In any case, I definitely need to make sure the mods we're doing this Summer make it into the regular distributions this time....
Hmm. Changing data used for unknown purposes sounds like a good way to brick a camera.... Suppose I simply checksum blocks?
By the way, is there any rule for how to make write() as fast as possible -- ideal size, alignment WRT start of file, etc.?
Actually, what value will I see for memory locations that don't exist?
Hmm. Changing data used for unknown purposes sounds like a good way to brick a camera.... Suppose I simply checksum blocks?While I'm at it, I don't see any reason to stop at the end of the framebuffer -- why not do this all the way through EXMEM? Actually, what value will I see for memory locations that don't exist?I'm thinking about doing a checksum probe to make a file that specifies the usable patch(es) and then reading that to build my own extended malloc/free. That might not be a bad solution.... Could even do the check in two steps, checksum probing first and then, only where the initial probe found safe, changing values and repeating the checksum probe. This could be a very clean way to use that memory space as long as Canon isn't really putting it into their own malloc/free infrastructure....For the meantime, I've gotten things to work with only a single 1/2MB buffer... but it's a bit messy, requiring more computation and frequent write() calls. By the way, is there any rule for how to make write() as fast as possible -- ideal size, alignment WRT start of file, etc.?
Started by Leonardo Miguel Delgado « 1 2 » General Discussion and Assistance
Started by NielsN Creative Uses of CHDK
Started by locksinajam General Help and Assistance on using CHDK stable releases
Started by markoneswift CHDK Releases
Started by Lebeau General Discussion and Assistance