Olin Reading your thread[s] about a production programmer reminds me that I need a production programmer. I will soon start out programming about 250 16F676's a week so programming speed is important. There are two stages of product(DUT) testing DC and RF. I need to program the DUT first before any testing of course so in the first (DC) station I need to build in a programmer. (I don't have the time or money to build a complex switching network as it will likely cause more problems than it is worth and I need a different caliber/type of technician to do the RF testing so after the 1st DC test the DUT will be moved and manually connected to an RF network analyzer. In the beginning both stations will be driven from the same PC. The next product that will require an ATE testing setup will have a serial control port so I'd prefer to have a production programmer that was USB so I could have the serial port of the PC free for LAbview to exercise the DUT's serial port. Later on as production increases there will be two separate PCs and later on dedicated stations for each separate product line. The next generation of the product will have a USB or RS232 control port methinks/hopes...my customers are already requesting USB and they don't have the RS232 ones yet.) Back to the first product: To plan for staffing needs I need to know about how long it will take to program & verify each device (along with the rest of the test[s]) and if this is faster than a MPLAB PM3? Or is this a function of the device and not the programmer? Also do you have examples of your scripts being called from Labview? (I can't imagine not being able to call exe or bat files from LabView but I don't recall doing it but it has been more than a few days since I wrote anything in that environment. ) So while I would prefer your USB programmer you mentioned a few posts earlier but if the proprog /serial port controlled one goes a lot faster (I'd be surprised if that were the case) then I reckon that I would prefer the faster one if the speed difference is significant. In the end serial port cards are not that expensive but why buy something with a serial port instead of a USB. Phillip Things should be as simple as possible but no simpler PS I still think you are an arrogant horse's arse but I have little doubt your programmers work well Phillip Coiner CTO, GPS Source, Inc. Your source for quality GNSS Networking Solutions and Design Services, Now! -----Original Message----- From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf Of Gerhard Fiedler Sent: Wednesday, December 06, 2006 5:49 AM To: piclist@mit.edu Subject: Re: [PIC] Why the preoccupation with bus powered programmers? Olin Lathrop wrote: > I think there are three broad catagories of use for PIC programmers: > production, professional development, and hobbyist. > > Production: > - Does the same job repetitively. > - Probably embedded in a production test/calibration fixture, > mechanically making this easy is a plus. > - Must be automatable from command scripts or another program. Native > program rarely used directly by the operator. > - Operator is relatively unskilled, low paid, often not on site. > - Reliability is critical. > - Price is not a high priority. > > Professional development: > - Used by engineer or technician as needed. > - Should be scriptable so that can be automatically run as part of > firmware build script if desired. > - Must be a reliable tool that can be counted on. > - Should just work, lots of fiddling to get working not tolerated. > - Price is medium priority, must be good tool to be considered. > > Hobbyist: > - Price is top priority. > - More inconveniences and unreliability tolerated as price get lower. IMO that pretty much sums it up. I'd probably add that a professional development programmer should provide possibilities to integrate into the most commonly used development environments used by professionals in the targeted area. That may be covered by "scriptable" or not, depending on the environments. An example is MPLAB... it doesn't lend itself well for integrating scriptable tools. I once tried to make my make scripts MPLAB-compatible (so that I can run them both from other, "script-friendly", environments and from MPLAB), but that seemed to take a lot of work, so I abandoned it. Who wanted to work with MPLAB had to maintain their own MPLAB projects and keep them in sync with the make files :) I don't know how common use of MPLAB is among professional PIC developers, but it's probably significant. FWIW, it was easier to integrate ICD2 programming into my make scripts using AutoIt3. (ICD2 is almost not a professional development programmer... :) Gerhard -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist