-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > 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. I'd like to know what those reasons are, considering that I'm doing some of the development for CUMP. Perhaps if you told me, I could address them. > >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. In the situation of CUMP (communitary etc...) The entire design principle is sharing everything as we go. > 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. :) As you seem to be a bit out of the loop on CUMP, perhaps I should explain that CUMP uses something very much like personality modules. Please go read the summary at http://www.piclist.com/techref/piclist/cump/index.htm > 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. CUMP will really be capable of far more than that. Since the last time this list has seen it, it has been revised to have a bit different approach to programming. It has now been decided that a byte code (which James Newton has posted a description for) will be used to implement delays and pin wiggling. In effect, it has now been decided that it will run something very much like a byte-code controlled bitbanging programming interface, and as such will be able to directly support anything that requires less than 25V, and can accept slower than the minimum timing available (as yet undecided). Since CUMP will be controlled by this byte code, I think it will be fairly simple to set up CUMP to act as a logic analyser, a glitch finder(maybe), a power supply, an oscilloscope (with a little host software) and any number of other useful development devices other than a programmer. I look forward to its fruition. - --Brendan -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use iQA/AwUBPWEw1wVk8xtQuK+BEQLEvwCgyIrNnCW9H/cqqQlKDosXK4IOQSwAnAv3 Gj81AqdsSsMK+gQmzUaMxSY9 =1HcF -----END PGP SIGNATURE----- -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu