James Newton, Host wrote:
> Ok then, how about an LVP programmer that uses only non-programmed
> components and takes a stream from a serial port like Tony's ASCII
> programmer. Perhaps the clock signal could be developed without RC
> circuits.

Why is that better than a high voltage programmer which can always program
the chip regardless of how the LVP bit is set?

> Again, the point is to not require any programming software,

But why?  There clearly needs to be *some* software between the disk and the
serial port (or whatever port), so why not let that software do a few other
useful things.  Requiring no software seems backwards.  There is going to be
complexity somewhere.  It makes sense to push that complexity onto the host
where developing it is easier, there are essentially no speed and memory
constraints, and the incremental cost is basically zero.

When I design a programmer I think about the higherarchy of host software,
firmware, and hardware.  You want to push complexity as much as possible to
the beginning of that chain except as required to meet the performance and
capability goals.  I have just revised my programmer host protocol again to
put less burden on the programmer in a few areas.  When I originally started
that several years ago, I was envisioning the programmer performing some
operations at a higher level on its own.  These were never implemented and I
later realized that they can be managed from the host without speed penalty.
The programmer firmware performs the lower level operations that the host
can't do fast enough, but as much as possible the host does the "thinking"
and high level control.

> but rather
> use a data file that loads a bootloader or like that. The data file
> only needs to be developed once, but having server based software for
> turning a hex file into such a datafile would be very cool as well.

The data file needs to be developed at least once for each HEX file.  You'll
probably do this with a program.  Given that that program will execute
instantaneously in human terms, why not run the program each time the data
file is needed from the HEX file.  Then you can run it with any HEX file at
any time.  Then you realize that since you can make the data file for free
whenever you want it, you don't need to save it.  You're making a temporary
data file on demand.  It's really just a data stream, since it's not saved
anymore.  So now you have a program that reads a HEX file on one side and
writes to a serial port on the other side to "convert" the HEX file
information into whatever is required for the low-complexity programmer to
write it into the target PIC.  Sound familiar?

> It really seems to me that it would be nice to have a very simple
> programming circuit that could load at least one or two types of blank
> PIC chip.  And it isn't like these chips stop being made. You can still
> buy 16F84's and you can still use a 16F84 to make a programmer that
> will program just about anything else. Right?

So how about a 16F648A, which is actually cheaper than a 16F84?  The
EasyProg (http://www.embedinc.com/easyprog) isn't the absolute simplest
circuit because robustness and flexibility were also a concerns, but it's
not real complicated either.  It would be easy to pare down the EasyProg
circuit if you didn't care about variable Vdd and didn't try to accomodate
multiple target footprints in the ZIF socket.  If you do that, you can even
start with the EasyProg firmware and strip some things out.  Many of the
protocol commands are now optional that weren't when the EasyProg was
designed, so the existing host software will just work as long as the
firmware adheres to any of the published protocol spec versions.  You could
even program dsPICs with it.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist