Simple bootloader for AVR?

>This is the device you are looking for, we use these to upgrade AVR
firmware
>in the field by non-electronic people.

Not what I'm looking for - The application gathers some data, which is
in EEPROM, The end-user wants to collect, analyze and modify this data
with their PDA. I.e. they need a UI that says "Current setting A is 54,
press < to decrement, > to increment. Since you last visited, sensor B
has triggered 47 times". They want the firmware update feature to be
built into this UI. The person doing that UI doesn't want to have to
learn too much about flash-loader protocols.

larwe@larwe.com wrote:
> 
... snip ...
> 
> Not what I'm looking for - The application gathers some data, which is
> in EEPROM, The end-user wants to collect, analyze and modify this data
> with their PDA. I.e. they need a UI that says "Current setting A is 54,
> press < to decrement, > to increment. Since you last visited, sensor B
> has triggered 47 times". They want the firmware update feature to be
> built into this UI. The person doing that UI doesn't want to have to
> learn too much about flash-loader protocols.

Sounds dangerous to me.  It means unsophisticated personnel have
the ability to (possibly accidentally) update the firmware with
unknown data.  Experience shows that even 8 levels of "Are you
sure" queries will still fail to protect, even with knowledgeable
operators.

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

>Sounds dangerous to me. It means unsophisticated personnel have
>the ability to (possibly accidentally) update the firmware with
>unknown data. Experience shows that even 8 levels of "Are you

There is a potential for erasure, yes. However the downside risk is not
enormous. This is a vending application. The field tech needs a way to
get auditing information (credits in, product dispensed), modify a few
parameters like pricing and some specialized information related to the
product being dispensed, and also run some simple tests to verify that
the sensors and actuators are working OK.

The original plan was to use a laptop running a VB app to do the UI
and, if firmware upgrades are necessary (I think this will be rare;
everything we could think of is already parameterized in EEPROM), let
the field tech use an ISP cable and a batchfile-based reflash
operation. However the end-user wants something pocket-sized rather
than a big ol' laptop, hence my request for a bootloader.

The BOM cost for the whole board is in the order of $50, and all the
I/Os are on a few D connectors, so it is not much effort for the tech
to carry around one or two spare boards, too. The board is designed so
that if the chip does happen to get erased or worse than erased (e.g.
bad clocking option selected), it can be HV-programmed in circuit.

> As cheap as CPUs are, you might consider a second CPU whose job is to 
> reprogram the first one.

Sure, but this is slightly more effort than writing a custom bootloader in
the main CPU :)

-- 
Here, in a large house, formerly a house of state, lives Mr. Tulkinghorn. It
is let off in sets of chambers now, and in those shrunken fragments of its
greatness, lawyers lie like maggots in nuts.

I found an appnote from AVR freaks that looks interesting. It says the
bootloader works in combination with AVRprog (AVRstudio), but since all
code is supplied, it shouldn't be hard to figure out the available
functionality (and build your own update.exe ?).
http://www.avrfreaks.net/Tools/showtools.php?ToolID=328
Regards