Except for the excellent BenF firmware, there is not much development activity on the Nano as far as I can tell. I believe one reason is that it is awkward to reflash the Nano when changing between the Benf application for real work, and your own application for tinkering and development. Another reason might be reluctance to reflash the device for testing out smaller things and between every development advancement - some might fear the ~10000 flash cycle limit coming closer for each little typo that has to be fixed 
To help overcome this, and to simplify my own (wishfully planned) development on the Nano, I have written a small bootloader extension to the original USB DFU bootloader. The code is at gitorious.org/dsonano/dso-bootl
It currently adds these features:
-
- Let any application decide which application should start after reset (think boot selection applets here).
-
- Allow DFU downloading to RAM. This also uses (1) so that an application can be downloaded and run from RAM.
I have posted an example of dual-booting between two applications here: viewtopic.php?p=13618#p13618 but that is kind of an added hack and does not demonstrate 1 or 2 above. The corresponding code is in the “dualboot” branch of the git repo.
Later I will provide a “hello world” example for running from RAM.
More info in the README file at gitorious.org/dsonano/dso-bootl … oot/README
If several applications become available on the Nano, it might call for some agreement between developers in order to simply multi-boot. I would suggest the following:
-
- We will avoid having to reprogram the original bootloader, since that can be a support burden. This leads to 2:
-
- No application should install in the first page at 0x08004000. This location is called from the original bootloader so the (link to a) new bootloader or application selector must be installed here. Otherwise the application in question must provide the multiboot selection facility.
-
- To allow space for more applications in flash, try to pack code segments together, because holes are difficult to use.
-
- Some convention for a identification tag or title that can be scanned for and displayed in a boot selection applet.
Take the example of the BenF firmware. Regarding (3) there is a unused gap between LIB and APP of 18KB. In the dualboot example I managed to fit a stripped down version of the DSO-FFT lib in there, but this is not a real solution. Since LIB and APP are shipped together anyway, this gap can be minimized without problems. The alignment of vector tables is the only practical issue.
Also, the calibration data resides 4 KB below the upper flash memory limit. Maybe it can be shifted up as high as possible so that other applications have more contiguous space? If it needs space for future growth, it can grow downwards.
Regarding (2) the LIB can simply be shifted one page up. The application provider can ship a separate 1-page image file to install in case there is no boot selection facility installed on the device. The 1-page image just needs to contain a copy of the 8 first bytes of the LIB image.
Looking forward to your comments, ideas, and… new applications