Nigel Broad wrote:
> I am considering writing software to program 16C6X/7X.
> Please can you explain which particular pulse timing specifications
> cause the problem?

I'm replying to the list just in case anyone else is interested (if
you can't understand why anyone should want to waste their time
building their own PIC programmer hit delete now!).

My programming hardware more or less directly connects the PC parallel
port to the PIC.  This means I have to get the PC itself to generate
the exact waveforms required.  Needless to say this is the basis of
the problem.

Some PICs (like the 16x84) have very lax timing requirements and it is
easy to meet the specs.  Others (like the 16C5X chips) need a
particular line to be pulsed for 100us.  I can get close to the specs
for these.  I do this by using the PC's internal timer (approx 1us
resolution) and turning off PC interrupts for the whole length of the
pulse.  The serial-mode EPROM-based PICs (16C6X/7X, 12C5XX, etc.)
should be programmed by sending a 6-bit command to start programming,
waiting a while and then sending a 6-bit command to stop programming.
The time between the PIC fully receiving the two commands should be
100us.  This I can't do.  Or at least I can't guarantee the timing is
within spec.

There are basically two problems: if I want the hardware to work
reliably (particularly if its connected over a longish cable) then the
time taken to send a command can be close to 100us on its own; and, if
I don't turn off interrupts, the PC could steal time during the
critical period between the two commands being received.  What little
I've learnt about PCs suggests it's not a good idea to turn off
interrupts for more than 200us or so.

I note that several people on the list have written software to
program the serial-mode EPROM PICs using similar hardware to my own.
Perhaps their software doesn't meet the specs either (some I've looked
at uses 1ms programming pulses for example) or they have a clever
solution which I haven't thought of (quite likely).  In any case, it
may not even be necessary to meet the specs.  My 16C6X/7X software is
certainly not within spec although it seems to work but I don't supply
it to anyone else just in case (the old "unerasable" code-protection
problem is another reason :-)

Good luck with writing your own software.

David
--
http://www.man.ac.uk/~mbhstdj