gnupic: love this bootloader (for pic16f/18f)
Subject:
Re: love this bootloader (for pic16f/18f)
From:
David McNab ####@####.####
Date:
19 Jan 2005 10:28:20 +0000
Message-Id: <41EE3637.7080408@rebirthing.co.nz>
Chris Emerson wrote:
>>I got around the limitation by hacking up a command-line python prog to
>>replace it (which I can share if people want - note that it's 18fxx2-only).
> That's weird - I'm literally in the middle of writing a command-line
> python program to use it. :-)
Great minds think alike :)
> There are some disadvantages:
>
> 1. You have to temporarily erase the reset vector (with the jump to the
> loader) and rewrite it, giving a small window where you can lose
> bootloading ability. However, I think most "transparent" loaders would
> suffer from that anyway because of the 64 byte erase size.
No hassle - the client prog can have the bootloader's entry point
hardwired, and write that to addr 0000 after erasing/writing page0.
> 2. It can erase itself if you get the host program wrong, so it's not
> failsafe.
IMO, it's way more sensible to dump responsibility onto the host prog,
which has access to resources orders of magnitude greater than what the
bootloader has on the PIC.
Some on-PIC bootloaders weigh in at up to 1024 words - embarrassing!
To put validation, sanity checks etc onto the PIC side is IMO a waste of
scarce memory. Tiny Loader gets it right by limiting checks to a simple
checksum.
At a minimum, a host prog should:
- parse the .hex input file into an in-memory image
- break up the in-memory image to pages of up to 64 bytes, aligned
on 64-byte boundaries
- contain hardwired location of the bootloader, for writing reset vec
- in image page0, replace addresses 0-3 with a GOTO for the bootloader
- write the original addresses 0-3 to the end of the page just before
the bootloader
- decline to send any pages of image which would overwrite the
bootloader
- continually retry the initial handshake, to give user time to turn on
and/or reset the PIC
--
Cheers
David
