gnupic: love this bootloader (for pic16f/18f)
Subject:
Re: love this bootloader (for pic16f/18f)
From:
Byron A Jeff ####@####.####
Date:
19 Jan 2005 20:35:19 +0000
Message-Id: <20050119203514.GA29469@cleon.cc.gatech.edu>
On Wed, Jan 19, 2005 at 06:14:50PM +1300, David McNab wrote:
> Hi,
>
> My search for pic18fxxx-compatible bootloaders turned up this particular
> little gem - 'Tiny PIC Bootloader':
> http://www.ac.ugal.ro/staff/ckiku/software/picbootloader.htm
I've been examining Tiny for awhile. It does have some limitations. The primary
one for me is that it uses the hardware USART. In general I believe that the
USART is too valuable a resource to dedicate to , or really even share with,
the bootloader.
The second which has been pointed out, limited protection of the reset vector
and the bootloader itself.
I admit that my bootloader views have been skewed (read spoiled) by Wouter
van Ooijen's WLoader. From the single pin half duplex interface to the
transparent boot vector, it does many of the right things.
The only item that's left is the command protocol. I believe any such
protocol should have the following features:
1) Row based (either 32 or 64 words)
2) Proper checksum. I been looking at the add/triple/add checksum
3) ACK/NACK retries.
>
> Fastest bootloader I've seen, and the damn thing uses just 100 words
> (or, to 18fxxx folks, 200 bytes) of program memory.
>
> Only catch is that the host downloading client is a windows prog with no
> source code. It works fine on windows and on linux via wine, but still
> suffers the inability to be driven purely via command line args (which
> to any linux user, will feel lame).
>
> 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).
>
> I do recommend Tiny PIC Bootloader to anyone who uses bootloaders. Why
> put up with larger footprints and slower downloads?
Because it's real important not to screw the bootloader up.
Because it's kind of important to make the HEX file transparent, so that you
don't have to set up one HEX file for the bootloader and another if you want
to burn it straight.
Because program memory is the most plentiful resource, so using a bit more
doesn't hurt you very much.
Because even if it is a bit slower to download the convenience of not having
to be confined to the ICSP interface is good.
I'm a bootloader fan. But I'm a picky bootloader fan. And none match my
specification list exactly. And unfortunately I don't have time at this time
to write one that does match exactly.
BTW Tato Nogueira's PLoader bootloader comes closer to my ideal even though
it takes a few more bytes (178). You can find it here:
http://www.propic2.com/ploader
Still needs some work on the packet format and uses 2 pins for full duplex.
Also since the original target was a 819 with 2K words, it didn't have
any PCLATH code attached. An auto baud detect would be nice. Finally it's
targeted for the 16F family.
But all in all these are relatively minor issues, so it makes a good target
because it has the basic structure that a bootloader for modern PIC chips
require: multi word block writes and row erase.
BAJ
