I built a Tait-style programmer, which is pretty close to the
simplest possible way I can think of to program a PIC, without
much (hardwarily) to go wrong. It successfully programs a bunch
of PIC samples I got (16F627/8), but will not program another bunch
of samples (16F777, 16F870, etc).
One thing that made me suspicious is that all the ones which work
came from the same shipment of samples, and all the ones that fail
came from another shipment. Maybe I got a bad set of samples. But
after reordering the "bad" ones, I get the same failures on the new
parts.
As far as I can tell, the programmer's working fine. It succeeds and
fails the same whether driven by PICALL on Windows or my own programmer
code on Unix.
So... either there's something fundamentally weird about the programmer
or I have two sets of bad samples. I find the latter a little hard to
believe, but before I go out and just buy a commercial programmer, what
kind of quality history have you found with Microchip's samples? Have
they been really good, or would it be worth it for me to purchase a
couple of PICs from another vendor and try them?
--
Steve Willoughby | "It is our choices... that show what we truly
<spam_OUTsteveTakeThisOuTalchemy.com> | are, far more than our abilities."
| --Albus Dumbledore, in Harry Potter and the
| Chamber of Secrets, by J. K. Rowling
>I built a Tait-style programmer, which is pretty close to the
>simplest possible way I can think of to program a PIC, without
>much (hardwarily) to go wrong. It successfully programs a bunch
>of PIC samples I got (16F627/8), but will not program another bunch
>of samples (16F777, 16F870, etc).
>
>One thing that made me suspicious is that all the ones which work
>came from the same shipment of samples, and all the ones that fail
>came from another shipment. Maybe I got a bad set of samples. But
>after reordering the "bad" ones, I get the same failures on the new
>parts.
>
>As far as I can tell, the programmer's working fine. It succeeds and
>fails the same whether driven by PICALL on Windows or my own programmer
>code on Unix.
>
>So... either there's something fundamentally weird about the programmer
>or I have two sets of bad samples. I find the latter a little hard to
>believe, but before I go out and just buy a commercial programmer, what
>kind of quality history have you found with Microchip's samples? Have
>they been really good, or would it be worth it for me to purchase a
>couple of PICs from another vendor and try them?
>
>
>
They have always worked for me.
I'm going to shamelessly recommend that since you have a PIC16F628 you
could make a Wisp628 (voti.nl)
The programming algorithms for the PIC's have gained tremendous complexity
(needlessly so, methinks) and those parts require a completely new approach
in order to program them.
> Steve Willoughby wrote:
>
>> I built a Tait-style programmer, which is pretty close to the
>> simplest possible way I can think of to program a PIC, without
>> much (hardwarily) to go wrong. It successfully programs a bunch
>> of PIC samples I got (16F627/8), but will not program another bunch
>> of samples (16F777, 16F870, etc).
>>
>> One thing that made me suspicious is that all the ones which work
>> came from the same shipment of samples, and all the ones that fail
>> came from another shipment. Maybe I got a bad set of samples. But
>> after reordering the "bad" ones, I get the same failures on the new
>> parts.
>>
>> As far as I can tell, the programmer's working fine. It succeeds and
>> fails the same whether driven by PICALL on Windows or my own programmer
>> code on Unix.
>>
>> So... either there's something fundamentally weird about the programmer
>> or I have two sets of bad samples. I find the latter a little hard to
>> believe, but before I go out and just buy a commercial programmer, what
>> kind of quality history have you found with Microchip's samples? Have
>> they been really good, or would it be worth it for me to purchase a
>> couple of PICs from another vendor and try them?
>>
>>
> They have always worked for me.
> I'm going to shamelessly recommend that since you have a PIC16F628 you
> could make a Wisp628 (voti.nl)
>
> --
> Martin K
> The programming algorithms for the PIC's have gained tremendous complexity
> (needlessly so, methinks) and those parts require a completely new approach
> in order to program them.
I think the reason for the increased programming complexity
is the effort to speed up the process. By a factor 8 in the
case of the 'A' v.s. non 'A' parts. As PIC flash capacity
increases, do you really want to wait 655 seconds (11 minutes
for 10msec/location) for a 65k word part?
I can live with a more complex algorithm if it saves me 10
minutes programming time.
> Bob Axtell wrote:
>
>> The programming algorithms for the PIC's have gained tremendous
>> complexity
>> (needlessly so, methinks) and those parts require a completely new
>> approach
>> in order to program them.
>
>
> I think the reason for the increased programming complexity
> is the effort to speed up the process. By a factor 8 in the
> case of the 'A' v.s. non 'A' parts. As PIC flash capacity
> increases, do you really want to wait 655 seconds (11 minutes
> for 10msec/location) for a 65k word part?
>
> I can live with a more complex algorithm if it saves me 10
> minutes programming time.
>
> Robert
Very good point, Robert. But look at the PIC18F "advances"; it
takes 15 payloads to send a single word. Nothing faster about
that scheme. Looks like it was developed after hours at Hooter's.
> Robert Rolf wrote:
>
>> Bob Axtell wrote:
>>
>>> The programming algorithms for the PIC's have gained tremendous
>>> complexity
>>> (needlessly so, methinks) and those parts require a completely new
>>> approach
>>> in order to program them.
>>
>>
>>
>> I think the reason for the increased programming complexity
>> is the effort to speed up the process. By a factor 8 in the
>> case of the 'A' v.s. non 'A' parts. As PIC flash capacity
>> increases, do you really want to wait 655 seconds (11 minutes
>> for 10msec/location) for a 65k word part?
>>
>> I can live with a more complex algorithm if it saves me 10
>> minutes programming time.
>>
>> Robert
>
>
> Very good point, Robert. But look at the PIC18F "advances"; it
> takes 15 payloads to send a single word. Nothing faster about
> that scheme. Looks like it was developed after hours at Hooter's.
"All instructions are 20 bits, consisting of a leading 4-bit
command followed by a 16-bit operand which depends
on the type of command being executed. To input a
command, PGC is cycled four times. The commands
needed for programming and verification are shown in
Table 2-3.
Depending on the 4-bit command, the 16-bit operand
represents 16 bits of input data or 8 bits of input data
and 8 bits of output data."
Doesn't seem THAT bad.
"
Typically, all of the program buffers are written in parallel
(Multi-Panel Write mode). In other words, in the case
of a 64-Kbyte device (8 panels with an 8-byte buffer per
panel), 64 bytes will be simultaneously programmed
during each programming sequence.
"
So if you're writing 64 bytes at a time, it would of
course require more 'payloads' to deliver the data.
I didn't realize the 18F was 32 times more efficient
at writing. And so what if more commands are required?
They're sent at megahertz, not the 100 hertz of programming
time.
> Bob Axtell wrote:
>
>> Robert Rolf wrote:
>>
>>> Bob Axtell wrote:
>>>
>>>> The programming algorithms for the PIC's have gained tremendous
>>>> complexity
>>>> (needlessly so, methinks) and those parts require a completely new
>>>> approach
>>>> in order to program them.
>>>
>>>
>>>
>>>
>>> I think the reason for the increased programming complexity
>>> is the effort to speed up the process. By a factor 8 in the
>>> case of the 'A' v.s. non 'A' parts. As PIC flash capacity
>>> increases, do you really want to wait 655 seconds (11 minutes
>>> for 10msec/location) for a 65k word part?
>>>
>>> I can live with a more complex algorithm if it saves me 10
>>> minutes programming time.
>>>
>>> Robert
>>
>>
>>
>> Very good point, Robert. But look at the PIC18F "advances"; it
>> takes 15 payloads to send a single word. Nothing faster about
>> that scheme. Looks like it was developed after hours at Hooter's.
>
>
> Really?
>
> ww1.microchip.com/downloads/en/DeviceDoc/30499b.pdf
> PIC18F6X2X/8X2X
>
> "All instructions are 20 bits, consisting of a leading 4-bit
> command followed by a 16-bit operand which depends
> on the type of command being executed. To input a
> command, PGC is cycled four times. The commands
> needed for programming and verification are shown in
> Table 2-3.
> Depending on the 4-bit command, the 16-bit operand
> represents 16 bits of input data or 8 bits of input data
> and 8 bits of output data.
That's correct. Been that way since 1995.
> "
>
> Doesn't seem THAT bad.
Its worse.
>
> "
> Typically, all of the program buffers are written in parallel
> (Multi-Panel Write mode). In other words, in the case
> of a 64-Kbyte device (8 panels with an 8-byte buffer per
> panel), 64 bytes will be simultaneously programmed
> during each programming sequence.
But each one of those 64 bytes, being unique, have to be
shoved into a buffer to be written. 20bits per pop. Plus all
of the table setups. Takes about 15 20-bit writes for each
word written into the PIC18F device. There's not any savings
anyplace that I can see.
MY math says it takes about 8x what it does to write the
same amount of PIC16F data word.
> "
>
> So if you're writing 64 bytes at a time, it would of
> course require more 'payloads' to deliver the data.
>
> I didn't realize the 18F was 32 times more efficient
> at writing. And so what if more commands are required?
> They're sent at megahertz, not the 100 hertz of programming
> time.
I didn't either. Megahgertz? Gosh, I gotta get better glasses...
> Bob Axtell wrote:
>
> > The programming algorithms for the PIC's have gained
> > tremendous complexity (needlessly so, methinks) and
> > those parts require a completely new approach
> > in order to program them.
>
> I can live with a more complex algorithm if it saves me 10
> minutes programming time.
Yep, right.
If I plan to use "PIC model X" and my programmer supports
"PIC model X", then I couldn't care less whatever happens
between the programmer and the PIC itself. Just as with what
happens under the hood of my oscillioscope (well, even
under the hood of my car, b.t.w :-) :-) ).
Now, regarding the original question :
> I built a Tait-style programmer,..
> ...It successfully programs a bunch
> of PIC samples I got (16F627/8), but will not program
> another bunch of samples (16F777, 16F870, etc).
And does the documentation specificaly say that that programmer
should be able to program all those PICs ??
You can probably be (close to) 100% sure that there is nothing
wrong with our samples.
On Wed, 9 Mar 2005, Jan-Erik Soderholm wrote:
> And does the documentation specificaly say that that programmer
> should be able to program all those PICs ??
Yes and no. The programmer itself is almost, but not quite, as
blindingly simple as you can get -- parallel port -> hex buffer ->
PIC chip. So assuming that most PIC chips program with a 13V Vpp,
5V Vdd, and some fiddling with PGD and PGC, it's just a matter of
software at that point.
I wrote my own programming software based on the Microchip datasheets
which runs under BSD. So if I did that correctly, it should be
compatible with my chips. I also used PICALL for Windows as a
test when the first didn't work for the 16F870. It's supposed to
do that one at least, so there's probably something in the timing
of the programming cycle (or something) which both my homebuilt
(and admittedly naive) code, and the third-party (but now unsupported)
program, are missing.
> You can probably be (close to) 100% sure that there is nothing
> wrong with our samples.
That's my assumption as well, but I thought it was an odd coincidence
that the parts which did and didn't work happened to be from separate
sample shipments. So I thought it was at least worth asking.
--
Steve Willoughby | "It is our choices... that show what we truly
<EraseMEstevespam_OUTTakeThisOuTalchemy.com> | are, far more than our abilities."
| --Albus Dumbledore, in Harry Potter and the
| Chamber of Secrets, by J. K. Rowling
On Tue, 8 Mar 2005, Martin Klingensmith wrote:
> They have always worked for me.
> I'm going to shamelessly recommend that since you have a PIC16F628 you
> could make a Wisp628 (voti.nl)
That's not a bad idea. I may just give that a try.
--
Steve Willoughby | "It is our choices... that show what we truly
<stevespam_OUTalchemy.com> | are, far more than our abilities."
| --Albus Dumbledore, in Harry Potter and the
| Chamber of Secrets, by J. K. Rowling
alchemy.com> | are, far more than our abilities."
