gnupic: love this bootloader (for pic16f/18f)
Subject:
Re: love this bootloader (for pic16f/18f)
From:
Chris Emerson ####@####.####
Date:
19 Jan 2005 12:48:03 +0000
Message-Id: <20050119124748.GA29918@ixion.tartarus.org>
On Wed, Jan 19, 2005 at 11:28:07PM +1300, David McNab wrote:
> Chris Emerson wrote:
> >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.
It's fine for non-critical uses, but it is still possible to disable the
PIC (including bootloader) if you lose the power at the wrong moment.
> >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.
It depends. If I were putting a bootloadable PIC in a system where it
would be really inconvenient or expensive to fix if something went
wrong, then I'd want to be pretty sure that there was no way to disable
the bootloader (including setting code protection, and doing something
about the reset vector).
As it happens, neither of those are true so Tiny's fine.
> Some on-PIC bootloaders weigh in at up to 1024 words - embarrassing!
How much of the code space do you actually use for your app code? If
you don't run into the limit that's not really important.
Chris
