I've been reading here about questions regarded uploading hex files, and I was wondering: can we modify the program memory from within code?
I'm under the impression the Arduino has fuses to prevent this except from within the memory space of the bootloader. If so, is there any way we can petition the bootloader team for a snippet of code to do this in the next version, or can the api be exposed to make it possible, or how hard is it to change the fuse for writing?
My reason for this is I'd like to reach the point where revised program code can be passed to clients without them needing the whole tool chain to install it, or use specialty software/hardware - ideally, using a simple tool like many device's 'flash rom' style programs would be ideal.
I've seen some talk about modifying a bootloader to be able to read a new hex file from an SD card directly, but lots about how it's extremely difficult.
I think the simplest method of accomplishing this is just using an entire 2nd micro as a built in dedicated circuit programmer, and have it read a hex file from some other external storage.
From what I can see, the current Optiboot loader takes 512 bytes, freeing up 1.5 Kb of potential bootloader space for normal code. I doubt there is much spare room for extra APIs, and indeed it is a little hard to see how one might work. To reprogram 32 Kb of program memory you would need another 32 Kb (the new code) somewhere, and there is nowhere that large on the chip, which requires at least an additional memory chip.
If my calculations are correct the current loader uses 494/512 bytes, so you only have a handful of spare instructions. To go over that limit makes the bootloader jump in size to 1024 or 2048 bytes.
From what I have read, you can program the fuses to allow code to overwrite any of the program memory, which might possibly help, although you have the danger then that a rogue program could totally corrupt itself.
Another approach might be to simply write your own bootloader, which (space permitting) could see if a new version was available (say on flash RAM) and if so, copy it on top of the old program. Whether you can fit the code to do that (including the file system etc.) into 2 Kb is something you might need to investigate.
Then to install the bootloader itself you simply program via the SPI programming interface (bypassing the bootloader). However as extent said, a second processor which is dedicated to booting the first one, and updating it if required, might be the simplest and cheapest. You would still need the external storage to hold the copy of the new program.
Another not-insignificant benefit of the bootstrapping micro is it would be "brick proof". Power failures, bugs in your main program, corrupted binaries, none of those would permanently kill a device. You would always be able to program your main chip "from scratch" as long as the chip is in physically working condition. If your update routine is in your main program file and anything happens then you're right back to using dedicated hardware to recover it.