> And for that we now have bootloaders which are more convenient and the
> update can be done by the customer without extra hardware and without a
> technician. This leaves your programmer to serve low volume projects where
> the convenience of the bootloader does not justify the development cost to
> implement it. Frankly, I think it's a neat idea but I carry around a ICD2
> with my laptop so I wouldn't buy it. Also I'm developing a bootloader for my
> application for customer updates.
>   
Good experience. I enjoyed it, too.

> So maybe there's a US$ 100k/year market for these things which works out at
> a mere 500 units per year and that sounds pretty easy to sell. However I
> can't see how you would reach that market without spending a significant
> portion of that revenue in advertising. Google ads might do for 50
> units/year, for the remaining 450 what would you do?
>   
The market is primarily with field service engineers. These guys drag 
around enough stuff, and want a CERTAIN,
RELIABLE way of upgrading products. Are you saying they would like 
dragging around an ICD2, MPLAB, and
a laptop, when a 4"x2" programmer with an SD card would do perfectly? 
Frankly, the ICD2 is too unreliable to be
used as a field service tool; it takes too long to get it moving in the 
right direction, like an old steam engine locomotive.

Only a couple of years ago, updates consisted of replacement chips; 
first UV PROMS, then UV uPs, now flash
uP's. MOST are now interfaced by some ICSP scheme. PICs are no different.

The other application is on the production floor. The engineering 
department releases the updated firmware for the
whatsit which is almost ready to be boxed up and shipped. The updated 
firmware goes into the bottom of the
production programmer each morning. The programmer charged at its holder 
all night, and its LiIon or NiMH
battery pack is topped off. The QC engineer notes which product needs 
final updates, dials it in, plugs in a tiny ICSP
plug, and updates are done in a few seconds; NOT just the program 
section, but ALL of it; the config bits as well.

Let's look at bootloaders for a second. I've written several, how about 
you? The customer dials up your website and
gets the  "latest firmware" release to be installed. He points to the 
link, and in a few minutes, the new firmware is installed.
Here are the pitfalls with bootloaders:

1. The actual firmware can be intercepted and stolen easily. Even if an 
encryption scheme is used, it can't be very solid,
since there is almost no space in the PIC RAM for encryption minterms. 
Also, adding encryption adds enormous complexity;
if you don't know the correct password, THEN what?

2. The client won't routinely use it. You can lead them to water, but 
they may not drink. Maybe because the encryption process
is too complex?

3. Rarely are changes ONLY firmware changes.A product shipment or a 
field-service visit is usually needed.

Flames and unkempt emails accepted.

--Bob  
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist