Paul B. Webster VK2BZC wrote:
>
> Mark Willis wrote:
>
> > I have had a number of times where, given ONLY the hex file, I've
> > needed to burn 1 code protect OFF part to read or even send back to
> > someone (to make sure I did indeed have the right .hex file, etc.) -
> > and then many more parts that're set with Code Protect=all.
>
>   I think you're better editing the hex file.  The point is made that
> with no standardization, it's a bit much to expect the chip programmer
> to know which way is which.  You really end up having to tell it a
> "magic" address *and* data pair to modify the hex file.

Do-able, though I'd actually have to open a {Gasp!} Manual or Datasheet
to do that - you really expect me to be able to do that?  <G>  I could
see having a "control panel" type applet in there that does the advanced
options, and have the usual interface be VERY much simplified;  Let's be
honest, though, by the time someone's taken the time to learn assembly
for the PIC series, they probably CAN cope with the current MPLab
interface (I deal with Needham's EMP-10, EMP-20, MLab, the gang
programmer, the Parallax interface, the Atmel interface, and about 8
other IDE's some months, it's not THAT bad - after the first time, you
usually have it fairly well figured out.)

>   Since the hex file already contains (or should) the "magic" address
> and a *mostly* correct value, you're much safer to edit this with a text
> editor in the situation you gave.  And in general, safer to re-compile
> with the chip-specific option in the more "knowledgeable" compiler.

Trust the user, though <G>

> >  *  For burning "many" OTP copies of a particular PIC chip, at least,
> > it'd sure be nice if the programmer had some nice RAM in there & it
> > could accept the entire image into that RAM, verify all the checksums
> > to make sure that your serial or parallel cable didn't have a loose
> > connection (or your PC or OS had hardware-related timing problem, or a
> > software problem like NT <G>), and then, once THAT was done, the
> > programmer could start to burn the part.
>
>   Isn't that what all the "high-end" programmers do?  The ones that you
> program in the shop, take to the field and use hand-held to update your
> firmware?
>
>   Now, since moderately capable serial (I2C) EEPROMs are available, this
> should be dirt easy for a PIC-based (16F84 for instance) programmer.
> --
>   Cheers,
>         Paul B.

I've thought of a "Laptop-based" mobile development system, for in the
field - battery powered, able to supply power to an attached DataRase ][
on a timed basis, maybe some day I'll get moved in & do it.  Don't hold
your breath, tho <G>  If Canon can put a printer in a laptop, I can put
this in one <G>

  Mark