Yes, but writing to flash (program memory) at runtime isn't really a desirable thing to do. Sure, we can be open about it. But if you do it 10 times a day, and the flash can be written to 10,000 times, your app will fail after 3 years.

And if you write the EEPROM 100 times a day it will fail too.

The idea is to design for that (by minimizing writes, wear-levelling...etc).

(by the way, found the error you were mentioning... a missing right parentheses - in MemoryFree.cpp):this: return (FLASHEND - 8191 - SketchSize();should be this: return (FLASHEND - 8191) - SketchSize();

OK... for the MEGA 2560, my IDE (version 1.0.1) says the sketch is 4,046 bytes. The MEGA has 242144 bytes minus 8K for the bootloader is 253952 bytes. Subtract 4046 from that (the sketch size) and you get 249906 bytes which is what the code reports.

Of course, *MY* mega board has a 2K bootloader instead of an 8K bootloader and in reality I have 6K more free, but the MemoryFree code doesn't know that (as expected).

I'll try to stuff a lot of PROGMEM into the MEGA and see how much works!

Instead of thinking all the things you shouldn't do and 'just saying no', what about the things reasonable that may deserve a 'yes'? An open approach instead of closed?

Yes, but writing to flash (program memory) at runtime isn't really a desirable thing to do. Sure, we can be open about it. But if you do it 10 times a day, and the flash can be written to 10,000 times, your app will fail after 3 years.

It might be. There are some legitimate uses to overwrite the running code in flash.

With respect to the number of writes, it depends on where the write(s) is done. The 10,000 times is per page. If you are updating the flash with a minimalchange it will potentially only impact a single page. Since there are many pages in flash the actual numberof writes could be much higher than 10,000 times if the writes are being done on different pages.

Quote

Plus, it would be easy, if you enable writing to flash, to corrupt the running program. Do you want that?

I could think of reason to want to do this: Debugging.Suppose you want to run gdb for source level debugging and insert a break point.The way to do this is to "corrupt" the running code with a new bit of code where youwant the breakpoint to be.The Atmel ICE products do this by "corrupting" (overwriting) the existing codewith a BREAK instruction. They read the appropriate flash pageand re-write the page with the BREAK instruction inserted in the correct place.

It is possible to do the same (overwrite code with a special instruction)without an ICE in the code itself to allow gdb to talk to through the serial port on the AVR byusing a similar approach. You can't use the BREAK instruction because that is reserved by ATMEL whenthe OCDEN fuse enables 1 wire debugging (debugwire).You can do it through a cleaver use of an instruction to trigger a hardware interrupt (INT0 is best to gain full control) to cause a trap into an ISR.From there the code can take over and talk out the serial port and eventuallyback to gdb to transfer all the relevant information using gdbmon messages.Yes it is a bit tricky and it does require the ability to overwrite flash pagesbut it allows using the AVR serial port for source level debugging.It also requires a custom version of gdb to modify the "breakpoint" instruction to the needed instruction opcode to trigger the interrupt because currently the opcode for the "breakpoint" instruction is hard coded into gdb as BREAK and BREAKcan't be used since it only works for debugwire.

Or perhaps I might make a generic combo PDA and electronic key that a user would enter personal data that won't change any time soon. It might have certain code and data but also have room for more without overwriting anything but empty space. I could do that now if my users were expected to load the device from a PC/ISP but maybe I'd rather not have them do that for whatever reason. It's hard to say before the app is thought of except yo, I'd like the freedom to do that.

A real-world application that I've tossed around is a serial glcd backpack.glcd fonts and bitmaps can be quite large and as such are stored in flash.In a backpack product, it might be useful to provide a way toupdate/modify a font or a bitmap splash image.For that usage case it might be nice to be able to reserve areas in flashfor font/bitmap storage that can be updated and overwritten using the serial communicationinterface.So in this usage case it really isn't updating "code" but rather an area of the flash that isreserved for data that can be modified because eeprom is not large enough.And if that area starts right after the end of the real code vs a hard coded location,knowing where the code ends becomes quite useful.Even if the data starts high and starts to move down towards the code, knowing how muchroom is available is needed to determine how space is available for data storage.