Would it be possible to program an arduino to modify its own code, after its been uploaded?
You could have settings you store in EEPROM, and make program decisions based on what you store there and change there.
Otherwise, application code is not allowed to change what is stored in boot code space.
Alternately:
"Boot Loader Lock Bits
If no Boot Loader capability isneeded, the entire Flash is available for application code. The Boot Loader has two
separate sets of Boot Lock bits which can be set independently. This gives the user a unique flexibility to select different levels of protection.
The user can select:
• To protect the entire Flash from a software update by the MCU.
• To protect only the Boot Loader Flash section from a software update by the MCU.
• To protect only the Application Flash section from a software update by the MCU.
• Allow software update in the entire Flash."
So it would seem so...
Interesting concept 
Self modifying code..... programs writing programs !!!!
nicoverduin:
Interesting concept
Not a new concept 
While there is nothing stopping a program re-writing the contents of flash (after all, that's just what the bootloader does), there are certain technical difficulties around doing it - mainly that of how do you actually generate the code?
It is perfectly possible to set aside a block of flash as your extra program area and erase/reprogram that (as long as it is multiples of a flash page in size), but what are you going to put in there? There is no way you can fit an entire C compiler inside your program (I know - we've been trying for ages to fit a decent one into RetroBSD, with only 96KB of RAM for both the program and its data - not easy), but you could work directly in assembly language. Of course, that would mean having a good grasp of assembly language, and probably building up the program from pre-written building blocks - not really the flexibility I guess you're after.
So yes, while physically possible... technically...?
Not something I'd fancy debugging on an arduino.
Interesting concept
...and a nightmare to test/debug
No... Not at all, Issue the command... "Machine.."
majenko:
nicoverduin:
Interesting conceptNot a new concept
While there is nothing stopping a program re-writing the contents of flash (after all, that's just what the bootloader does), there are certain technical difficulties around doing it - mainly that of how do you actually generate the code?
It is perfectly possible to set aside a block of flash as your extra program area and erase/reprogram that (as long as it is multiples of a flash page in size), but what are you going to put in there? There is no way you can fit an entire C compiler inside your program (I know - we've been trying for ages to fit a decent one into RetroBSD, with only 96KB of RAM for both the program and its data - not easy), but you could work directly in assembly language. Of course, that would mean having a good grasp of assembly language, and probably building up the program from pre-written building blocks - not really the flexibility I guess you're after.
So yes, while physically possible... technically...?
I know the concept is old.... I recall reading it in Byte somewhere back in the 70íes. But if he wants to do this he'll probably have to fall back to machine code. And then a lot more is possible. I had an assembler for my 6502 KIM-1 computer running in 8K of memory (I built 2 x 4K boards then) and it all fitted including the actual program (I still have that papertape with the assembler on it). I had a chess program then running in 512 bytes or memory going 8 levels deep.
And with 32K of memory, a lot faster CPU and more efficient instruction set on the Arduino line, it is probably doable....Depending on what he wants to do with it.
nicoverduin:
But if he wants to do this he'll probably have to fall back to machine code. And then a lot more is possible. I had an assembler for my 6502 KIM-1 computer running in 8K of memory (I built 2 x 4K boards then) and it all fitted including the actual program (I still have that papertape with the assembler on it).
Yes, but modern compilers generate good machine code. That's their job after all. The compilers cleverly keep track of register usage and generate very good code, keeping things in registers rather than getting/putting from RAM.
Personally I would stay away from self-modifying code. It's put into flash memory for a reason. Plus the reprogram count is comparatively low. Sure, you can reprogram the flash 10,000 times, which is a lot if you are uploading new code every few days. It certainly is not a lot if your code reprograms itself every second.
If you are running Bitlash then it would be straight forward to have the stored scripts modify each other. (Why you would do that, and how difficult it would be to get it to do what you want, would be another matter.)
I've written lots of self-modifying code...mostly involving pointers. 
[quote author=Nick Gammon link=topic=172849.msg1285252#msg1285252 date=1371710274]
Personally I would stay away from self-modifying code. It's put into flash memory for a reason. Plus the reprogram count is comparatively low. Sure, you can reprogram the flash 10,000 times, which is a lot if you are uploading new code every few days. It certainly is not a lot if your code reprograms itself every second.
[/quote]Good point Nick. Forgot about that......