Re: PIC Based Bootloader

[swelsh000]

> lo mate :)

hi mate :)

>
> > As I'm a cheep ;)
>
> ...says the man with cable *and* adsl? ;)
<--SNIP-->

Everyone needs a resilient internet connection nowadays :)

> moving up to the "chunky" PICs though: the smaller devices
have an
advantage
> of less PCB space, which makes a difference when using a service
like PCB
> pool...
<--SNIP-->

You can use smaller PIC18's like the PIC18F1320, that will take a
boot loader no problem, and should be pin compatable with the
16F628's, just plug and go.

I tested the Michrochip AN00851 bootloader and it appears to work
straight out of the box!
All you have to do is

1. program in the pre-compiled firmware
2. Adjust the org and reset vectors according to AN00851 in your
source code
3. Program the complied hex file with the Microchip Quick Programmer
software

>
> > Note: For a xPl based bootloader all xPl comms would have to go
via
> > the bootloader software to intercept requests, is there a PIC
based
> > framework for xPl I can work to?
>
> No, the guys who were developing PIC in ASM are still over on the
xAP side
<--SNIP-->

If I get a chance I may be able to do something in ASM for xPl.


> Hmm. I'm torn. I fancy a look at that ICD :) Then again, tehre's
always the
> thought that bootloaders will always be confined to the bigger
pics, I
> haven't seen one for the 628s yet, and with the 18F being
<--SNIP-->

The PIC has to be able to re-program it's own memory, don't think
you can do it on the 628's. Upgrade to the PIC18F1320 and your
covered, it's supported in PBP too...

>
> > P.S. While I'm on the subject is there a schema, or plans for a
> > schema to allow NAS (network attached storage) on the xPl bus.
> > i.e. send a xPl message to store retrieve a setting held
centrally,
> > that is independant of a particular schema?
> > It may be worth while incorporating a bootloader into this,
similar
> > idea to routers booting from TFTP servers.
>
> Well if you ideas on how to do it, lets have a go :D There is a
structure in
> place to support
<--SNIP-->
I think I missed some text here,
structure in place to support....

>
> There is quite a lot of discussion going on "behind the
scenes"
about the
> other layers and protocols glueing the infrastructure together.
One thing we
> are keen to stress is that the xPL Protocol is finished, complete,
and will
> not be changing from here.
<--SNIP-->

Cool!

>
> All of the clever stuff we are adding are bolt-ons, and intelligent
> applications, not modifications to the protocol, a perfect example
being the
> Bridge.
>
> Rather than having additional fields in the message to separate out
> networks, we implemented an MD5 hashing message cache to prevent
looping,
> and added a Blowfish encryption wrapper around the message.. so the
> functionality is there, but there's no need to bloat the protocol
to do it.
<--SNIP-->

Nice!!!

Cheers

Stephen