gnupic: Thread: Re: [gnupic] [ANN] Pikme PIC Bootloader (for 16F819 etc)

On Mon, Jul 24, 2006 at 05:59:22PM -0500, Frank Sergeant wrote:
> The Pikme PIC Bootloader is available at
> 
>           http://pygmy.utoh.org/pikme
> 
> I call it "The World's Simplest PIC Bootloader".

I took a read. Very impressive!

> It is set up for the PIC16F819 but should be easy to modify for other
> PIC variants that are capable of programming their own flash memory.

Cool. And it already has the Row Erase Routine in it.

> All source is included and commented extensively.  License is
> MIT/BSD-style.

Again Excellent! The bootloader I was working with 
(Octavio Nogueira's ####@####.#### 16F819 bootloader from 2004
had similar licensing requirements.

> The downloader is in Python.  I run it under Linux (Debian) but it
> should run at least on Unix/Linux/Windows (anywhere Python and its
> serial module run).

Good choice. That's make the code portable.

> It uses only half of an I/O pin on the PIC (that is, it can use an
> input-only pin) and even that pin can be used for other purposes by the
> application, providing it doesn't wiggle at boot time.

Interesting choice. That's getting close to Wouter van Ooijen's ZPL
which used wiggling on MCLR to reset the PIC after specific time delays.
The length of time that the PIC ran determined the bit transmitted.
ZPL = Zero Pin Loader.

> It uses a one-way serial interface from the PC to the PIC (so, 2 wires:
> the PC's TX pin and ground).  It is bit-banged to do inverted TTL serial
> (fake RS232) so that no MAX232 or similar is needed.

Depending on the serial port, this may be a problematic choice. Unfortunately
some serial ports don't even come close to generating the 4V required to 
register as a 1 on the PIC. And unfortunately it's in spec because RS-232
allows for 3V or higher to be a valid signal.

Also I read your pinouts.txt file. Using a pot to tune the voltage is a bit
time consuming. A better choice may be to refer back to Wouter's El-Cheapo
serial bootloader interface. The schematic is located here:

http://www.voti.nl/wloader/wl2-2.gif

A description can be found for the WLoader project in the parent directory
of that image file. Simply put the R2/D1 resistor/5V zener interface is
sufficient to solve all of the voltage issues, giving output from about
-0.5V to 4.7V or so to the PIC pin. No tuning necessary.

It's the interface I use on all of my current bootloader projects and it
works well.

Note that Wouter voices some concerns with trusting the PIC protection
diodes to clamp and keep the part working properly. Frankly since a 10
cent zener (well a 65 cent one if you buy from the RatShack) can easily
do the job, why not use it?

> I use it with the RA5/Vpp/MCLR* pin but 3 equates in the source code
> allow you to use another I/O pin if you prefer.

In addition you can switch to a full I/O pin, add the R1/R3 resistors and
get a serial output channel on that same pin.

> The downloader picbl.py needs the name of the hex file and the number of
> the serial port.  So, to download dummy1.hex via the second serial port
> (COM2: on Windows, /dev/ttyS1 on Linux), you would run something like
> 
>        python picbl.py dummy1.hex 1

Cool.

> I'll be glad to have feedback on it and will try to adjust the
> documentation if anything isn't clear.

Clear as freshly wiped glass. I keep debating to myself how important is
robustness and verification in the bootloading process. I'm been
working on Tato's bootloader on and off and here are some of the specs 
I've come up with:

- Using 'U' as the syn character for autobauding.

- Sending packets with checksums to allow for verification. Currently I
plan to implement the TCP checksum with the wrap around carry. I've also
looked at Fletchers and add/triple/add as other checksum techniques.

- Using the single pin half duplex scheme of Wouter's to allow for output
and verification.

- I was thinking of locating the entire bootloader in low memory. It seems
to me once the application cannot be transparent and must account for low
memory that the bootloader can occupy low memory.

- Finally I'm trying to figure out how to build a Trivial programmer that
runs from the serial port. Something along the lines of Tony Nixon's
ASCII programmer here:

http://www.piclist.com/techref/com/picnpoke/www/http/projects/prog.html

My first attempt (the Trivial BootStrap 555) is incomplete only because
I keep trying to get verification working. I've built and tested the
transmitter and it latches bits just fine. So it should be able to program
just fine. And now I have yet another fine Python program (along with
Wouter's ZPL loader in Python) to use to wiggle the bits.

Frank, this is a fine effort and very much apprciated. I have an intern
working on PIC bootloader stuff. I'm going to forward your stuff to him
and get him to test it out and adapt it for the 16F88, which is our chip
of choice. I'll let you know of any results that come from it.

Thanks again.

BAJ

I am still wondering what are the advantage of a bootloader / bootstrap? Is
is because you would like to make it possible to update the firmware by the
user / engeneer?

Thanks
Tamas


On 25/07/06, Byron A Jeff ####@####.#### wrote:
>
> On Mon, Jul 24, 2006 at 05:59:22PM -0500, Frank Sergeant wrote:
> > The Pikme PIC Bootloader is available at
> >
> >           http://pygmy.utoh.org/pikme
> >
> > I call it "The World's Simplest PIC Bootloader".
>
> I took a read. Very impressive!
>
> > It is set up for the PIC16F819 but should be easy to modify for other
> > PIC variants that are capable of programming their own flash memory.
>
> Cool. And it already has the Row Erase Routine in it.
>
> > All source is included and commented extensively.  License is
> > MIT/BSD-style.
>
> Again Excellent! The bootloader I was working with
> (Octavio Nogueira's ####@####.#### 16F819 bootloader from 2004
> had similar licensing requirements.
>
> > The downloader is in Python.  I run it under Linux (Debian) but it
> > should run at least on Unix/Linux/Windows (anywhere Python and its
> > serial module run).
>
> Good choice. That's make the code portable.
>
> > It uses only half of an I/O pin on the PIC (that is, it can use an
> > input-only pin) and even that pin can be used for other purposes by the
> > application, providing it doesn't wiggle at boot time.
>
> Interesting choice. That's getting close to Wouter van Ooijen's ZPL
> which used wiggling on MCLR to reset the PIC after specific time delays.
> The length of time that the PIC ran determined the bit transmitted.
> ZPL = Zero Pin Loader.
>
> > It uses a one-way serial interface from the PC to the PIC (so, 2 wires:
> > the PC's TX pin and ground).  It is bit-banged to do inverted TTL serial
> > (fake RS232) so that no MAX232 or similar is needed.
>
> Depending on the serial port, this may be a problematic choice.
> Unfortunately
> some serial ports don't even come close to generating the 4V required to
> register as a 1 on the PIC. And unfortunately it's in spec because RS-232
> allows for 3V or higher to be a valid signal.
>
> Also I read your pinouts.txt file. Using a pot to tune the voltage is a
> bit
> time consuming. A better choice may be to refer back to Wouter's El-Cheapo
> serial bootloader interface. The schematic is located here:
>
> http://www.voti.nl/wloader/wl2-2.gif
>
> A description can be found for the WLoader project in the parent directory
> of that image file. Simply put the R2/D1 resistor/5V zener interface is
> sufficient to solve all of the voltage issues, giving output from about
> -0.5V to 4.7V or so to the PIC pin. No tuning necessary.
>
> It's the interface I use on all of my current bootloader projects and it
> works well.
>
> Note that Wouter voices some concerns with trusting the PIC protection
> diodes to clamp and keep the part working properly. Frankly since a 10
> cent zener (well a 65 cent one if you buy from the RatShack) can easily
> do the job, why not use it?
>
> > I use it with the RA5/Vpp/MCLR* pin but 3 equates in the source code
> > allow you to use another I/O pin if you prefer.
>
> In addition you can switch to a full I/O pin, add the R1/R3 resistors and
> get a serial output channel on that same pin.
>
> > The downloader picbl.py needs the name of the hex file and the number of
> > the serial port.  So, to download dummy1.hex via the second serial port
> > (COM2: on Windows, /dev/ttyS1 on Linux), you would run something like
> >
> >        python picbl.py dummy1.hex 1
>
> Cool.
>
> > I'll be glad to have feedback on it and will try to adjust the
> > documentation if anything isn't clear.
>
> Clear as freshly wiped glass. I keep debating to myself how important is
> robustness and verification in the bootloading process. I'm been
> working on Tato's bootloader on and off and here are some of the specs
> I've come up with:
>
> - Using 'U' as the syn character for autobauding.
>
> - Sending packets with checksums to allow for verification. Currently I
> plan to implement the TCP checksum with the wrap around carry. I've also
> looked at Fletchers and add/triple/add as other checksum techniques.
>
> - Using the single pin half duplex scheme of Wouter's to allow for output
> and verification.
>
> - I was thinking of locating the entire bootloader in low memory. It seems
> to me once the application cannot be transparent and must account for low
> memory that the bootloader can occupy low memory.
>
> - Finally I'm trying to figure out how to build a Trivial programmer that
> runs from the serial port. Something along the lines of Tony Nixon's
> ASCII programmer here:
>
> http://www.piclist.com/techref/com/picnpoke/www/http/projects/prog.html
>
> My first attempt (the Trivial BootStrap 555) is incomplete only because
> I keep trying to get verification working. I've built and tested the
> transmitter and it latches bits just fine. So it should be able to program
> just fine. And now I have yet another fine Python program (along with
> Wouter's ZPL loader in Python) to use to wiggle the bits.
>
> Frank, this is a fine effort and very much apprciated. I have an intern
> working on PIC bootloader stuff. I'm going to forward your stuff to him
> and get him to test it out and adapt it for the 16F88, which is our chip
> of choice. I'll let you know of any results that come from it.
>
> Thanks again.
>
> BAJ
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>

There is an even smaller bootloader, tiny bootloader, at

   http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm

It's less than 100 words!

Yes, it uses serial port as the interface for downloading.

- Mengjin Su -

>From: "Frank Sergeant" ####@####.####
>Reply-To: ####@####.####
>To: ####@####.####
>CC: "Frank Sergeant" ####@####.####
>Subject: [gnupic] [ANN] Pikme PIC Bootloader (for 16F819 etc)
>Date: Mon, 24 Jul 2006 17:59:22 -0500
>
>The Pikme PIC Bootloader is available at
>
>           http://pygmy.utoh.org/pikme
>
>I call it "The World's Simplest PIC Bootloader".
>
>It is set up for the PIC16F819 but should be easy to modify for other
>PIC variants that are capable of programming their own flash memory.
>
>All source is included and commented extensively.  License is
>MIT/BSD-style.
>
>The downloader is in Python.  I run it under Linux (Debian) but it
>should run at least on Unix/Linux/Windows (anywhere Python and its
>serial module run).
>
>It uses only half of an I/O pin on the PIC (that is, it can use an
>input-only pin) and even that pin can be used for other purposes by the
>application, providing it doesn't wiggle at boot time.
>
>It uses a one-way serial interface from the PC to the PIC (so, 2 wires:
>the PC's TX pin and ground).  It is bit-banged to do inverted TTL serial
>(fake RS232) so that no MAX232 or similar is needed.
>
>I use it with the RA5/Vpp/MCLR* pin but 3 equates in the source code
>allow you to use another I/O pin if you prefer.
>
>The downloader picbl.py needs the name of the hex file and the number of
>the serial port.  So, to download dummy1.hex via the second serial port
>(COM2: on Windows, /dev/ttyS1 on Linux), you would run something like
>
>        python picbl.py dummy1.hex 1
>
>I'll be glad to have feedback on it and will try to adjust the
>documentation if anything isn't clear.
>
>
>--
>Frank
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: ####@####.####
>For additional commands, e-mail: ####@####.####
>

On Tue, Jul 25, 2006 at 03:27:46PM +0100, Tamas Rudnai wrote:
> I am still wondering what are the advantage of a bootloader / bootstrap? Is
> is because you would like to make it possible to update the firmware by the
> user / engeneer?

It's a long running debate of its effectiveness. When I'm developing I like
to have all my resources available. Also I like to be able to pick the
connection interface between the PC and the PIC. When you use a programmer
you have to use Microchips interface. Another issue is that unless you're
using ICD, you cannot debug using the same channel that you use to program.

Nearly all of my successful projects where developed with a bootloader.

BAJ

On Tue, Jul 25, 2006 at 03:44:36PM +0000, mengjin su wrote:
> There is an even smaller bootloader, tiny bootloader, at
> 
>   http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm
> 
> It's less than 100 words!
> 
> Yes, it uses serial port as the interface for downloading.

Size really isn't the issue. I have an issue with Tiny precisely because
it does use the USART, which is a valuable resource, for programming.

BAJ

Byron A Jeff ####@####.#### wrote:

Thank you for your detailed and thoughtful comments.

Let me say first, that I find various bootloaders and also software
minimization and particularly hardware minimization *interesting*.  I am
not suggesting a single approach (even mine!) is the best in every
case.  I may well spend more time fooling around with a bootloader than
it is actually worth.

> > It uses only half of an I/O pin on the PIC (that is, it can use an
> > input-only pin) and even that pin can be used for other purposes by the
> > application, providing it doesn't wiggle at boot time.
 
> Interesting choice. That's getting close to Wouter van Ooijen's ZPL
> which used wiggling on MCLR to reset the PIC after specific time delays.
> The length of time that the PIC ran determined the bit transmitted.
> ZPL = Zero Pin Loader.

Thanks for reminding me of that.  I've seen his page but haven't taken
the time to study it in detail.  I felt the initial mention of the code
taking about 1K disqualified it from consideration for a 16F818/819 (with
only 1 or 2 K of instruction words).  Of course, that doesn't mean than
some aspects wouldn't be useful.
 
> > It uses a one-way serial interface from the PC to the PIC (so, 2 wires:
> > the PC's TX pin and ground).  It is bit-banged to do inverted TTL serial
> > (fake RS232) so that no MAX232 or similar is needed.
 
> Depending on the serial port, this may be a problematic choice. Unfortunately
> some serial ports don't even come close to generating the 4V required to 
> register as a 1 on the PIC.

That's a good point.  The first thing I would try if I ran into this
would be a pull-up between the PIC's 5 V and the PIC's serial input
pin.  (And, if using the RA5/Vpp/MCLR* pin for the serial input, that
pin should be pulled up or down anyway if the serial port is not
connected.)  So, this would be an even simpler circuit than the one I'm
using with my desktop machine.)

> Also I read your pinouts.txt file. Using a pot to tune the voltage is
> a bit time consuming.

I guess that depends on how many host PCs you would use.  It is a
one-time action per host machine.  I wire the (miniature) pot, connect
the PC serial side (but not the PIC side), measure the output as I turn
the pot until the output voltage is approximately -5 V and viola (as we
in the string section like to say), it's done.  Yes, there is no
guarantee the negative and positive excursions of the PC's serial port
are symmetrical, in that case some further adjustment would be necessary
-- again one-time per host PC.  Another choice would be to measure the
voltage and calculate the 2 resistors for a non-adjustable voltage
divider.  I might even guess at it (assuming, perhaps 11 volts and scale
it to 5 volts, download an LED flashing program (I usually download a
serial output program that says "Hello") and see what happens.  The pot
seems like a nice compromise.

>A better choice may be to refer back to Wouter's El-Cheapo
> serial bootloader interface. The schematic is located here:

Yes, I appreciate that but I'm of 2 or 3 minds about it.  If I get
burned bad enough some day, I might lean more toward it.  

> Note that Wouter voices some concerns with trusting the PIC protection
> diodes to clamp and keep the part working properly.

Thanks for the caution.  I'll keep that in mind.  

> I keep debating to myself how important is robustness and verification
> in the bootloading process.

I admit I was a little nervous when I first started on this bootloader.
I was prepared to use an extra pin on the PIC for transmitting back to
the PIC (Tx) (yes, I realize we could use a single pin as Wouter does and as
Dallas 1-wire does) if absolutely necessary.  For feedback while
developing the bootloader, I did use Tx, bit-banged as with Rx.  The
code for that is still present, but commented out, in boot.asm.

So far, I have been tickled to find the bootloader reliable.  My purpose
for this bootloader is to use it for quick turn around while developing,
rather than for using it in the field in finished products for software
upgrade.  Because of that, I think I can work without a net, since I
don't have far to fall.  The Python downloader does take various steps
to verify each line of the hex file (but, really, if we can't trust our
assembler, who can we trust).  Can we trust the serial port to get the
data across a 3 foot cable?

Also, extensive verification can be built into the application that is
downloaded via the bootloader.  It does not necessarily need to be
present in the bootloader itself.

I might well argue the other side, about the cost of lost, expensive
(human) programmer time, upset customers, etc. just to save a little
hardware cost and complexity, if we were talking about a production
quality field upgrader.  So, I am not necessarily disagreeing.

> - I was thinking of locating the entire bootloader in low memory. It seems
> to me once the application cannot be transparent and must account for low
> memory that the bootloader can occupy low memory.

That's very interesting.  I had been thinking of moving *parts* of the
bootloader (as much as would fit) from high-memory down to the first
32-word block, since most of that 32-block is now wasted.  Your idea,
though, would eliminate the need of adjusting where the high-memory part
of the bootloader is ord'd for different processors.  I like it.

Some approaches let the user application sit in that first 32-word block
and the bootloader overlays the 'goto loader' etc so that gets
reprogrammed every time.  That makes me even more nervous (unaccountably, I
guess) than the blind downloading.

> - Finally I'm trying to figure out how to build a Trivial programmer that
> runs from the serial port. Something along the lines of Tony Nixon's
> ASCII programmer here:
> 
> http://www.piclist.com/techref/com/picnpoke/www/http/projects/prog.html

Thanks for the link.  I hadn't seen that before.  I hope to find the
time to take a careful look.

> Frank, this is a fine effort and very much apprciated. I have an intern
> working on PIC bootloader stuff. I'm going to forward your stuff to him
> and get him to test it out and adapt it for the 16F88, which is our chip
> of choice. I'll let you know of any results that come from it.

Thank you again.  I will look forward to how he gets on with it.  I
think the 16F87 and 16F88 are my (14-bit) chips of choice also, I just
haven't switched over yet due to inertia.  However, I am wondering
whether I should switch directly to an 18F chip.


-- 
Frank

Tamas Rudnai ####@####.#### wrote:

> I am still wondering what are the advantage of a bootloader /
> bootstrap? Is is because you would like to make it possible to update
> the firmware by the user / engeneer?

I had been pleased with the JDM-style serial PIC hardware programmers
(the PG1 and PG2 made by Olimex and also sold by Spark Fun).  They are
*very* reasonably priced and had been working fine for me (via pikdev on
Linux).

Recently, I couldn't get some 16F819 chips to program and verify
reliably.  No, I did not change my desktop PC or its serial port.  I
tried 3 or 4 PCs.  I measured the Vpp (only statically, so it still
might have been marginal).  Did I get a "bad" batch of '819 chips that
might have needed e.g. 13.5 V rather than only e.g. 11 V?

Besides, the JDM approach does not use the PC's serial port ground as
the circuit ground, which meant, even when I was using chips that PG1 or
PG2 could program ok, that I often needed to unplug the programmer from
my development circuit before I could test it, and then unplug whatever
from the development circuit before I could re-attach the programmer.  I
hate the plugging and unplugging (and sometimes forgetting).

So, I bought the Olimex PG3 parallel PIC hardware programmer from Spark
Fun.  (I should have bought their parallel cable at the same time, as a
number of my parallel cables did not work -- fortunately one I had did
work).  Here, ground is ground, and I've been very happy with it.
However, there can still be a lot of plugging and unplugging, if your
project's circuit's use of pins conflicts with the hardware programmer's
pins.

So, to summarize: fast turn around while developing.  I like a
bootloader to eliminate the plugging and unplugging.  There are other
ways to eliminate the plugging and unplugging, but I think a bootloader
is the simplest.  My bootloader takes just one pin on the PIC -- a pin
that my circuit does not need for any other purpose.  I can leave it
connected the PC's serial port all the time.

I have mixed feelings about a (remote) user/customer upgrading the
firmware.  Yes, a bootloader can be used for this.  I have indeed used
it for this.  I guess it depends on the circumstances.

I might like the idea of a bootloader for burning the application at
production time, but I worry too much about whether the bootloader
itself would get burned correctly into the chip before it is soldered
onto the PCB.  If it didn't, then what do you do?  I think you have to
be sure you can attach a hardware programmer.  I like Spark Fun's
approach of not soldering a programming connector, but just leaving the
holes in the PCB.  Then the connectory is held in place manually when
programming.  If you use a DIP, you could use a DIP-clip (if nothing else
on the PCB prevents the clipping part).  You could use a bed-of-nails
approach.  You could just throw the bad board away.  In other words, I
am nervous about relying totally on a bootloader for production
programming of the application.  

Just some quick thoughts.


-- 
Frank

mengjin su ####@####.#### wrote:

> There is an even smaller bootloader, tiny bootloader, at
> 
>   http://www.etc.ugal.ro/cchiculita/software/picbootloader.htm
> 
> It's less than 100 words!
> 
> Yes, it uses serial port as the interface for downloading.


Thank you.  I hope to look at it carefully eventually.


-- 
Frank

(I hope I am not posting this a second time.  I think my first try
failed due to using the wrong From: address.)

Byron A Jeff ####@####.#### wrote:

Thank you for your detailed and thoughtful comments.

Let me say first, that I find various bootloaders and also software
minimization and particularly hardware minimization *interesting*.  I am
not suggesting a single approach (even mine!) is the best in every
case.  I may well spend more time fooling around with a bootloader than
it is actually worth.

> > It uses only half of an I/O pin on the PIC (that is, it can use an
> > input-only pin) and even that pin can be used for other purposes by the
> > application, providing it doesn't wiggle at boot time.
 
> Interesting choice. That's getting close to Wouter van Ooijen's ZPL
> which used wiggling on MCLR to reset the PIC after specific time delays.
> The length of time that the PIC ran determined the bit transmitted.
> ZPL = Zero Pin Loader.

Thanks for reminding me of that.  I've seen his page but haven't taken
the time to study it in detail.  I felt the initial mention of the code
taking about 1K disqualified it from consideration for a 16F818/819 (with
only 1 or 2 K of instruction words).  Of course, that doesn't mean than
some aspects wouldn't be useful.
 
> > It uses a one-way serial interface from the PC to the PIC (so, 2 wires:
> > the PC's TX pin and ground).  It is bit-banged to do inverted TTL serial
> > (fake RS232) so that no MAX232 or similar is needed.
 
> Depending on the serial port, this may be a problematic choice. Unfortunately
> some serial ports don't even come close to generating the 4V required to 
> register as a 1 on the PIC.

That's a good point.  The first thing I would try if I ran into this
would be a pull-up between the PIC's 5 V and the PIC's serial input
pin.  (And, if using the RA5/Vpp/MCLR* pin for the serial input, that
pin should be pulled up or down anyway if the serial port is not
connected.)  So, this would be an even simpler circuit than the one I'm
using with my desktop machine.)

> Also I read your pinouts.txt file. Using a pot to tune the voltage is
> a bit time consuming.

I guess that depends on how many host PCs you would use.  It is a
one-time action per host machine.  I wire the (miniature) pot, connect
the PC serial side (but not the PIC side), measure the output as I turn
the pot until the output voltage is approximately -5 V and viola (as we
in the string section like to say), it's done.  Yes, there is no
guarantee the negative and positive excursions of the PC's serial port
are symmetrical, in that case some further adjustment would be necessary
-- again one-time per host PC.  Another choice would be to measure the
voltage and calculate the 2 resistors for a non-adjustable voltage
divider.  I might even guess at it (assuming, perhaps 11 volts and scale
it to 5 volts, download an LED flashing program (I usually download a
serial output program that says "Hello") and see what happens.  The pot
seems like a nice compromise.

>A better choice may be to refer back to Wouter's El-Cheapo
> serial bootloader interface. The schematic is located here:

Yes, I appreciate that but I'm of 2 or 3 minds about it.  If I get
burned bad enough some day, I might lean more toward it.  

> Note that Wouter voices some concerns with trusting the PIC protection
> diodes to clamp and keep the part working properly.

Thanks for the caution.  I'll keep that in mind.  

> I keep debating to myself how important is robustness and verification
> in the bootloading process.

I admit I was a little nervous when I first started on this bootloader.
I was prepared to use an extra pin on the PIC for transmitting back to
the PIC (Tx) (yes, I realize we could use a single pin as Wouter does and as
Dallas 1-wire does) if absolutely necessary.  For feedback while
developing the bootloader, I did use Tx, bit-banged as with Rx.  The
code for that is still present, but commented out, in boot.asm.

So far, I have been tickled to find the bootloader reliable.  My purpose
for this bootloader is to use it for quick turn around while developing,
rather than for using it in the field in finished products for software
upgrade.  Because of that, I think I can work without a net, since I
don't have far to fall.  The Python downloader does take various steps
to verify each line of the hex file (but, really, if we can't trust our
assembler, who can we trust).  Can we trust the serial port to get the
data across a 3 foot cable?

Also, extensive verification can be built into the application that is
downloaded via the bootloader.  It does not necessarily need to be
present in the bootloader itself.

I might well argue the other side, about the cost of lost, expensive
(human) programmer time, upset customers, etc. just to save a little
hardware cost and complexity, if we were talking about a production
quality field upgrader.  So, I am not necessarily disagreeing.

> - I was thinking of locating the entire bootloader in low memory. It seems
> to me once the application cannot be transparent and must account for low
> memory that the bootloader can occupy low memory.

That's very interesting.  I had been thinking of moving *parts* of the
bootloader (as much as would fit) from high-memory down to the first
32-word block, since most of that 32-block is now wasted.  Your idea,
though, would eliminate the need of adjusting where the high-memory part
of the bootloader is ord'd for different processors.  I like it.

Some approaches let the user application sit in that first 32-word block
and the bootloader overlays the 'goto loader' etc so that gets
reprogrammed every time.  That makes me even more nervous (unaccountably, I
guess) than the blind downloading.

> - Finally I'm trying to figure out how to build a Trivial programmer that
> runs from the serial port. Something along the lines of Tony Nixon's
> ASCII programmer here:
> 
> http://www.piclist.com/techref/com/picnpoke/www/http/projects/prog.html

Thanks for the link.  I hadn't seen that before.  I hope to find the
time to take a careful look.

> Frank, this is a fine effort and very much apprciated. I have an intern
> working on PIC bootloader stuff. I'm going to forward your stuff to him
> and get him to test it out and adapt it for the 16F88, which is our chip
> of choice. I'll let you know of any results that come from it.

Thank you again.  I will look forward to how he gets on with it.  I
think the 16F87 and 16F88 are my (14-bit) chips of choice also, I just
haven't switched over yet due to inertia.  However, I am wondering
whether I should switch directly to an 18F chip.


-- 
Frank

Byron A Jeff wrote:

> Note that Wouter voices some concerns with trusting the PIC protection
> diodes to clamp and keep the part working properly. Frankly since a 10
> cent zener (well a 65 cent one if you buy from the RatShack) can easily
> do the job, why not use it?
> 

I agree conservative design is good, but probably grossly overdone in 
this particular case.

If the pin in question is an IO (not MCLR) you have the intrinsic well 
diodes to clamp to vdd.vss for free.  They are in addition to ESD 
protection.
The external zener is likely to be slow enough (due to lead inductance) 
to be of little benefit.

For mclr, its designed to handle Vpp, so should be safe enough too.

john