>When we started the CUMP project, there were only a few "close to
>universal" programmers out there and they cost a LOT of money.
>Everything else seemed to be available, the only missing element
>was enough people from enough different backgrounds to provide
>the programming algorithems. And I expected when Tony Nixon
>donated his Engine programmer (which was again, just about what
>we wanted to build, but without algorithms for other than a few
>PICs) I figured people would start building them or buying the
>kit from Tony (as others have build the "free"ICD or purchased
>one from Mchip) and work to add their programming algorithms for
>other target chips to the web site via the form at the bottom of
>the page.

having used a so-called "universal programmer" that was supposed to be able
to be software updated to handle any chip and programming algorithm and
voltage anyone might use, only to be unable to get updates after about 5
years, I suspect the CUMP will never make it for some other reasons.

>Instead, we got hung up in re-design after re-design, trying to
>compensate for every little possible problem that we percieved
>with the Engine. If we had started by just building Engines and
>publishing (SHAREING) the algorithms that we got to work, we
>would be far ahead of where we are now.

This is what happens when you try and do something which is universal across
all manufacturers program algorithms. There are just so many variations in
timing and voltage requirements that somewhere compromises happen. The
universal programmer I mentioned above did exactly that to me. I had a
particular brand of eproms that it had programmed happily, but on purchasing
a new batch, had a horrendous failure rate. It turned out that the
programming algorithm was nothing like the manufacturer specified, but it
worked on older chips. I ended up building a stripboard circuit with a
couple of one-shots to do the manufacturers algorithm correctly and then
copied parts I could program with this. Chips that then failed in the
programmer would verify satisfactorily after programming in this board.

For another reason why the CUMP is likely to not program everything,
consider why successful programmer manufacturers like DATA I/O use
personality modules, least all the ones I came across did, it may be they
have newer models that don't, but I doubt these will do 1702's either. :)

The idea of a universal micro programmer is great, but realistically, how
many different (manufacturers) micros do you really use at one time? I would
be surprised if it was more than 2, maybe 3 at the outside for a very
specialised project, and then they are likely to be on different boards,
with separate development teams, so having separate programming hardware is
not that much of an issue.

It is not my intention to criticize the CUMP as a project, but every time I
have seen an attempt at doing something along these lines, it seems to have
fallen through the cracks as people realise why DATA I/O programmers, and
others of their adaptability cost so much.

With the PBK, I see an aim of getting something that is reliable for a
beginner to have operating without needing a dose of hardware debugging
knowledge. The proposal combines programming hardware, target micro, and
simple I/O to get the user up and running, to a point where the fun bit
begins. Perhaps some LED's with drivers, where the driver input can be
patched around to any PIC pin with a flying lead for diagnostic purposes to
see if pins are changing state. This as near as we should get to the "logic
analyser" proposal IMHO.

Building something on a breadboard in the manner of the photo Olin showed is
OK for someone with knowledge of hardware debugging to pick up on why
something does not work. Is it the program, is it an iffy connection? Trying
to sort this out without knowing which it is will be daunting to any
beginner, but to one trying to get "on the learning treadmill" will be a
mountain to climb. If they have built their own programmer, that adds
another unknown into the list - did the chip program correctly, how do I
know it did, or has the programmer driver program just not given me a
suitable error message? This is the part of the loop we are trying to steer
beginners around, and get them to a point where they can do the fun bits,
and come back to the hardware fun bits for a project when they have the
software fun bits under control.

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu