Sorry Olin,
I could'nt download mail for a week.And hence I'm replying this message
late.
The Checksum Idea is great. I was how to detect and possibly fix errors
caused
by power failures.

But, how long does it take to checksum a long block of code (say 6K words) ?

If you are curious, the application is a UPS system which is flash
upgradable
through RS232 uplink to the PC its powering.
But when the code is being updated, the PIC will just have to sit like a
dumb moron
forgetting all its complex functions and it won't be able to switch to
battery power
if the power is to fail.

I could possibly do something like write all the code in a particular page
into an
unused page and then copy the code from there to page 0 and 1(This is
because I know
that my code won't exceed 4K words).

As for the Assembly optimizer, I don't have time for writing it now. Maybe
it'll have
to wait some 6 months. But I am serious about it and am convinced that it
will work for
JAL generated code. Just check the assembly output of JAL0435 with 16f877 as
the target processor
and i'll bet you'll believe me. I have not used SX chips but I think JAL has
the same weakness
on SXs. It simply generates a hell lot of redundant page selection code.
Merely removing these
redundant page selections can reduce code size by 30%. Add to it multiple
chained gotos (I hope you
get it) which JAL sometimes generates. This may be optimized and a further 5
to 10% code size may be
reduced. I've already worked out ways to adjust other calls and gotos to
compensate adding/removing
of code by the optimizer.

Anyway,
Thnx for the cool idea on BootLoaders

Jeethu Rao

> -----Original Message-----
> From: pic microcontroller discussion list
> [mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Olin Lathrop
> Sent: Saturday, July 07, 2001 6:52 PM
> To: PICLIST@MITVMA.MIT.EDU
> Subject: Re: [PIC]: Compiler
>
>
> > ... self modifying code ...
> > Although it is theoritically possible to write
> > such code on PIC16f87x devices through flash writes,
> > I'm sure no one is gonna do it (Its way too inefficient).
>
> Ha, never say never!
>
> My code uploader for the 16F parts modifies one of its own instructions.
> The uploader runs for a short time after a reset to allow the
> host a chance
> to upload new code before the main code is run.  It then
> checksums the main
> code and compares the result to the expected value.  The main code is only
> run if it checksums correctly, otherwise the uploader restarts
> itself in an
> infinite loop until new code is uploaded.  This is to protect against data
> errors, power loss, etc, during an upload.
>
> However, the upload code as written in the source code, and therefore as
> programmed into a new chip, contains a GOTO to skip the
> checksumming of the
> main firmware and always run it.  This speeds things up when debugging,
> especially with the ICE which does direct flash reads/write *VERY* slowly.
> The GOTO is overwritten with a NOP as soon as an upload request
> is received,
> which causes the main code to be checksummed forever after.  This method
> seemed to be simpler and smaller than writing a flag someplace then
> explicitly checking it at run time.
>
>
> ********************************************************************
> Olin Lathrop, embedded systems consultant in Littleton Massachusetts
> (978) 742-9014, olin@embedinc.com, http://www.embedinc.com
>
> --
> 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
>
>

--
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