Re: PIC Based Bootloader

[Ian Lowe]

lo mate :)

> As I'm a cheep ;)

...says the man with cable *and* adsl? ;)

> 3. Optionally add/create a xPl based bootloader
>
> I was wondering what peoples opinion on the subject of bootloaders,
> have you used them, would you like to? is a xPl bootloader for PIC
> based devices of any use?

I would like the idea, as I have now killed a couple of 16F628s through
repeated plug/burn/plug/test cycles knackering the pins. Not sure about
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...

> 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
of things. I have a pretty solid xPL implementation on a 16F628, but that's
using PICBASIC, fast to develop, but not exactly optimal.

You are welcome to it though, looking at the PBP generated ASM file might
save some time...

> Having said all this I'm considering buying the Microchip ICD2, but
> I think it's worthwhile effort as bootloaders are pretty cool for on
> the job reprogramming without having to have a ICSP interface.

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

> 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

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.

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.

I.