> I was reading the app note for the 16F87XA boot loader and was wondering
> if anyone on the list had used it before, and if so how did you take
> care of the configuration memory? Did you set them to the desired levels
> before you installed the boot loader? My understanding is that you can
> not write the configuration memory with the 16F87XA boot loader.

I don't know about the 87xA portion, but I just adapted the 18F version
to my application on an 18F2320, so here are my observations:

1.  I'm not certain how truly well the app note, the PC software, and 
the firmware match up.  That said, it does basically everything I need
it to do.

2.  The PC software has a config file which can easily be altered to
tell it where to start and stop writing, but regardless of the settings
there, the thing figures out where its own reset vector is and won't
write over it.  If you tell it to put its reset vector in location 0x001,
you can put your own application's reset vector in location 0x000.
That way, your app gets to decide when and if to bootload, rather
than the bootloader.  If that's what you want; Wouter scolded me
once for thinking that my application had to be aware of the
bootloader at all, and he's right, it doesn't.  With PBP, though, it
helps, because you never know where PBP is going to stick the
start of your code other than by the goto at 0x0000.

> The module I am working on will be installed in some hard to reach
> places and I was thinking of adding the boot loader to my code to allow
> software upgrades without moving the boards. IS this a good application
> of the boot loader?

That's my idea, too.  Just make certain that you can't trash the system
with an accidental entry into the bootloader.
 
> And how hard will it to be to add the boot loader to my existing code? I
> used absolute code, will that help or hurt?

In my case, I'm using PicBasic Pro.  I snooped a little but couldn't find
any real hard data about incorporating a bootloader, but a little investigation
showed that PBP puts a pointer at 0x0000 to the first line of user code,
goes about its business of loading its various libraries and such in the
first block of memory after the interrupt vector.  That's a problem, since
the bootloader wanted to go there.  Plus, the bootloader refuses to write
over its first memory location (it assumes that is the reset vector), so
upon reset, the bootloader always got first crack.  Usually not a problem,
but once into the bootloader, it became impossible to know for certain
where PBP had decided to stick the initialization code for my program.
The solution was to
alter the bootloader code to work in the last 256 words of memory
(replacing rcall with call and bra with goto, in some places, and changing
PCLATH to reflect the current memory location instead of letting it be
in the lower range) and start the whole thing at 0x0004.  That way, it
programs the PBP goto in location 0x0000, skips its own goto in 0x0004,
then continues to write the PBP code through the rest of the memory,
up until 0x1DFF.  The config file allows you to select the writable range;
tell it to stop before it overwrites itself, obviously.

Bottom line, it took me about 3 hours of fooling around to adapt this
to suit my own needs.  I'm sure a more experienced or skilled programmer
could have done it faster, but by both number of projects and time spent
on them, I'm barely a neophyte according to the standards of this list.

Mike H.

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