Crazy idea, multiplexing a pickit 3 programming lines to program more mcus?

[free_electron]

those are called gang programmers.
been around for ages. Data-i/o and the likes ...

[NorthGuy]

On many PICs, you don't need any feedback to program. So, you can simply connect all the PGC, PGD and MCLR lines in parallel, and, given enough drive strength you can program as many as you wish. However, this won't give you any feedback, so you won't know if it programmed Ok. Of course, you will need your own software because most stock programmers will want to receive the chip id before programming.

That's another advantage of using your own bootloader - you can arrange the protocol such that the programming time is guaranteed by enough dummy bytes in the serial stream, so you don't need any feedback from the device.
e.g. let's say your programming commands all start with 0xc5, and any other byte is ignored til it sees 0xc5, you send
<0xc5> <stuff to program one page>  <enough 0xff bytes to exceed the maximum row program time at your baudrate>
Use 0xff as filler as it's the easiest value for the UART to re-sync to - during programming, the UART will be being ignored so will overrun, and needs reliably re-syncing.

Still, you will need a way to find out if everything programmed Ok. I don't think the current ICSP protocols are flawed and need replacing. The problem is that once in a while you do come across a PIC which just doesn't want to be programmed no matter what.

[Ian.M]

Since the O.P. needs the PICs individually serialised, a simple (dumb) gang programmer is not useful.  However, if the objective is to reduce programming time without ordering preprogrammed chips and the PICs have a lot of FLASH, programming serialised bootloaders by ICSP, then using the bootloader to gang-load the rest of the firmware to all the PICs simultaneously, using the same PIC pins, but switching them to a USB <=>  logic level serial module might be worth considering.

[mikeselectricstuff]

On many PICs, you don't need any feedback to program. So, you can simply connect all the PGC, PGD and MCLR lines in parallel, and, given enough drive strength you can program as many as you wish. However, this won't give you any feedback, so you won't know if it programmed Ok. Of course, you will need your own software because most stock programmers will want to receive the chip id before programming.

That's another advantage of using your own bootloader - you can arrange the protocol such that the programming time is guaranteed by enough dummy bytes in the serial stream, so you don't need any feedback from the device.
e.g. let's say your programming commands all start with 0xc5, and any other byte is ignored til it sees 0xc5, you send
<0xc5> <stuff to program one page>  <enough 0xff bytes to exceed the maximum row program time at your baudrate>
Use 0xff as filler as it's the easiest value for the UART to re-sync to - during programming, the UART will be being ignored so will overrun, and needs reliably re-syncing.

Still, you will need a way to find out if everything programmed Ok. I don't think the current ICSP protocols are flawed and need replacing.

Not flawed, but far from optimal in some cases

The problem is that once in a while you do come across a PIC which just doesn't want to be programmed no matter what.

After programming you'll be testing the product anyway, so any failures will become apparent then.
If you have an onboard LED, you could also use this to indicate successful programming. 

[NorthGuy]

Say, theoretically, if this machine were available, and if it worked as advertised... would there be any market for this? There are so many other ways to go about it, which have been discussed in this thread. Would anyone be interested in having their own chip flashing factory? Why wouldn't they, right?

I've seen such machines advertised for around $5K. Don't seem to find them now.

At any rate, you would probably want to do some sort of QA on your final board. If you do programming and QA together, the programming may be of less overhead than when you pre-program before assembly.

[KL27x]

After programming you'll be testing the product anyway

You'll be testing it for a variety of faults. If you could exclude corrupted firmware and just focus on hardware faults, it may simplify the testing procedure. A failed flash could be just a single corrupted byte. And who knows under what conditions that would be elicited? Maybe your customer will be the one to find it. I suppose if you have done it enough times with similar device and firmwares without any problem, you will be confident. For the first time, I don't know how I would sleep at night.

I've seen such machines advertised for around $5K. Don't seem to find them now.

Do you suppose it's because no one has a legitimate use for a machine like this? (Cuz of JTAG and programming services?) Or because it is too complicated and expensive? I still believe there is some potential benefit for this approach. If the cost were 1/10th or 1/20th, something one could afford for even personal use?

[alm]

If the parts have a decent JTAG programming implementation (seem to recall JTAG on the 16-bit PICs was only partly functional), then putting all devices on a panel in a JTAG chain could be an easy way to do this. Not sure what the instruction register width on PIC parts would be, probably zero on 16-bit PICs .

[NorthGuy]

I've seen such machines advertised for around $5K. Don't seem to find them now.

Do you suppose it's because no one has a legitimate use for a machine like this? (Cuz of JTAG and programming services?) Or because it is too complicated and expensive? I still believe there is some potential benefit for this approach. If the cost were 1/10th or 1/20th, something one could afford for even personal use?

I'm sure they are still alive. For example: http://www.dataio.com/Solutions/PSV3000

This one is probably too expensive. I've seen better priced models.

[mikeselectricstuff]

After programming you'll be testing the product anyway

You'll be testing it for a variety of faults. If you could exclude corrupted firmware and just focus on hardware faults, it may simplify the testing procedure. A failed flash could be just a single corrupted byte. And who knows under what conditions that would be elicited? Maybe your customer will be the one to find it. I suppose if you have done it enough times with similar device and firmwares without any problem, you will be confident. For the first time, I don't know how I would sleep at night.

That's what Checksums/CRCs are for.
 

[mikeselectricstuff]

I've seen such machines advertised for around $5K. Don't seem to find them now.

Do you suppose it's because no one has a legitimate use for a machine like this? (Cuz of JTAG and programming services?) Or because it is too complicated and expensive? I still believe there is some potential benefit for this approach. If the cost were 1/10th or 1/20th, something one could afford for even personal use?

I'm sure they are still alive. For example: http://www.dataio.com/Solutions/PSV3000

This one is probably too expensive. I've seen better priced models.

BP Microsystems are the other big players in auto production programming
http://www.bpmmicro.com/programmers/

[KL27x]

That's what Checksums/CRCs are for.

AFAIK, a bad checksum means for sure there was a transmission error. But a matching checksum cannot rule out error.

But besides this point, how do you do checksum in gang programming setup? If you are going to individually connect  each board to a programmer at some point, why not flash it, then? With full verification? And why not put the bootloader on there at this point, too, yourself?

Is this strategy solely for saving the time of flashing, in itself? For chips which will take on order of minute rather than seconds? This seems to be the case for these expensive chip flashing machines, too... Spend as much time loading the machine as doing the flashing. I am wondering about saving time of making connection to each invidual board by flashing the chips (easier) before they get on the board. The way Microchip factory does it, essentially. But on a smaller scale. Like as in you stick a tube of chips in a machine, press a button, and when you come back, they are all flashed with full verification. And back in factory packaging. Never touched by human hands. (I promise Microchip won't charge pennies per to flash a stack of your boards. The chips are standard size and shape and are handled by machine.)

If someone can make this machine affordable and make it available to purchase, would anyone be interested?

*edit, sorry. Looked closer at those links. And yeah, they handle the chips via CNC. I'm wondering if someone could sell a machine for smaller volumes which sat on your bench, not in the third factory. And which was hundreds rather than thousands?

[mikeselectricstuff]

That's what Checksums/CRCs are for.

AFAIK, a bad checksum means for sure there was a transmission error. But a matching checksum cannot rule out error.

I think you misunderstand. This was in answer to how you can be sure, at testing time, that the code was programmed correctly, particularly in a 1-way programming situation.
Either the bootloader, or the code itself, checks that the code image satisfies some checksum or CRC criterion that guarantees the image is valid, and either doesn't start or gives an error indication, which means it fails test.
e.g. it is common for a bootloader to do a check on the program code before jumping into it, to prevent erroneous code being run, and ensure that it can be reprogrammed.

[KL27x]

You are right, I didn't get it. Lightbulb finally turned on. Bootloader, checksum, LED signal. Thanks for explaining it.