On Thu, 18 Aug 2005, Mike Harrison wrote:

> Now that self-programming is available on some smaller PICs (e.g. 16F818), I was thinking about ways
>  of providing in-system firmware updates with the absolute minimum of code overhead - a typical
> 'traditional' bootloder takes of the order of 128-256 words, depending on the communications
> requirements, which is a significant chunk on a 1K part. 
> 
> I was thinking particularly about a current design, but it would be applicable to any system where
> the main application already has : 
> a) An external eprom or serial flash etc. memory big enough to hold a code image
> b) Some communications link capable of reading/writing to the eeprom. 
> 
> Instead of the traditional bootloader approach (where the loader handles the comms and the
> programming, and has to be able to recover if the comms fail), you copy the code into eeprom using
> the existing application code, verify it back, then call a small routine at the top of memory to
> copy the eeprom image to the flash.
> 
> This has the advantage that because you already have the comms code in your main application, the
> only code overhead is the actual eeprom-to-flash copying code - off the top of my head I'd guess
> this could easily be less than 64 words, and may be a lot less  if your eeprom is on a hardware SPI
> or I2C interface.

If you're going to add an extra chip why not simply add a second PIC and 
use that to program the first in LVP mode? There would be lots of benefits 
in this including the ability to program the config words.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use




-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist