PICkit3 ICD's from China - genuine or not?

[SingedFingers]

I'm currently using this crock of shit to program some PICs:



It does work but as you can imagine this is a big PITA and I'd like some ICSP and ICD love here, particularly as the thing I'm working on at the moment is going to make it into production use (first paid up job - yay)

So the question is: are the cheap PICkit3's you see on eBay the genuine article?

They are £14 including delivery shipped from Jersey apparently (just under the £15 customs limit). If I go to RS the same unit is £46! Big price difference.

Edit: to clarify, I need to program some mid range 16F series devices, nothing fancier. Would a clone PICkit2 do the job?

[Ian.M]

They are definitely *NOT* genuine, they often have poorer spec components in the Vpp boost and variable Vdd supply circuits so cant be counted on to drive as low a /MCLR pullup or isolation resistor as the genuine article, or supply as much Vdd current to the target (which can be a particular issue for PIC24 and PIC32 targets), have no warranty other than the typical EBAY D.O.A buyer protection, but generally work OK with MPLAB as a PICkit 3.  Typically they all have the same serial number which is a PITA if you are developing a multi-PIC project and need multiple PICkit 3 devices connected.

Although it happens less often than it used to, the PICkit 3 has a bit of a reputation for bricking itself.  Its often retrievable by forcing bootloader mode, but if the bootloader is corrupted, the only solution is to reprogram the PIC24 in it with another programmer, or if its genuine, Microchip will send you a free exchange unit.  Buy a clone and the odds are you'll have to buy a second one within the next couple of years,.

[SingedFingers]

Thanks for the info - much appreciated. This is entering slightly more PITA territory than I'm willing to take on I think. I seem to remember this sort of stuff when I last took on a PIC based project in about 1998.

At this point I'm considering scrapping the PIC idea and using an AVR and avr-gcc + avrdude and a cheap USB programmer. Seems to be less friction filled. Plus I can do it on Linux then.

The target doesn't have to do much. It's reading a 3-bit address and 4-bit data bus and a latch pulse that populates 8 (dead - hence the project) HP5082-7000 series displays.

[Ian.M]

Sounds like a good reason to use a PIC.  There are several 8 bit ones in 40 or 44 pin packages that have a parallel slave port, which will latch 8 bits of data under the control of an external strobe signal, and raise an interrupt, so you don't have to worry about bus timings in the system you are attaching it to as long as you can service the latched data before the next strobe pulse.

A PICkit 3 + MPLAB X will not only let you develop under Linux in C or assembler, but will also let you debug (assuming a PIC with debug silicon support or a debug header).

[SingedFingers]

Yep that's what I was hoping for. Basically there was going to be an ISR that gets triggered on the latch pulse, a short settling delay, read the high and low nibbles, and/shift them, LUT (I love the CALL,ADDWF,RETLW tables ) write the looked up digit to a file register and shift all the digits out to a bank of 74HC595's connected to substitute LED displays and then latch them. Figure I can get away with a 16F684 then as I know them pretty well and have some stock. latch pulse is every 50ms which is forever in the scale of things.

Already written most of the code.


I've ordered the genuine PICkit3 from RS. Will see where I get to.

Also ordered a USBasp and a couple of Arduino mini pro's to have a play with and I will compare the two afterwards for dev friction and turnaround as a research exercise. Not using the Arduino toolchain; will try with AVR-gcc and avrdude.

[Ian.M]

That wont get you a hardware latched 8 bit port.  Your ISR will have to read the bus while the data and address are still valid.  The PIC18F4221 is probably the cheapest device with a PSP, and as its a 40 pin device, if you are multiplexing the replacement displays you may not need any 74HC595 shift registers.

OTOH if the strobe pulse is long and slow enough, and there's enough time between them to service them there's no reason not to do it in software as you described.

Incidentally, I should mention that Microchip's toolchains under Linux require an ix86 architecture CPU, so if you are running anything else you are S.O.L.

[SingedFingers]

Latch strobe is long enough for the ISR to read the port. Path of least resistance is used here.

Good point about display multiplexing. I didn't even consider that. That'd save the 595's on the BOM and I can just poke the file register content on the port and keep a pointer to the current digit's file register and increment that on a timer.

Time to refresh myself in interrupt priorities

x86-64 here.

Edit: original board is a 74ls138, a couple of buffers, 8x 5082-7000 series displays and a 7805 (because the damn board sinks 680mA when all segments are lit!). Can save some power with multiplexing as well.

[Ian.M]

PIC16 14 bit core doesn't have interrupt priorities.  Interrupts are simply serviced in the order you put their service code in the ISR.  However, as long as the multiplexing interrupt doesn't block for too long, you should be OK.   If not, well there's PICs with PSP as I suggested or you could add an external 8 bit latch, clocked by the strobe to hold the address and data, + hook the same strobe to the external INT pin so your service routine knows the latch has been updated.

You will need digit drivers - low Vgs threshold MOSFETs are easiest.  You can probably sink enough current to drive the segments direct.  Obviously common anode displays are preferred as typically PICs can sink more than they can source.

[SingedFingers]

Thanks for the tips. Much appreciated. Will go through and evaluate these tonight

[22swg]

Can i suggest you put a ferrite core on the usb cable ( if not one provided ) also , if running from  laptop, go via a powered usb hub or better use external power.   

[SingedFingers]

I'm going via an Olimex USB-ISO connected to a bench supply. I've killed too many USB ports in my time and I'm not risking the ones on my nice new HP Z620

[lem_ix]

No experience with the Chinese Pickit3 but many of my friends have Pk2 clones from aliexpress and they work fine. Maybe you got a Pk2 clone which isn't supported in MP lab ? Try that separate programming app? Not much of a microchip guy

[westfw]

I'm considering scrapping the PIC idea and using an AVR and avr-gcc + avrdude and a cheap USB programmer.

Don't most PICs these days come from the factory with low voltage programming enabled?  You might get away without ever needing "quality components in the Vpp boost power supply."

In any case, the cheap USB programmers for AVR are no more genuine than the the cheap PICkit clones, and are flat-out incapable of supporting the high-voltage programming modes that you might occasionally need for an AVR (OTOH, many of the official AVR programmers don't support HV programming modes, either.)\

[Ian.M]

The better quality clones that go to the trouble to copy the PICkit 3 case usually don't have problems with ordinary programming.  However if you have an application circuit that loads /MCLR by more than the recommended 5K minimum pullup or isolation resistor, that all of the current and previous generations of Microchip programmer were rated to drive, or that heavily loads PGC or PGD or is pushing the limit of the PICkit 3's ability to supply target Vdd current, the genuine article is preferable.  Also, when it just doesn't work, its a big help talking to support if you have a genuine Microchip programmer and can reproduce the problem on a genuine Microchip demo board as they often choose to 'shotgun' suspected hardware faults by sending you a replacement programmer, to the point that if anyone asks how to repair a PICkit 3, the Microchip forum regulars always say something along the lines of "Here's how you do it, but talk to support first, you wont regret it!"

[SingedFingers]

Well the USBasp and AVR arrived yesterday (no sign of the PICkit yet). Managed to rig the whole shebang up and get it working with AVR-gcc. All sorts of timing problems leading to device recognition. Then I fucked up the fuse configuration and bricked the AVR. The development experience is, how shall we say it, slightly horrible compared to my experience with PICs. Test code was as follows, and no I didn't bother with a Makefile for the experiment - unnecessary complexity for a quick experiment:

Code: [Select]

#!/usr/bin/env bash
avr-gcc -mmcu=atmega168 -Os -D__AVR_ATmega168__ -c blink.c
avr-gcc -mmcu=atmega168 -o blink.elf blink.o
avr-objcopy -j .text -j .data -O ihex blink.elf blink.hex
avrdude -C avrdude.conf -B 8 -c usbasp -p m168p -F -e -U flash:w:blink.hex

Code was simply:

Code: [Select]

#define F_CPU 16000000UL

#include <avr/io.h>
#include <util/delay.h>

int main(void) {
  for (;;) {
    PORTB = 0xFF;
    _delay_ms(500);
    PORTB = 0x00;
    _delay_ms(500);
  }
}

That little experiment above however cost just under £7 for the USBasp and AVR which is respectably low. Sourced from bitsbox.co.uk.

PICkit3 is scheduled to arrive today. Doing this with MPlab X

[HwAoRrDk]

Are you sure your AVR is bricked? Or did you come to that conclusion because your test code didn't appear to do anything?

All you're doing there is toggling the internal pull-ups. You forgot to first set the DDRB register to make the Port B pins outputs.

[ebclr]

They are fake,

But they work without any problem, advantage to buy the expensive original is minimal if not null, But even the fakes ones have the bads and the goods, don't buy the cheapest available take a look on details, like case accessories etc

Mine are those ones

https://world.taobao.com/item/20912275839.htm?spm=a312a.7700714.0.0.kECzX2#detail

https://world.taobao.com/item/40461241705.htm?spm=a312a.7700714.0.0.oqRe5f#detail

[DimitriP]

advantage to buy the expensive original is minimal if not null,

When I needed one, being able to order one from digikey and have it in three days , skipping all the "research" and the finger crossing was worth the extra few bucks 

[Ian.M]

The clones are great for hobbyists,  and maybe if you need to send out preloaded PTG firmware to customers, but any salaried developer or full-time contractor will prefer the genuine article for bench use simply because the time saved when there is an issue is more valuable than the difference in price.

[ebclr]

Why not Mouser, better customer service, If you want to pay high, buy on the right place

[DimitriP]

Why not Mouser, better customer service, If you want to pay high, buy on the right place

The price difference is less than  $3, and I already had an order going on digikey so it made sense not save 3 dollars on the pic-kit andspend 4-8 in additional shipping instead. There is a method to  my madness .

but any salaried developer or full-time contractor will prefer the genuine article for bench use simply because the time saved when there is an issue is more valuable than the difference in price

A hobbyist's time by definition being "spare" time, is even more valuable ...

[KL27x]

So the question is: are the cheap PICkit3's you see on eBay the genuine article?

I have used 3 of them, which I think covers most of them except the olimex version. The only one that is dodgy is the Sure Electronics one with the black case. The other clones have been just as good... except when in free-standing programming mode; here, my genuine PICKIT3 freezes up occasionally, requiring a reboot. One of my clones works better, rarely if ever hanging up. One hangs up more frequently. There are some bugs in this device, genuine or not.

[SingedFingers]

Are you sure your AVR is bricked? Or did you come to that conclusion because your test code didn't appear to do anything?

All you're doing there is toggling the internal pull-ups. You forgot to first set the DDRB register to make the Port B pins outputs.

It did work like that and now does work. Shitty breadboarding on my part was the cause.

Setring DDRB to outputs made no difference either way so I removed that LOC. Assumed default was outputs (I haven't read the data sheet TBH).

[HwAoRrDk]

That's strange, because the default is inputs.

[SingedFingers]

Indeed that is rather odd. I'm going to check the binary it kicks out tomorrow and see if this is being done implicitly somewhere.