Searching \ for '[PIC:] 16F88 RS232 bootloader.' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=rs232
Search entire site for: '16F88 RS232 bootloader.'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] 16F88 RS232 bootloader.'
2004\06\26@104659 by Kyrre Aalerud

flavicon
face
My bootloader is coming along nicely :)
I have most of the functionality in place now.

Specs are now:
- uses 106 words
- saves interrupt states and goes to a new interrupt-vector.
- receives data in 32 word blocks (32x2 bytes) wich are programmed and acked
for next block.
- does not reprogram first 256 words or memory as this block can be
protected by the internal memory fuse.

Todo:
- Add a check on data input
- when I know how large it will be, adjust programming to allow use of the
remaining program-memory of the first page.

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


Kyrre

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

2004\06\26@105525 by David VanHorn

flavicon
face
At 04:49 PM 6/26/2004 +0200, Kyrre Aalerud wrote:

>My bootloader is coming along nicely :)
>I have most of the functionality in place now.
>
>Specs are now:
>- uses 106 words
>- saves interrupt states and goes to a new interrupt-vector.
>- receives data in 32 word blocks (32x2 bytes) wich are programmed and acked
>for next block.
>- does not reprogram first 256 words or memory as this block can be
>protected by the internal memory fuse.

What happens if I pull the cable in mid-load?
Will the system recover, or become a "brick" that can only be recovered with a chip programmer?

You could use LRC, which is simply an addition of all the bytes in the packet, throwing away the overflow, or "add, triple, add" which is used in UPC/EAN barcodes.
Both are very easy to implement, and for short packets, pretty reliable.

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

2004\06\26@110353 by Kyrre Aalerud

flavicon
face
If you pull the cable the buffer won't fill and it will sit there patiently
waiting.
If noise is interpreted as data, then it may program rest of memory with
that and the chip will get a garbage-program.
(As I don't verify data yet.)
However, the code is written so that it won't touch it's own code.  And, it
will always load.

The bootcode actually announces itself on the RS232 and waits a short while
for a Flash-reply.  If none is received it continues to boot the regular
program.  If received, it asks for a data-block, then erases memory and
programs the block before asking for a new block.  After the final block, it
tells the computer it is done, and doesn't want another block before halting
in anticipation for a full reset.

I like the sum idea.  It should be quick and simple.
(Adding it now while I wait for other bright ideas, but I really think it
would be enough :) )

Kyrre


{Original Message removed}

2004\06\26@113850 by Philip Pemberton

face picon face
In message <1b6801c45b8c$d13a8980$fe01010a@cartman>
         Kyrre Aalerud <spam_OUTkreatureTakeThisOuTspamC2I.NET> wrote:

> 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...
How about this:

declare variable Checksum as byte

proc checksum_init()
{
 Checksum = 0x00
}

proc checksum_update(byte in ByteIn)
{
 Checksum = Checksum XOR ByteIn
}

Basically, you XOR together all the bytes in the data block that was
received. Compare the checksum you received with the value in the Checksum
variable after you've scanned through all the data.

Later.
--
Phil.                              | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB,
.....philpemKILLspamspam@spam@dsl.pipex.com              | ViewFinder, 10BaseT Ethernet, 2-slice,
http://www.philpem.dsl.pipex.com/  | 48xCD, ARCINv6c IDE, SCSI
... LASER : Looking At Source Erases Retina

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

2004\06\26@114716 by Kyrre Aalerud

flavicon
face
Is this better or wose than the sum method ?
Maby I can do both ?

Kyrre

----- Original Message -----
From: "Philip Pemberton" <philpemspamKILLspamDSL.PIPEX.COM>
To: <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU>
Sent: Saturday, June 26, 2004 5:40 PM
Subject: Re: [PIC:] 16F88 RS232 bootloader.


{Quote hidden}

6GB,
> philpemspamspam_OUTdsl.pipex.com              | ViewFinder, 10BaseT Ethernet,
2-slice,
> http://www.philpem.dsl.pipex.com/  | 48xCD, ARCINv6c IDE, SCSI
> ... LASER : Looking At Source Erases Retina
>
> --
> 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

2004\06\26@120948 by Byron A Jeff

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

2004\06\26@122854 by Byron A Jeff

face picon face
On Sat, Jun 26, 2004 at 09:55:31AM -0500, David VanHorn wrote:
> At 04:49 PM 6/26/2004 +0200, Kyrre Aalerud wrote:

I should speak for Kyrre, but I can't resist... ;-)

{Quote hidden}

Loader will still be available but the application is toasted.

> Will the system recover, or become a "brick" that can only be recovered with
> a chip programmer?

Neither. It'll be a brick from the application standpoint. But the loader
will be intact and available to reload. There should be enough communication
between the PC loader app and the PIC bootloader for the PC loader app to
indicate that the application didn't get completely loaded.


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

2004\06\26@124932 by Kyrre Aalerud

flavicon
face
My bootloader will be available as source...
The rest of the code is usually relocatable when one can have the bootloader
and software through the linker together...

Basically, my first version of the bootloader will handle interrupts by
saving context, then jumping to the address 0x104 while the booting of the
application will happen by jumping to 0x100 ergo I simply shifted the stuff
up to next page.  I had to add the context-saving in the bootloader as the
goto would change the status of stuff.  as would any other instructions kill
W.

The restoring would be done as normal in the target interrupt-routine to
avoid extra jumps.

Simple yet effective...
Oh, and I adjusted some stuff...

I added the check stuff and the code to ask PC to repeat datablocks if
mangled data is received.  I also cleaned up some other stuff.
Total words now is 114, but technically I still start loading software at
0x100.  I will change this to start at 0x80 giving 128 words more memory
available.  For testing, I will leave it at 0x100.

Kyrre


{Original Message removed}

2004\06\26@124933 by Victor Faria

picon face
Sorry if this is a stupid question??
But with all the talk about bootloaders is it possible to turn these into a
single pin loader???
Much like Wouter's. Even if it costs some memory but you gain a pin it may
be a good trade off!!
victor

{Original Message removed}

2004\06\26@150245 by Dave VanHorn

flavicon
face
>
>   Checksum = Checksum XOR ByteIn

I've seen this one used too..
I don't see any real advantage over add, since in the end, you have a byte,
and an errored packet has a 1/256 chance of having a passing checksum no
matter how you calculate it.  Same for word-width checksum.

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

2004\06\26@164011 by Byron A Jeff

face picon face
On Sat, Jun 26, 2004 at 12:49:15PM -0400, Victor Faria wrote:
> Sorry if this is a stupid question??

Why would you think that?

> But with all the talk about bootloaders is it possible to turn these into a
> single pin loader???

Of course! Tato's loader is a prime candidate because it bit bangs the
serial interface.

> Much like Wouter's. Even if it costs some memory but you gain a pin it may
> be a good trade off!!

There are more advantages:

1) You get to pick the I/O pin.
2) You don't have to tie up the USART.
3) Since it's a bit banged interface you can dynamically adjust the bit rate
  so that the load will work using the internal oscillator even when the temp
  fluctuates.


Wouter's basic idea is sound. A single pin interface is created by tying the
RX and TX pins of the serial interface via a resistor (he shows 330 ohms
on his WLoader schematic here: http://www.voti.nl/wloader). Then the TX
driver output pin is connected directly to a PIC I/O pin. So the PIC I/O pin
can drive TX, receive from RX, with only the minor side effect of everything
from RX being echoed to TX, which is actually a good check for the PC side
loader software.

BTW for bit banging serial Timer 2 is great as a bit rate generator when it's
available. With the period register PR2 set, the timer will auto reset after
the given interface. So you can set it to time out and auto reset after one
bit cell. Then only a single bit needs to be checked to see when to transmit
or receive the next bit from the serial interface.

Lastly the single pin interface will cost only a trivial amount of code over
a 2 pin bit banged interface. The only difference is that you have to turn
the TRIS bit for the pin around from transmitting to received. Otherwise it's
exactly the same. So 2 instructions to save an I/O pin, especially on an 18
pin part? Definitely a winner.

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

2004\06\26@164637 by Byron A Jeff

face picon face
On Sat, Jun 26, 2004 at 06:51:23PM +0200, Kyrre Aalerud wrote:
> My bootloader will be available as source...

Good start. Now how can we use that source? It's up to you to allow for
change, redistribution of original and modifications, commercial usage, and
the like. Use the GPL if you want everyone to contribute their changes, or
the BSDL if it doesn't matter to you.

> The rest of the code is usually relocatable when one can have the bootloader
> and software through the linker together...
>
> Basically, my first version of the bootloader will handle interrupts by
> saving context, then jumping to the address 0x104 while the booting of the
> application will happen by jumping to 0x100 ergo I simply shifted the stuff
> up to next page.  I had to add the context-saving in the bootloader as the
> goto would change the status of stuff.  as would any other instructions kill
> W.

Cool.

{Quote hidden}

So you decided not to write protect the 1st block then?

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

2004\06\26@165013 by Bob Axtell

face picon face
I am VERY interested in the F1688 Bootloader project. I have a
specific need for one, so that the client can change the 688 firmware
whenever needed.

It might be very helpful if you make 1 or 2 more registers available for
debugging, where you can press the reset button, and if those registers
are not the DEFAULT value, let them be read by your bootlegger as a
primitive debug tool. The way it would work is to copy to these
registers anything valuable you'd like to see, or verification of a
pathway (by setting bits in the debug register as the particular routine
is passed through)
I'll be glad to help you guys debug or verify the Bootloader; having a
card made right now...

--Bob

--

Replier: Most attachments rejected
      --------------
        Bob Axtell
PIC Hardware & Firmware Dev
  http://beam.to/baxtell
      1-520-219-2363

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

2004\06\26@165454 by Bob Axtell

face picon face
Bryon, Where can we get a copy of tato's bootloader? I have Wouter's
already.

--Bob

Byron A Jeff wrote:

{Quote hidden}

--

Replier: Most attachments rejected
      --------------
        Bob Axtell
PIC Hardware & Firmware Dev
  http://beam.to/baxtell
      1-520-219-2363

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

2004\06\26@170114 by Jan-Erik Soderholm

face picon face
Byron A Jeff wrote :

> Wouter's basic idea is sound. A single pin interface...

Note the name, " *ZERO*  Pin Loader".

Wouter uses the MCLR pin, not an I/O pin.

Jan-Erik.

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

2004\06\26@170534 by Kyrre Aalerud

flavicon
face
Actually, my loader isn't tying up the usart at all.  It only uses it during
load.  Then the system itself can use it after boot to retrieve my logged
data etc...  No response from PC within a few ms means go and boot...

Kyrre

{Original Message removed}

2004\06\26@170739 by Kevin

flavicon
face
Tato's bootloader is here http://propic2.com/ploader/

~Kevin

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

2004\06\26@172050 by Byron A Jeff

face picon face
On Sat, Jun 26, 2004 at 01:40:56PM -0700, Bob Axtell wrote:
> I am VERY interested in the F1688 Bootloader project. I have a
> specific need for one, so that the client can change the 688 firmware
> whenever needed.

I think we all have a need for a 16F819/16F88 bootloader! Have you taken a
look at Tato's PLoader here?: http://propic2.com/ploader

It's a bit banged serial loader targeted for the 16F819. While I haven't
gotten to testing yet, it should work fine for a 16F88 as written, and with
trivial modifications (setting/resetting PCLATH) the loader should be
able to move to the last page of the 16F88 program memory space.

See my post to Victor as to why I like the bit banged idea.

Now Kyrre's is sounding like a tight USART based loader what will have its
uses too.

I'm glad that I can stand on the sidelines and cheer, because I do think that
it'll benefit many of use as we proceed.

>
> It might be very helpful if you make 1 or 2 more registers available for
> debugging, where you can press the reset button, and if those registers
> are not the DEFAULT value, let them be read by your bootlegger as a
> primitive debug tool. The way it would work is to copy to these
> registers anything valuable you'd like to see, or verification of a
> pathway (by setting bits in the debug register as the particular routine
> is passed through)

That's one way to tackle it. I'll tell you how I've handled it in the past.
When using Wouter's Wloader on my 16F877 projects in the past, I realized
(with a light switch from Woj, the author of linwload) that the single pin
serial interface was still available when the application was running. So
instead of just having a couple of registers, that it's possible to send
messages and data through the bootloader serial interface. You can see a sample
of this in action in my sunrise/sunset outdoor light controller here:

http://www.finitesite.com/d3jsys/clock.asm

THe dbgout routine along with delay/idelay near the bottom will send a single
char down the bootloader serial interface. Routines like printdate and printstr
then use the single character routine to send messages. It made desktop
testing trivial as you could program, execute, and debug all in a single
session with a single application. Finally note how the use of the Timer 2
period register makes short work of the bit rate generator.

[IDLE THOUGHT ALERT!]: It would even be cooler if the USARTs bit rate generator
could be decoupled from the USART hardware and be used as a 4th independant
self resetting on rollover timer. I'd use it like I'm using timer 2 here but
bitbang the serial interface with it.[/IDLE THOUGHT ALERT!]


> I'll be glad to help you guys debug or verify the Bootloader; having a
> card made right now...

I need to wire up a quick card and get to testing. But my lawn tractor needs
to be fixed first. Priorities, Priorities!

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

2004\06\26@173334 by Kyrre Aalerud

flavicon
face
Hehe.
If only I could get my LV ICSP to work I could test the loader...

BTW: If you have a system where you will be using a RS232 connection, why
not use that as the bootloader ?
Saves all the other pinns for regular I/O :)  (That's why I made mine USART
based.)

Kyrre


{Original Message removed}

2004\06\26@173746 by Wouter van Ooijen

face picon face
> Wouter's basic idea is sound. A single pin interface...
> Note the name, " *ZERO*  Pin Loader".
> Wouter uses the MCLR pin, not an I/O pin.

Confusion here: I have two bootloaders on my website: WLoader is a
more-or-less standard one-I/O-pin bootloader for 16F877(A) and
relatives, ZPL is a zero-I/O-pin loader (using /MCLR) for teh 18F452 and
relatives.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

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

2004\06\26@181119 by Bob Axtell

face picon face
Kyrre Aalerud wrote:
> Hehe.
> If only I could get my LV ICSP to work I could test the loader...
>
> BTW: If you have a system where you will be using a RS232 connection, why
> not use that as the bootloader ?
> Saves all the other pinns for regular I/O :)  (That's why I made mine USART
> based.)
>

The main advantage of the UART method is that in the application itself,
 the RS232 has to be used anyway, to perform the objective of the
product. Having the UART already setup for periodic updates makes
Kyrre's scheme more attractive, to me.

--Bob
--

Replier: Most attachments rejected
      --------------
        Bob Axtell
PIC Hardware & Firmware Dev
  http://beam.to/baxtell
      1-520-219-2363

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

2004\06\26@183232 by Howard Winter

face
flavicon
picon face
Kyrre,

On Sat, 26 Jun 2004 17:50:44 +0200, Kyrre Aalerud wrote:

> Is this better or wose than the sum method ?

If I remember rightly (it's late so I can't think
clearly enough to check!) if the last byte transmitted
is the checksum, the result of a rolling XOR of
everything before, when you XOR it you will end up with
zero if all was sent correctly.  So the receiver just
XORs everything it receives and the result should be
zero - easy!

> Maby I can do both ?

No need - it doesn't improve anything.

Cheers,

Howard Winter
St.Albans, England

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

2004\06\26@184928 by Byron A Jeff

face picon face
On Sat, Jun 26, 2004 at 11:01:19PM +0200, Jan-Erik Soderholm wrote:
> Byron A Jeff wrote :
>
> > Wouter's basic idea is sound. A single pin interface...
>
> Note the name, " *ZERO*  Pin Loader".
>
> Wouter uses the MCLR pin, not an I/O pin.

Jan-Erik,

I was talking about WLoader, not ZPL. WLoader uses a single I/O pin to do its
job. I do believe that I posted a pointer to the schematic and the WLoader page
in that message, yes?

I've been debating the conceptual merits of the two approaches. Wouter does
a great job of outlining the issues in his ZPL PDF documentation found in the
ZPL ZIP file here: http://www.voti.nl/dwarf/zpl.zip

His transparancy argument for I/O has merit. The short argument is that I/O
is scarce. More scarce than other resources like memory. So it behooves the
bootloader to use as little I/O as possible. Obviously a ZERO pin loader
(actually for nanowatt parts it's a half pin loader as MCLR does share space
with the RA5 input). Would use no I/O. Great, right?!

Well the other side of the debate is twofold:

1) Lack of verification. Since MCLR cannot be an output, the PIC cannot send
any status data about programming back. It's open loop.

2) Loss of debugging interface. See my message to Bob on that discussion.

I'm starting to think that it may be worth giving up one (or an extra half) pin
in order to get these features.

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

2004\06\26@190420 by Byron A Jeff

face picon face
On Sat, Jun 26, 2004 at 11:33:05PM +0100, Howard Winter wrote:
> Kyrre,
>
> On Sat, 26 Jun 2004 17:50:44 +0200, Kyrre Aalerud wrote:
>
> > Is this better or wose than the sum method ?
>
> If I remember rightly (it's late so I can't think
> clearly enough to check!) if the last byte transmitted
> is the checksum, the result of a rolling XOR of
> everything before, when you XOR it you will end up with
> zero if all was sent correctly.  So the receiver just
> XORs everything it receives and the result should be
> zero - easy!

Right. The question is how effective? Just conceptually XOR has a major
problem: 1) paired bit errors in the same column can result in an erroneous
packet with a valued checksum.

Consider the three byte stream ....1 ....1 ....1

When the LSB's are XORed the resumt is a 1. But when added the result is three.
Adding affects other columns in the checksum whereas XOR can only impact the
column it's in. Consider if there were two bit errors: ....0 ....1 ....0
The XORed result is still 1. Whereas the summed result is also 1, and would
indicate an error.

>
> > Maby I can do both ?
>
> No need - it doesn't improve anything.

Agreed. However it's best to pick the added result. Since adding and XORing
cost exactly the same, why not use the sum?

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

2004\06\26@195951 by Byron A Jeff

face picon face
On Sat, Jun 26, 2004 at 11:36:02PM +0200, Kyrre Aalerud wrote:
> Hehe.
> If only I could get my LV ICSP to work I could test the loader...
>
> BTW: If you have a system where you will be using a RS232 connection, why
> not use that as the bootloader ?
> Saves all the other pinns for regular I/O :)  (That's why I made mine USART
> based.)

You're asking this question of a couple of folks who have well thought out
the process. I actually addressed this issue with Tato. But let me throw out
a simple example to illustrate.

One project on my list is a MIDI sequencer. MIDI is a musical async serial
interface, not RS232. But even if it were, for example a caller ID box that
uses a modem for the CID interface, the principle is the same.

I have a conflicting usage for the port. I need it for the application at
one point in time, and I also need it for the bootloader. So I end up having
to do cable swaps each and every time I update the software.

I know that you're thinking of this as a "in the field" update tool. I use
bootloaders as my primary development tool. And the rule of thumb that I use
is that the less I have to mess with while developing, the faster I'll get
done.

So a bit banged interface is an excellent idea for a bootloader. While we'll
all agree that it'll take more code space to run, it gives three advantages:

1) That with minor effort, a port pin can be saved.
2) The separate debugging port is available as alluded to below.
3) The designer gets to pick the pin for the interface instead of having
it declared by the hardware pin selection.

I'll freely admit that Wouter has me quite spoiled when it comes to
bootloaders. He really thought out the issues, and followed it up with designs
that make sense. So everything else that comes along (including Wouter's own
ZPL) gets the comparison to the following feature list:

1) Single pin or less interface.
2) Less than 200 bytes in size.
3) User choosable bootloader pin.
4) Transparancy to the target application. Ideally any hex file should be
  loadable and executable without modification. except for...
5) Self protection. The bootloader should always be available even if the
  load fails. It shouldn't overwrite itself.
6) Verification. The application should not execute on a failed load and the
  PC application should be made aware of the failure.
7) Debugging interface for the application.
8) permanently utilize no resources other than program memory and the I/O pin
  from step 1.
9) Be available for all self writable PIC chips.

As of right now no loader that I know of meets all of these criteria.

* Wloader right now is the closest meeting 7 of 9 (failing #9 for 18F
 and the 16F88/16F819 family parts and #2 IIRC).

* ZPL fails #6, #7, #3 on a technicality, and #9. Maybe #2 also

* Tato's PLoader fails #5 and #9 and is currently written so that #1 fails as
 it uses 2 I/O pins. But a Wloader style interface can easily be added. Also
 I don't think it's application transparent, so #4 is out

* Yours fails #1, #3, #8 (all due to the USART) and #4, and of course has the
 #9 issue.

* Tiny fails #1, #3, #8 due to the USART. Currently it fails #9 because it
 doesn't do the 16F88 and 16F819 though it does have 18F support along with
 the  16F87X parts. It also fails #5 trusting the PC app to not overwrite
 it.

Also personally I have a #10 which is Linux based application applicability.
Not on the main list because it's relevant only to me. This has two phases:
Can the source be compiled with gpasm, and is there an application for
loading and executing applications. ZPL may meet both, the ZPL16F that I
wanted to write definitly met both. Both Tiny and Wloader used a couple of
macro contructs that threw gpasm off. Ploader assembles just fine, and
Woj's linwload can be transformed in less than an hour. Same for yours and
Tiny, while both linwload and Wouters XWISP in python drives Wloader. Wouter
also wrote the ZPL interface in python, and I've tested it a couple of times
too.

So my analysis is as follows:

* PLoader is my new frontrunner. It's small, bit bangs, works for the 18 pin
 nanowatt self programmable parts already. Also it assembles no problems.
 Throw in some transparancy, some verification, and a single pin interface
 (all pretty easy to do) and call it a day for now. Later on up port it to
 the 16F87X[A] and 18F (especially the 40 pin nanowatt huge 18F4320!) and
 have a great all around tool for development.

* WLoader is close. It's already successful in my book. Really only requires
 the 4-8 block write and pre-erase of blocks to work for 16F87XA (which
 Wouter has already done from what I understand) and 16F88/16F819. No current
 18F port yet.

* ZPL is intriguing. Only requires a MCLR pin to work! No verification or
 debugging capabilities. Also currently no 16F downport (I hope to get to it
 soon. I started preliminary testing a couple of months ago.)

* The USART based loaders are a decision on the dedication of the USART to
 the task.

But ideally I'd like to pick one and stick to it like glue. So the closer
the target fits to the list above, the better the overall value.

BAJ
>
> Kyrre
>
>
> {Original Message removed}

2004\06\26@200612 by Byron A Jeff

face picon face
On Sat, Jun 26, 2004 at 03:10:02PM -0700, Bob Axtell wrote:
> Kyrre Aalerud wrote:
> >Hehe.
> >If only I could get my LV ICSP to work I could test the loader...
> >
> >BTW: If you have a system where you will be using a RS232 connection, why
> >not use that as the bootloader ?
> >Saves all the other pinns for regular I/O :)  (That's why I made mine USART
> >based.)
> >
>
> The main advantage of the UART method is that in the application itself,
>  the RS232 has to be used anyway, to perform the objective of the
> product. Having the UART already setup for periodic updates makes
> Kyrre's scheme more attractive, to me.

See my other post. This presumes that the application's RS232 target and the
development RS232 target are the same. Fine for datalogging for example. But
if the the application wants to use the USART for MIDI, or a modem, or a
RS232 LCD panel, or to drive a IR/laser wireless interface, or to use an
XPORT ethernet to get connectivity, then the bootloader will be in conflict
with the applications use of the USART.

With a soft bitbanged interface, the USART can be dedicated to the application
as opposed to having to share it. You also get a free debugging serial port
for the application too.

Just a couple of pennies for the pot.

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

2004\06\26@200613 by Byron A Jeff

face picon face
On Sat, Jun 26, 2004 at 01:44:47PM -0700, Bob Axtell wrote:
> Bryon, Where can we get a copy of tato's bootloader? I have Wouter's
> already.

Sorry, I thought I posted the link:

http://propic2.com/ploader

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

2004\06\26@201029 by Kyrre Aalerud

flavicon
face
Genious.  I will test this.  If true, it's definately a great way to do
it...

Kyrre


----- Original Message -----
From: "Howard Winter" <@spam@HDRWKILLspamspamH2ORG.DEMON.CO.UK>
To: <KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU>
Sent: Sunday, June 27, 2004 12:33 AM
Subject: Re: [PIC:] 16F88 RS232 bootloader.


{Quote hidden}

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

2004\06\26@201030 by Byron A Jeff

face picon face
On Sat, Jun 26, 2004 at 11:08:33PM +0200, Kyrre Aalerud wrote:
> Actually, my loader isn't tying up the usart at all.  It only uses it during
> load.  Then the system itself can use it after boot to retrieve my logged
> data etc...  No response from PC within a few ms means go and boot...

I understand where you are coming from. In your case the load application and
the application application share the same physical RS232 interface. But as
I've pointed out elsewhere, it's no fun when the two conflict because the
bootloader needs to be connected to the PC, while the application needs to
be connected to something else.

Kyrre, it's a design choice. It's the right choice in your particular
application. I'm not knocking it. However I tend to view bootloading from
a general development perspective. See my list of 9 items for the ideal
bootloader in my other post for details.

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

2004\06\26@201649 by Kyrre Aalerud

flavicon
face
My system can't be updated while in use anyways.  It will be in a
radio-controlled boat barely skimming the surface of the water, logging
current consumption in the 1-200 amp range (1-40 amp in prototype) :)
The downloading of the data happens via RS232.  The circuit will be molded
into epoxy so I won't have access to the ICSP stuff when it's molded in.  To
be able to load a updater and flash it is much easier for me than using a
seperate programmer, also the guys who will test some of this stuff later
won't know up and down on the programmer.  The flasher will be a single util
you start up, connect the circuit and power it up.  It would be flashed and
that's the end of that.  Normally there would be another software running
talking to the circuits main program on the serial interface, exchanging
calibration parameters and logged data.

User friendly :)

Kyrre




{Original Message removed}

2004\06\26@203555 by Kyrre Aalerud

flavicon
face
I know what u are saying.  It would be as simple as adding bit-banging 1-pin
interface instead and call that function instead of feeding the usart
registers...

I did make a system once that used two different physical interfaces for
regular use and configuration.  I simply made a converter and used the
paralell port to talk to it.  Worked well.  Adapters is a possibility you
know.

Anyway...  Yeah, there will always be design-choices.

Kyrre


{Original Message removed}

2004\06\26@205500 by Bob Axtell

face picon face
Byron A Jeff wrote:
> On Sat, Jun 26, 2004 at 11:08:33PM +0200, Kyrre Aalerud wrote:
>
>>Actually, my loader isn't tying up the usart at all.  It only uses it during
>>load.  Then the system itself can use it after boot to retrieve my logged
>>data etc...  No response from PC within a few ms means go and boot...
>
>
> I understand where you are coming from. In your case the load application and
> the application application share the same physical RS232 interface. But as
> I've pointed out elsewhere, it's no fun when the two conflict because the
> bootloader needs to be connected to the PC, while the application needs to
> be connected to something else.
>
> Kyrre, it's a design choice. It's the right choice in your particular
> application. I'm not knocking it. However I tend to view bootloading from
> a general development perspective. See my list of 9 items for the ideal
> bootloader in my other post for details.

Well said. Most of my apps WILL be general apps (no committed RS232),
Bryan, so I will use the modified PLoader; so I agree on that score.

But I'd like to use Kyrre's for this first app, though, because of the
program update capability it lends. That's all.

[[aside: This F88 Bootloader conversation has been the best we've had
here in months!]]

--Bob
--

Replier: Most attachments rejected
      --------------
        Bob Axtell
PIC Hardware & Firmware Dev
  http://beam.to/baxtell
      1-520-219-2363

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

2004\06\27@003238 by Byron A Jeff

face picon face
On Sun, Jun 27, 2004 at 02:12:17AM +0200, Kyrre Aalerud wrote:
> Genious.  I will test this.  If true, it's definately a great way to do
> it...

I was going to repeat my caveat from my other post. But for some reason I
felt paranoid so I decided to run some experiments. So I wrote a quick
program that generates a random 8 byte message. It then pseudo-randomly
generates XOR and sums for 50 million test patterns. Emperical testing is
interesting. A few observations.

1) Howard is right. an 8 bit sum and 8 bit XOR generated exactly the same
number of matching patterns.

2) The marked difference occured when I doubled the size of the checksum.
The number of matches for a 50 million psuedo random sample seeded with
the time produced about 700 matches for the 8 byte sample and a 16 bit
checksum. The 8 bit checksum generated about 200000 pattern matches.

3) Since addition and xor generated the same number of patterns, I threw out
addition. I then bumped the checksum size to 32 bits. 0 matches in a 50 million
pseudo random sample. Excellent!

However the messages were only 8 bytes long, hardly representative. So I
bumped up the size of the target and samples to 64 bytes, which matches well
with the target packet. [Drum roll please?]

0 matches in 50 million random samples!

Just to make sure I was doing it right I backed it back down to 16 bits with
the 64 byte sample packets and 740 matches, which correlated with the result
with the 8 byte samples.

So with a minor cost to ram, code, and transmission time, a virtually
bulletproof checksum can be generated. Use a 4 byte checksum buffer cleared
to all zeros. Keep a count of which checksum byte to xor next. As you read
bytes xor to the current checksum byte then advance (of course wrapping around
when you get to the 4th one). Then end the packet by sending the 4 checksum
bytes in order starting with the current checksum byte.

Upon receipt (and xoring) of the 4 checksum bytes, the checksum should be 0.

It's still cheap and virtually foolproof.

BAJ
>
> Kyrre
>
>
> {Original Message removed}

2004\06\27@015515 by Robert Rolf

picon face
The problem with simple XOR checksums is that if any
bit(s) are bad in an even number of bytes, you don't detect
the error. e.g. LSB error for two bytes is not detectable.
1 xor 1=0 but error of 0 xor 0is also 0. With sum you get 2 or 0,
which is a clearly detectable difference.

Even a true 'checksum' misses any case where any even number of bytes
have the MSB errored. CRC is about the only way to reliably detect
bit errors.

Howard Winter wrote:
{Quote hidden}

XOR is much less robust than sum. See above comments.
Computation overhead is the same.

Robert

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\27@021838 by Russell McMahon

face
flavicon
face
> 2) The marked difference occured when I doubled the size of the checksum.
> The number of matches for a 50 million psuedo random sample seeded with
> the time produced about 700 matches for the 8 byte sample and a 16 bit
> checksum. The 8 bit checksum generated about 200000 pattern matches.

50E6/2^8 = 195,312 ~= 200,000  as above

50E6/2^16 = 763 ~= 700 as above

> 3) Since addition and xor generated the same number of patterns, I threw
out
> addition. I then bumped the checksum size to 32 bits. 0 matches in a 50
million
> pseudo random sample. Excellent!

50E6/2^32 = 0.012 ~= 0  as above

This seems to be about the same as you would expect from a standard CRC.

When the number of samples exceeds the number of combinations that the check
word can assume it must produce duplicates.
The trick (which you seem to have achieved here) is NOT producing
unnecessary duplicates when the number of states that the check word can
assume is more than the number of data words being checked.


       RM

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\27@024610 by Jim Robertson

flavicon
face
>
>
>So with a minor cost to ram, code, and transmission time, a virtually
>bulletproof checksum can be generated. Use a 4 byte checksum buffer cleared
>to all zeros. Keep a count of which checksum byte to xor next. As you read
>bytes xor to the current checksum byte then advance (of course wrapping around
>when you get to the 4th one). Then end the packet by sending the 4 checksum
>bytes in order starting with the current checksum byte.
>
>Upon receipt (and xoring) of the 4 checksum bytes, the checksum should be 0.
>
>It's still cheap and virtually foolproof.
>
>BAJ

Putting on my best humility suit in case I (too?) have missed the obvious
(Byron's

paranoia is catching. ;-)

..

But here goes...

Wouldn't any  packet of any length > 1 with either the LSb or MSb (for
example)
incorrectly set or reset on each byte have a 50% chance of failing to be
detected
by your "virtually foolproof" checksum?

-And-

How many combinations of  your 4 byte Xor result will Xor together and give
a Zero
result?

(I didn't get past Year 10 Math at school but my first guess would be
16777216.)

Your "virtually foolproof" system appears to me to be "virtually useless"
in the case of
serial comms as it has a good chance of missing a very common failure mode
(Framing
error, and the checksum itself is subject to this error when it is
transmitted.)

Even in the case of random errors it still has a 1/256 chance of being
wrong does it
not?

Also, getting back to the suggestion of both summing and Xoring. Are not these
the facts?

Both can miss the same error.
Both can detect an error that the other missed.
Therefore using both will detect more errors than either alone.

If a "virtually foolproof" checksum could be had by either Xoring or
Summing then why would anyone bother with far more robust CRC
algorithms?

Maybe I have missed something? I have been known to do that occasionally.

Regards,

Jim Robertson
NEWFOUND ELECTRONICS

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\27@101209 by David VanHorn

flavicon
face
At 12:32 AM 6/27/2004 -0400, Byron A Jeff wrote:

>On Sun, Jun 27, 2004 at 02:12:17AM +0200, Kyrre Aalerud wrote:
>> Genious.  I will test this.  If true, it's definately a great way to do
>> it...
>
>I was going to repeat my caveat from my other post. But for some reason I
>felt paranoid so I decided to run some experiments. So I wrote a quick
>program that generates a random 8 byte message. It then pseudo-randomly
>generates XOR and sums for 50 million test patterns. Emperical testing is
>interesting. A few observations.

Shouldn't be surprising. No matter how you generate it, an 8 bit verification has a 1/256 chance of being wrong. 16 bit is 2^8 more secure, and so on.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\27@101214 by David VanHorn

flavicon
face
At 11:46 PM 6/26/2004 -0600, Robert Rolf wrote:

>The problem with simple XOR checksums is that if any
>bit(s) are bad in an even number of bytes, you don't detect
>the error. e.g. LSB error for two bytes is not detectable.

This may be why they do add, triple, add, in UPC/EAN.
Their data field is only 12 bytes.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\27@120203 by Byron A Jeff

face picon face
On Sat, Jun 26, 2004 at 11:46:00PM -0600, Robert Rolf wrote:
> The problem with simple XOR checksums is that if any
> bit(s) are bad in an even number of bytes, you don't detect
> the error. e.g. LSB error for two bytes is not detectable.
> 1 xor 1=0 but error of 0 xor 0is also 0. With sum you get 2 or 0,
> which is a clearly detectable difference.

I do believe I said that sometime yesterday.

>
> Even a true 'checksum' misses any case where any even number of bytes
> have the MSB errored.

Until last night I would have agreed. However after some emperical testing
it's clear that the error rate is in fact the same. There's no difference in
the robustness of addition vs. xor when the checksum size is the same and the
sample size is large.

The next phase, which I did not take into account in my first run of
experiments is the fact that there will only be a few bits difference between
the target and the samples. In other words instead of a pseudo random
sampling of the entire message space we need to concentrate on messages with
a limited Hamming distance from the target. Systematically generated 1 and 2
bit errors should be enough to illustrate the difference since the argument
is that even bit error pairs will screw XOR up.

Since I already have the test frame in place this shouldn't take long

[virtual time passing...]

OK I'm back with interesting results. As expected both caught all 1 bit errors.
But the code went nuts on 2 bit errors with both algorithms (4 byte XOR and
4 single byte adds with no carry inbetween). But the add came out a lot better
The results on 100000 pseudo randomly generated targets:

xors matches=1499985
sum matches=554578

The sums generated nearly 1/3 less matches than xor over the same sample set.
So the assertion hold true, that adding is better than xor for an even number
of bit errors. Note that there are multiple matches per target, hence the
number of matches coming out larger than the number of targets. That seems
to be a good metric: average number of matches per target. I'll use it from
now on. So the above numbers would be 14.99 and 5.54 matches per target (MPT).

So let's eliminate xor and move onto the checksum size and how important
carry is to the equation. Let's run the same 2 bit error experiment under the
following conditions:

1) 8 bit. Should easily be the worst.
2) 2 8 bits add with no carries inbetween. Should be better but not as good as
3) 16 bit add carrying between the bytes.

Note that we already have the results of a 32 bit checksum with no carries.
That's the 5.54 MPT number above. Also it's a waste of time to do a 32 bit
sum with carries on a 64 byte message because the sum cannot exceed 16 bits
anyway. I'll redo the 32 bit, no carries just to give context.

Be right back....

OK I'm back. Here's the numbers at the 10000 target mark

00000010000 targets analyzed.
 total sum[0,8] matches=294811
 total sum[0,16] matches=135050
 total sum[1,16] matches=294811
 total sum[0,32] matches=55342


Where [0,8] means no carries between bytes and an 8 bit checksum. So it's
clear that carries are totally irrelavent, so don't waste time on them.
Extending the number of bits in the checksum improves performance because it
spreads out the errors. Note that we get the same 5.53 MPT. Note that there
are 4032 2 bit error combos. So the 5.53 gives us a 99.86 percent error detect
rate. Not bad for 4 bytes of storage/transmission and 6 times better than
a simple 8 bit checksum.


The results are pretty clear. 8 bit sucks whether or not you split the sums
or not. 32 bits gives enough of an advantage to consider using. adding gives
a significant advantage over xor when multiple bit errors occur.


> CRC is about the only way to reliably detect bit errors.

Agreed. But the truth of the matter is that we're trying to implement a simple
check that won't take a lot of code.

CRC is my next test. I found some algorithms here:
http://www.monitor-computing.pwp.blueyonder.co.uk/projects/crc16

But genpoly wasn't clearly specified and the optimized crc16 kept converging.
So no results yet. I'll try to take a look at it later.

BAJ

{Quote hidden}

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\27@142016 by Byron A Jeff

face picon face
On Sun, Jun 27, 2004 at 08:38:44AM -0500, David VanHorn wrote:
> At 11:46 PM 6/26/2004 -0600, Robert Rolf wrote:
>
> >The problem with simple XOR checksums is that if any
> >bit(s) are bad in an even number of bytes, you don't detect
> >the error. e.g. LSB error for two bytes is not detectable.
>
> This may be why they do add, triple, add, in UPC/EAN.
> Their data field is only 12 bytes.

Is that the same as this algorithm?

http://tinyurl.com/3e5cl

where:

checksum = (3*checksum + newbyte + 1) & 0xffff

It's a whole heap better than simple add or xor. I got 100 error detection on
all 2 bit errors and 99.9998 % on a random sampling of 100 million 64 byte
messages. It's so much better than adding or xor, that they don't even seem
to be worth discussing anymore.

I renamed my thread "Better 16 bit checksum" or somesuch. Let's talk about
this algorithm there.

BAJ

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\27@174547 by William Chops Westfield

face picon face
On Jun 27, 2004, at 9:01 AM, Byron A Jeff wrote:

>  However after some emperical testing it's clear that the error rate
> is in fact the same. There's no difference in the robustness of
> addition vs. xor when the checksum size is the same and the sample
> size is large.
>
Certain types of checksums are worse at detecting certain types of
errors that others.  An ADD is better than an XOR if a particular bit
happens to be prone to errors, for instance.  Two errors on the same
bit with an xor cancel each other out, not not necessarilly so for ADD.
(although the high bit is more sensitive for add, which is why things
like the IP checksum use end-around carry.)  CRCs that are very good at
detecting 'all single bit errors and 99.9% of double bit errors' might
really suck if the comm link normally drops or trashes 8 or more bits
at a time.  It's all pretty much "black magic" to me, expect for the
fact that it means that you need to pay attention if you're going to
deviate much from standard practices...

BillW

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\27@180247 by Kyrre Aalerud

flavicon
face
The transmission medium in our case is a serial datastream.  There is no
clock in the data, or on seperate channel.  It is usually asynchronous.
Asynchronous communication is actually most prone to error on the MSB if one
transmits data in the usual LSB to MSB fashion.

The timing error for one bit is accumulated to the last bit.  If we use a
centered-sample we might get an error if the bit-error is more than 50%
divided by number of bits pr word transmitted at a time.  Shorter words mean
more overhead but also more resynchronization between sender and receiver.
With the  accuracy of the oscillators and the ability to either use baudrate
generators or bit-banging to within less than 4% pr bit, the errors in the
transmission would come from other sources.

Anyway, MSB is most "fragile" so it is important to use a checksum that can
protect this bit.

(16F88 has a typical accuracy of +/- 1% but a worst case +/- 2%.  As long as
one uses a bitrate with less than 2% error one should actually be quite
safe.  That is, assuming a centered sample on the receiving end.)


Kyrre


{Original Message removed}

2004\06\27@181116 by Bob Axtell

face picon face
You can overcome SOME timing errors by simply adding a short wait
between each character, in both directions. Usually, just setting the PC
to N/8/2 (2 stop bits) handles it from that end. On the PIC end, just a
simple wait of 2-stop bit length will do.

It makes the process slower, but allows the UARTS to resynch.

--Bob

Kyrre Aalerud wrote:

{Quote hidden}

> {Original Message removed}

2004\06\27@190222 by Kyrre Aalerud

flavicon
face
Yep.

Actually, a good UART, not a cheap or universal one, would be able to resync
with a "too early" first stop-bit as it would be edge triggered.  It would
also detect the timing error.

Kyrre


{Original Message removed}

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...