On Sat, Jun 26, 2004 at 04:49:41PM +0200, Kyrre Aalerud wrote:
> My bootloader is coming along nicely :)

I love all the bootloader activity going on right now.

Same questions to you that I posed to Tato a few days ago:

1) Will you be able to license it? If so then how are you planning to license
   it?

2) When can I see it? ;-)

> I have most of the functionality in place now.
>
> Specs are now:
> - uses 106 words

Just about the same as tiny. Good.

> - saves interrupt states and goes to a new interrupt-vector.

It that because of PCLATH? This is one of the few times that I wish that
the PIC had a limited goto that zeroed out the upper bits of the address.
Something like a "AGOTO 0x100" where AGOTO means absolute goto. It would
even be possible to do it with the current instruction set by splitting the
current GOTO instruction and letting the GOTO that uses PCLATH simply get
another bit from PCLATH. It would save on this issue.

> - receives data in 32 word blocks (32x2 bytes) wich are programmed and acked
> for next block.

Cool. That couples nicely with the erase size. I presume that these blocks
must be on a 32 word block boundary? Does your program check those last 6
bits of the address and make sure that they are zero?

> - does not reprogram first 256 words or memory as this block can be
> protected by the internal memory fuse.

Again I wish that Mchip had put the boot block at the end of memory.
I understand the design choice (all chips will have the first block, but
because of varying memory sizes, the location of the last block will vary).
But it really cuts into transparancy because it forces all applications to
start at address 0x100 and applications that don't start there cannot be
loaded.

Wouter has me spoiled with the transparancy he has implemented in Wloader and
ZPL. The bootloader takes care of relocating the first 4 address, and allows
the application to use any non bootloader memory available. However it does
cost precious memory space.

Kyrre, I do realize that yours is a specialized application and that you'll
have control over the loaded content. So that it's not an issue. But I always
view bootloader applications from the general development perspective
especially for beginning users. The less that can go wrong, then the less
that will go wrong.


>
> Todo:
> - Add a check on data input

Simple checksum should be fine. Just add everything up in the packet and send
the complement as the checksum. So when you add everything in the packet the
sum should come up to zero. You you want you can get a better detection
result then a CRC computation. Here's a pretty good article on the subject:

http://www.ciphersbyritter.com/ARTS/CRCMYST.HTM

> - when I know how large it will be, adjust programming to allow use of the
> remaining program-memory of the first page.

That's a catch 22 situation. I thought the whole point of putting the loader
in the first page was to prevent it from being overwritten by setting the
write protect for the boot block. Well if your application is allowed to exist
on the 1st page, then you'll have to turn that write protection. If that's the
case then there's no real point in having the loader in the boot block and
you can move it to the end of memory allowing the application to have
everything except for the first two or three instructions in memory. Or
compromise and reserve the 1st erase row (32 words) for the loader and let
the application start at word 32.

>
> What check algorithm do you guys (and girls?) suggest ?
> It should be as small as possible, but I do have 22 words left before I
> start on the next 32 word block...

Simple checksum may be  sufficient. The article above points out that an 8 bit
checksum catches 99.29 percent of errors. Of course the CRC is 4 9's
(99.998%) which is much better. But it'll cost you some code space to implement.
It may be worth 55 instructions (22+32). Decisions, decisions...

BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics