I was thinking of modifying the bootloader code intended for the arduino mega 2560 to facilitate the current scenario:
My understanding about the current bootloader :
The bootloader will facilitate the arduino to listen to the serial port on the reset button. If there is a new sketch being uploaded via the USB , then the bootloader will erase the portion of the falsh memory and upload the new sketch and will move the program counter to that memory segment.
Modified bootloader's funtion
So by modifying the bootloader i want to perform as follows. So when the reset button is pressed for the first time, it will perform its original intented funtion , i.e - the task it is supposed to actually do. But next time, it is not supposed to wait for the new program from the USB . Instead it must wait for the new program/commands from some other interface, namely the GSM, ethernet , etc.. So by this way , the bootloader will be waiting for the commands from the external device and not rely on the USB interface alone.
Scope / Usage
By modifying the bootloader code , one can upload the firmware/sketch from anywhere rather than rely only on the USB interface without using any external hardware. So by this way the bootloader will intelligently be able to delete the flash contents and upload new codes as and when required.
This is my idea. Is this possible ? Can anyone throw some light about the feasibility of this ?? Also please correct me if I am wrong !
Thanks MarkT.
My understanding of the bootloader is correct right ? I am in the process of familiarising with the bootloader code.
Any suggestions you have for me for performing the above task that i mentioned ?!
Are you planning to monitor the wireless interface just at boot time, or also at runtime?
In the first case, how will you arrange to trigger a reset prior to the upload so that the bootloader is running when the upload occurs?
In the second case, how will you arrange for your bootloader to continue running the wireless interface after it has handed control over to the running sketch? I assume that in this case the wireless interface would be dedicated to the bootloader and not available for the sketch to use.
In case you're interested, the Ciseco RFu range supports over-the-air uploading and there may be others that do. It was mentioned as something that might be supported by the standard WiFi shield in future although I haven't followed whether that has / will ever happen.
You might pick a byte of EEPROM to use as a program load source flag. 255 might be load from serial, 0 might be load from wireless. You can either toggle this byte each time the bootloader runs, or set it in your sketch as appropriate.
If you can't fit all the code in the bootloader section of flash, then you can place some of your functions in the "regular" flash. As far as I can tell the there are just two differences between the bootloader section of flash and the rest:
You can only write to program space(flash) from within the bootloader section. That is because the cpu instruction to write to program space is disabled for code outside the bootloader section.
The reset vector will point to the bootloader section, if the right fuse bit is set(default on arduino). This means the bootloader code will execute first thing after a reset/power up.
If you place you space demanding upload-related functions just below the bootloader section, you won't overwrite them unless your uploaded sketch is very large - I guess you could check for this in your bootloader.
Code space would be the biggest problem. One way to do things, on a mega with lots of pins and lots of sketch space, is to have the sketch able to download new code to an external EEPROM, and just modify the bootloader to detect "new code in EEPROM, will copy to avr flash space.". That should be pretty easy to fit, and gives you a lot of flexibility in what protocols to support in the sketch. And you could do multiple stages, downloading a sketch via Ethernet that knew how to download via wireless, or similar.