2
\$\begingroup\$

I want to program some PIC micro simultaneously using single same port. There is no problem in programming but when process is finished, feedback command that say "done! its programmed" cause conflict in receiver. In the other words, I want to able check each micro separately and this is my challenge.

with diodes I can separate send/receive path and check that finish programming command. but I don't know what is the type and value of this feedback command.

can you help me in this case or give better suggestion? Thank you all,

\$\endgroup\$
  • \$\begingroup\$ There is no structural reason that you cannot gang program the devices and then selectively verify or complete the operation. However you will have to write the code and make the selection hardware yourself as this is not consumer stuff. If you research production GANG programmers you may find OTS systems that could work for you but they will be more costly than @st2000's solution below \$\endgroup\$ – KalleMP Apr 29 '17 at 14:15
3
\$\begingroup\$

Tying multiple PICs together to program them at the same time is not a good idea.

Programming is not totally a one-way process. Programmers may try to read from the PIC for several reasons:

  1. To determine what PIC is out there, or verify that the stated PIC is out there. By default, all my programmers go thru a surprisingly complicated process to try to determine what PIC is connected. Microchip's POD (Programming Obfuscation Division) has been busy creating different and incompatible ways to communicate with different PICs during programming. There isn't even a single way to enter programming mode, let alone read the chip ID. Even worse, the only means to enter programming mode of some PICs would fry others.

    The net result is that the programmer probably does several back and forth attempts at communication when first starting the programming operation.

    Even when the exact target PIC is specified externally, like with a command line argument, my programmers at least still attempt to verify that particular PIC model is connected.

  2. To know when some part of a programming operation has completed. Some programming algorithms require polling the chip to know when a erase or write has completed.

  3. To verify the data after programming. Obviously this needs to be unique per device.

However, that doesn't mean you can't program multiple PICs a the same time, only that a little more of the programming process needs to be replicated per PIC. Basically, you need to replicate at least the low level hardware interface per PIC.

The simplest way to do that is to use multiple programmers. Programmers are a one-time cost. If you are doing such high volume that programming multiple PICs in parallel is important, then the cost of multiple programmers should be minor.

For example, if you are using one of the newer PICs that can be programmed completely from a 3.3 V interface only, then you can use my LProg PIC programmer. At $18 each for five (Apr 2017), a bunch of these and a USB hub are cheaper than most gang programmers. That gives you a setup that works in-circuit, which gang programmers generally don't.

\$\endgroup\$
  • \$\begingroup\$ FYI: At the time of this writing (Apr 29 '17 at 10:07 CDT), the LProg website (embedinc.com/products/lprog) redirects to Firefox's "Reported Unwanted Software Page!", which has the error message: "This web page at www.embedinc.com has been reported to contain unwanted software and has been blocked based on your security preferences." The equivalent of a "Learn more" button sends me here: support.mozilla.org/en-US/kb/… Have you been hacked? \$\endgroup\$ – AaronD Apr 29 '17 at 15:13
  • \$\begingroup\$ @Aaron: I'm aware of that. First, there is not nor has there ever been malware on our site. A few years back something in one of our low level libraries apparently matched a signature in some malware. Unfortunately, trying to explain to the virus scanner companies that something is a false positive is like talking to a wall. I've sent test cases, and I've filled out the form with Google to "rescan" the site, explaining what is going on. "We don't care, we don't have to, we're Google." Maybe someday they'll to that do someone big enough to sue them for defamation. \$\endgroup\$ – Olin Lathrop Apr 29 '17 at 16:11
  • \$\begingroup\$ Thank you for your answer. I have 30 PIC ICs that they are same in part and program. That's why I have no choice but to simultaneous Programming. In this case, for saving Time&Cost I have to use something like multiple programming. Now, checking the process is a big problem and I'm looking for solution. \$\endgroup\$ – Saeed Vali Apr 30 '17 at 8:16
  • \$\begingroup\$ Imagine, I want to program a lot of the same PIC ICs with a similar program. Now, there is no problem in programming In theory, is it correct? if answer is yes, how to check all ICs for complete programming? \$\endgroup\$ – Saeed Vali Apr 30 '17 at 8:26
2
\$\begingroup\$

It might be the best approach to prevent field failures is to verify the programming after programming each processor. For this you will need to program each processor individually. To improve production throughput consider using several less expensive PIC programmers. The PICKIT3 is normally less that 50USD and can be configured to autonomously program PIC processors with out being attached to a computer. In addition, the PICKIT3 is small enough to be easily integrated into an ICT fixture. Reducing in circuit testing and programming to a single operation.

The autonomous program feature of the PICKIT3 is call Programmer To Go. The program to be burned into each PIC IC is pre-loaded into the PICKIT3 module when setting up the PICKIT3 for autonomous programming. As mentioned in this Microchip Programmer-To-Go video, there is no debugging when the PICKIT3 is configured as an autonomous programmer. In the video, the PICKIT3 (powered through a USB power supply) is connected to the target and the program button on the PICKIT3 is pressed. In seconds the PICKIT3 STATUS light turns green indicating the programming has finished. The entire process appears to take less than 10 seconds.

\$\endgroup\$
  • \$\begingroup\$ I have 30 PIC ICs that they are same in part and program. program each processor individually is not efficient in time. for this case, what is your solution or suggestion? Thank you. \$\endgroup\$ – Saeed Vali Apr 30 '17 at 8:19
  • \$\begingroup\$ I had assumed this was a production run of 1000s of units. Not a one time batch of 30. Still, I suspect programming 30 PIC ICs using a PICKIT 3 in its self programming mode will take less total time than putting together a fixture, let alone figure out the software, to program the same 30 PIC ICs at the same time. I suspect it will take less than 10 seconds to attache the PICKIT3 to the PIC IC, press the PICKIT3 program button & wait for the "successful programming LED" to light up. 30 x 10 seconds = 5 minutes. I have added links in my answer regarding this feature. \$\endgroup\$ – st2000 Apr 30 '17 at 14:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.