Searching \ for 'PIC16C87x serial bootloader development' 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=serial
Search entire site for: 'PIC16C87x serial bootloader development'.

Truncated match.
PICList Thread
'PIC16C87x serial bootloader development'
1998\12\21@123913 by Rick Farmer

flavicon
face
I just finished reading the 16C87x databook. Very nice part. The one thing
that makes it stand out is that program memory can be written under program
control. On top of that a small portion of program memory can be write
protected. Sounds like a good place to stick a resident bootloader program
to me.

It would seem that Microchip designed the chip with this in mind. The next
question is whether they are going to release a piece of bootloader code. If
so their web site makes no mention of it. If not I could see writing one
myself. Is anyone else working on this? If so, several of us could work on
this to make a universal loader that could be used by all. I think that the
loader itself is an almost trivial piece of code. The trick is making it
flexible enough to be useful to almost everyone and as well as novice
friendly.

Ideally the code should not require any special software or hardware on the
host side so that any terminal program that can talk X,Y,Z or modem would
suffice. HyperTerminal may be a shitty COM package, but at least you know
everyone has it. I don't really see any need for any fancy relocation
options since that can be done with a linker. The real question is whether
it should work like the old Moto Buffalo and activate on reset, or should
act like a TSR always looking for a escape sequence from the serial port.
I'm partial to a design that runs on reset and that can also be called by
the mainline code if desired, but that is otherwise dead code. The main
reason is that it minimizes complexity and interference with the mainline
code. Any comments?

Rick Farmer                | 1123 N. Water Street
Electrical Engineer        | Milwaukee, Wi. 53202
Adicon Consulting & Design | Phone 414-276-8080
spam_OUTrfarmerTakeThisOuTspamadicon.com         | Fax 414-276-8085

1998\12\21@132951 by Stefan Sczekalla-Waldschmidt

flavicon
face
Rick Farmer wrote:
>
>  I just finished reading the 16C87x databook. Very nice part. The one thing
> that makes it stand out is that program memory can be written under program
> control. On top of that a small portion of program memory can be write
> protected. Sounds like a good place to stick a resident bootloader program
> to me.
>
>  It would seem that Microchip designed the chip with this in mind. The next
> question is whether they are going to release a piece of bootloader code. If
> so their web site makes no mention of it. If not I could see writing one
> myself.

I4ve seen a "Technical Brief"  TB0025 at the Microchip Web-Site which
describes a kind of down-loader. Maybe you just need to rework it ... I
didn4t looked at it very close.

Found it in the alpanumerical listing of Applicationnotes.

But I4m very interested in first experiences with the new chip.

Kind regards

       Stefan

1998\12\21@144711 by Rick Farmer

flavicon
face
{Quote hidden}

The code in TB0025 only programs the flash. It has none of the higher level
stuff. I'm talking about a complete code image that used the UART and a 232
converter to talk to a COM program on a PC. It would have to be simple
enough that a newbie could just add an exclude statement to his code, add a
232 converter and use a standard xtal and be read to go with a preprogrammed
(with the protected bootloader) part.

Rick Farmer                | 1123 N. Water Street
Electrical Engineer        | Milwaukee, Wi. 53202
Adicon Consulting & Design | Phone 414-276-8080
.....rfarmerKILLspamspam.....adicon.com         | Fax 414-276-8085

1998\12\21@155718 by Andy Kunz

flavicon
face
> Ideally the code should not require any special software or hardware on the
>host side so that any terminal program that can talk X,Y,Z or modem would
>suffice. HyperTerminal may be a shitty COM package, but at least you know
>everyone has it. I don't really see any need for any fancy relocation

>the mainline code if desired, but that is otherwise dead code. The main
>reason is that it minimizes complexity and interference with the mainline
>code. Any comments?

Rick,

I have one just about done.  It accepts an Intel HEX file directly, burns
the code space appropriately.  It is activated by pulling a pin low on boot
(has pull-up for normal operation, and can be still used for other purposes
after starting normal operation).

This can't be tested because I don't have a chip, but it "works" on a '77.

Andy


==================================================================
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
==================================================================

1998\12\21@171746 by Rick Farmer

flavicon
face
{Quote hidden}

Cool. How do you handle flow control between the host and the target?

Rick Farmer                | 1123 N. Water Street
Electrical Engineer        | Milwaukee, Wi. 53202
Adicon Consulting & Design | Phone 414-276-8080
@spam@rfarmerKILLspamspamadicon.com         | Fax 414-276-8085

1998\12\21@190322 by wwl

picon face
On Mon, 21 Dec 1998 11:21:06 -0600, you wrote:

> I just finished reading the 16C87x databook. Very nice part. The one thing
>that makes it stand out is that program memory can be written under program
>control. On top of that a small portion of program memory can be write
>protected. Sounds like a good place to stick a resident bootloader program
>to me.
>
> It would seem that Microchip designed the chip with this in mind. The next
>question is whether they are going to release a piece of bootloader code. If
>so their web site makes no mention of it. If not I could see writing one
>myself. Is anyone else working on this? If so, several of us could work on
>this to make a universal loader that could be used by all. I think that the
>loader itself is an almost trivial piece of code. The trick is making it
>flexible enough to be useful to almost everyone and as well as novice
>friendly.
>
> Ideally the code should not require any special software or hardware on the
>host side so that any terminal program that can talk X,Y,Z or modem would
>suffice. HyperTerminal may be a shitty COM package, but at least you know
>everyone has it.
Strongly disagree - this would inevitably increase the loader size,
and therefore waste valuable code space in the PIC.

1998\12\22@082702 by Andy Kunz

flavicon
face
> Cool. How do you handle flow control between the host and the target?

Originally it burned each byte as received, but for "field production"
purposes I felt it wiser to go with some sort of protocol.

The sender doesn't put out the next line until it gets a CR from the PIC.
If it gets a bad line, it sends ESC and ignores all lines.

The command BURN to the PIC gets the thing to start reading the hex file.

Andy

==================================================================
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
==================================================================

1998\12\22@163018 by gwaiche

picon face
Hi!

Can't we just use an In Circuit Progamming process
instead of a Bootloader?

The 16C87x can be very comfortable if used with ICP...

Gael

1998\12\23@091657 by Andy Kunz

flavicon
face
ICSP works just fine. That's how you program the boot loader into the chip!

At 10:19 PM 12/22/98 +0100, you wrote:
>Hi!
>
>Can't we just use an In Circuit Progamming process
>instead of a Bootloader?
>
>The 16C87x can be very comfortable if used with ICP...
>
>Gael
>
==================================================================
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
==================================================================

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