On Wed, Mar 14, 2012 at 04:56:27PM +0000, alan.b.pearce@stfc.ac.uk wrote:
> PIC topic added ...
>=20
> > So I've been working on checksums. It's clear that CRC is the best. How=
ever it gets
> > murky in terms of running CRC on 15 bit values. While there are decent =
15 bit CRC
> > polynominals out there, I've had a tough time finding any table driven =
algorithms
> > that addresses anything other than 4, 8, 16, or 32 bits. It looks like =
the natural
> > breakdown would be to split the 15 bits into three 5 bit words and use =
three 5 bit
> > tables to encode. So the tables would cost 96 words of program memory. =
But then it
> > looks like some work to either split the 15 bit word into 5 bit chunks,=
 or the
> > opposite of combining three 5 bit chunks into a whole 15 bit word. With=
 some careful
> > coding it would be possible to generate both at the same time I guess.
>=20

> My initial thought was that the easiest way is to calculate a 16 bit CRC
> with the top bit of data always 0, but I guess you also need to transmit
> the CRC in a 15 bit word, but maybe the way to do that is have it as a
> special word.

Even if it's a 16 bit CRC, there will be some of the same types of
problems. Another thought is to split into a 7 bit table and a 8 bit one.
That will git rid of the split/combine issue at a cost of 384 words of
memory. Again just wondering if it's worth it.

>=20
> But if the comms are one way, how are you going to signify an error?

By not loading the bad row and marking the download as invalid. The
bootloader simply will not run application code anymore until a new load is
done. I'm thinking of saving the very last row of memory (or possibly the
2nd row as the first is reserved for the bootloader under Frank's scheme)
for such flags. Erase the row when the current application is valid, write
a "bad code flag" when it's invalid and check the row being blank before
running the application with either the execute command or after a timeout.

If a developer wanted to, they could certainly use a I/O pin (as opposed to
input only) or even two pins if they wanted to communicate back to the
host. But in my experience bootloaders are reliable virtually all the time.
so there's no real deep need for two way communication. Neither Frank's
Pikme nor Wouter's ZPL had a defined feedback channel. And even if there's
a burp, there's little cost to simply downloading again.

BAJ


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

--=20
Byron A. Jeff
Department Chair: IT/CS/CNET
College of Information and Mathematical Sciences
Clayton State University
http://cims.clayton.edu/bjeff
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.