Do Microchip PICKIT3 and Ebay PICKIT3 Clones Work Identical?

[SuzyC]

I want to program Microchip PIC chips, and I need something like a PICKIT3 to allow me to program new chip models.
I see on ebay that the PICKIT3 clone offerings are up to 6x(oops..maybe 1/2 as much) cheaper than the genuine Microchip device.

I want to use HV mode on the Vpp pin for programming the PICS and I also most always want to program using the PICKIT3 directly from a DOS IDE compiler generated INTEL HEX File.

My question is: Is there any HV programming mode or other limitations in the ability to program all PIC device types using a clone PICKIT3?

Is it that the programming instructions for each chip must be downloaded from a Microhip IDE program to the PICKIT3 or that the firmware that comes with PICKIT3 contains a program with this programming info?

If there is PICKIT3 firmware, is it then possible to just download the latest software/firmware/Chip Programming Procedure info for the PICKIT3 that will work on a clone PICKIT3 from Microchip?

[oPossum]

I see on ebay that the PICKIT3 clone offerings are up to 6x cheaper than the genuine Microchip device.

Where do you see them for $8. The real thing is $48.

I want to use HV mode on the Vpp pin for programming the PICS and I also most always want to program using the PICKIT3 directly from a DOS IDE compiler generated INTEL HEX File.

From DOS??? Can't do that with PICKit. Windows, OS X or Linux only.

[chibiace]

mplabx comes with a standalone program for uploading hex files

[SuzyC]

Thanks to all, actually some of the clones are mostly close to half the price..I saw the higher price looking at a development board price that included a PICKIT 3 from Newark.


The question remains..do PICKIT 3 clones offer the same functionality and ability to program yet to be released newer chips?

Is the chip programming info always part of the MPLABX package and independent of the PICKIT 3 firmware?

Does the MPLABX software allow me to use hex files generated by a Hi-Tech compiler or is it that the hex files must have a different format that only results from compiling with MPLABX?

[oPossum]

You can use Microchip's IPE (Integrated Programming Environment) software to program hex files from any compiler or assembler. The hex format used by PICs has be documented and standardized for a long time.

If you buy a cheap clone from china you get whatever they send you. Get the real thing for $20 more and avoid all the possible problems with a clone.

[neslekkim]

I have this http://www.ebay.com/itm/350637699036 and it works fine, but still bought this https://www.sparkfun.com/products/9973 soon after for some reason.

I would ask TopLoser on the forum here if he have any, he have sold some from time to time fairly cheap.

[22swg]

PK3 clones seem to be very similar , but there would always be a question if some bug seemed unbugable ... MC did an offer on a Debug express  PIC18 +  PK3  dev bd... unfortunatly not now ! also suggest check here
http://www.electro-tech-online.com/threads/pickit-3-for-18-new.142449/

[kaz911]

don't forget that Microchip has lifetime warranty (slightly limited against idiot operators) - on many of their debug tools. I had a few broken PIC tools - I sent them back - and got them replaced (bought 2nd hand on ebay)

[Mechatrommer]

and I also most always want to program using the PICKIT3 directly from a DOS IDE compiler generated INTEL HEX File.

i dont believe what i'm hearing. is it multitasking hatred or a nostalgia i'm not sure.

as for the clone advice. i dont know. the answer... maybe yes maybe not to all the questions. which one is the clone out of thousands? we dont know. simple general rule is... if you buy clone and it breaks next month (even though it can do all of the original functionalities) dont come and mourn to us, go to the seller and shout however you like... similarly if you buy original and it breaks, goto microchip... however, you are welcome to review either of them here so others get warned. cheers.

otoh i have pickit2 that just seemed to break last night, had it for several years now. several usb unplug-plug windows restart, change usb ports did not help, opening and brush cleaning the pcb/components did not help, checking all seems ok. so thinking without going further making unecessary damage, have faith pushing the red button and plug. it resetted itself and asked for the OS firmware, uploaded and its working like new again, thank you.

[neslekkim]

otoh i have pickit2 that just seemed to break last night, had it for several years now. several usb unplug-plug windows restart, change usb ports did not help, opening and brush cleaning the pcb/components did not help, checking all seems ok. so thinking without going further making unecessary damage, have faith pushing the red button and plug. it resetted itself and asked for the OS firmware, uploaded and its working like new again, thank you.

For those who have pickit2 etc: http://www.microchip.com/pagehandler/en-us/promo/legacymigration/

Edit: Shit, expired few days ago..

[rolycat]

For those who have pickit2 etc: http://www.microchip.com/pagehandler/en-us/promo/legacymigration/

Edit: Shit, expired few days ago..

Never mind - you would have had to return your pickit2. I would recommend keeping it even if you buy a pickit3; it has a number of useful features not offered by the newer device.

[ivan747]

You can use Microchip's IPE (Integrated Programming Environment) software to program hex files from any compiler or assembler. The hex format used by PICs has be documented and standardized for a long time.

If you buy a cheap clone from china you get whatever they send you. Get the real thing for $20 more and avoid all the possible problems with a clone.

My 2 cents: there's nothing worse than debugging the debugger.

The price difference will give you peace of mind with the tool every time something goes wrong (and when programming micro controllers, that's often, see what happened to mechatrommer). And it's peace of mind that will last for years.

[Howardlong]

My 2 cents: there's nothing worse than debugging the debugger.

Agreed, there are enough "features" to fight with on the real thing without having to question the compatibiltiy of a no name.

[diyaudio]

I want to program Microchip PIC chips, and I need something like a PICKIT3 to allow me to program new chip models.
I see on ebay that the PICKIT3 clone offerings are up to 6x(oops..maybe 1/2 as much) cheaper than the genuine Microchip device.

I want to use HV mode on the Vpp pin for programming the PICS and I also most always want to program using the PICKIT3 directly from a DOS IDE compiler generated INTEL HEX File.

My question is: Is there any HV programming mode or other limitations in the ability to program all PIC device types using a clone PICKIT3?

Is it that the programming instructions for each chip must be downloaded from a Microhip IDE program to the PICKIT3 or that the firmware that comes with PICKIT3 contains a program with this programming info?




If there is PICKIT3 firmware, is it then possible to just download the latest software/firmware/Chip Programming Procedure info for the PICKIT3 that will work on a clone PICKIT3 from Microchip?

Original or Clone PICKIT3 (Which I own) its dog slow, and to add to the frustration never seem to hit breakpoints during debugging. WTF?, im thinking of investing in a ICD3.


 

[SuzyC]

Thanks to all, I see now that saving a penny could cost me a dollar.

Not all the code I write works the first time..some of it does work the way I intended, most things take a little to a lot of debugging. And sometimes I find that my code works fine but my code is just not able to accomplish my pgm's goal. So, I need to debug my pgm flow.

I have never used a PICKIT3 (or any other debugger hardware sold by MCU producers), I have instead relied on hardware flag bits on MCU pins that trigger and display 1 to 4 output pins at the same time, with these carefully placed program set software flags displayed on my oscilloscope  I can see the points in my programs I am interested in while watching the MCU perform a task. At the same time the MCU periodically sends a stream of data out to the PC using a RS232 TX pin to show a long list or arrays of var values.

So I debug using these var values which are continually updated and displayed on my PC with my own program (and then I am able go back to look at data saved in files on the PC for analysis.) My program then allows me to page through stored data after a test session.
I can see the realtime behavior by watching the bit flags on my 4-chan storage oscilloscope( and so the storage scope can also allow me to playback and review many seconds to hours of  program operation). I transmit a timestamp at the start of each streamed packet so I can relate the flags stored on the oscilloscope display to the streamed data saved.

In this way the flags show program status and the data exposes var values.

Then it up to me to examine my program listing and compare my observation of pgm operation against this data to see expected and unexpected behavior. Finally, to fix the bugs I have to then look at my code and pseudo-code flow charts to try to figure out what I've got right or why what I've got is sometimes so amazingly wrong or where next to place flags to clarify how to solve the problem.

How is using a PICKIT3 any better than my method to debug with?

[mazurov]

How is using a PICKIT3 any better than my method to debug with?

I use both. Debugger allows stepping through code and set traps inside exception handlers. Have you ever tried to catch memory alignment trap with an oscilloscope (or a terminal)? Speaking of terminals, I suggest learning about DMCI - much better way of outputting arrays and vars.

[SuzyC]

What I am saying is that my primitive methods are able to be used with any MCU, independent of having an emulator or ICE or other MCU development board specific hardware, just requires use of a RS-232 TX pin and maybe 1 to 5 other pins on the MCU to identify pgm events and to store data that can be graphed or analyzed.

DMCI may not be so useful as difficult and time-wasteful to be continually tuned and set up to watch real world pgm operation when there are  many physical forces acting in a complicated manner and also changing in a random way. It is not so easy then to use something that difficult to emulate using debugging software, it could be that the result is too myopic in its scope of the entire dynamic to see overall pgm operation, to see more clearly that which is challenging a pgm's strategy to accomplish some control goal in a realtime situation.

My intention is to not to question other debugging tools while only praising my own methods as the better alternative.

I am not trying to say my methods lead to the better or the worse, everyone has those tools which they have become best accustomed to use to solve debug problems. I also know there is more than one way to skin a cat.

I am just wondering why anyone would want to attempt to use the a PICKIT3 for this purpose.

[BradC]

How is using a PICKIT3 any better than my method to debug with?

I do what you do. A LED and a CRO are my preferred tools, but having the ICD3 (because it's a _lot_ faster than the PICKIT) sometimes I also like the ability to set a breakpoint and be able to single step. You don't need it, but once you have it you will find uses for it.

I started with the old Picstart back in the early 90's, from there to the Picstart+ and then to the PICKIT2. The ICD3 was just the natural progression. Each iteration just gets faster and more versatile. I don't really use the debugging features of the ICD, but sometimes the ability to break and step saves a few instrumentation/compile/test cycles. Frankly if MPLABX supported my PICKIT2 properly I'd not have bought the ICD3, but it doesn't so I did.

Generally first thing I bring up on a new platform is a serial monitor and go debugging from there, but the LED and the CRO always get a good workout. I've only got 2 channels and a shallow sample depth, but it's generally enough.

[SuzyC]

There is no need to have an expensive emulator/IDE/Simulator etc to have the ability to single step. A few lines of code and a start/stop switch on a pin can easily accomplish this with your own tiny custom "dbg();" routine  that can be inserted into the code at any number of pgm points or inside an exception handler or software var value trap. One can even use one of the MCU's timers to slow walk through troubled code when an exception or event is triggered, and so it can slow down the pgm code and output values on each call.

[Mechatrommer]

A few lines of code and a start/stop switch on a pin can easily accomplish this with your own tiny custom "dbg();" routine  that can be inserted into the code at any number of pgm points or inside an exception handler or software var value trap.

now you start making sense. i use your method too but the limitation is we cant exactly pinpoint at which line the error code is, we can narrow it down to some smaller area but cant to exactly one line of code except some >1 iterations of debug-compile-upload process. i'm not sure if the debug ide or proprietary hardware facility like jtag can do real single stepping+regs/vars/memories view, not simulated single stepping in windows ide. i think they can but i have no time to learn. my app is simple, your method is workable.

edit: debugging embedded is quite a different arena than pc sofware development where you have realtime input data that you cant simply make a perfect simulation in sw (called stimuli in avr studio) thats why i keep hesitant to believe jtag or other proper way may work based on real life input...

[BradC]

There is no need to have an expensive emulator/IDE/Simulator etc to have the ability to single step. A few lines of code and a start/stop switch on a pin can easily accomplish this with your own tiny custom "dbg();" routine  that can be inserted into the code at any number of pgm points or inside an exception handler or software var value trap.

True, except I can modify my breakpoint without modifying the code or re-downloading the target.

I'm not trying to convince you of its worth to *you*, only letting you know where it is useful to *me*.

[SuzyC]

Thanks Mechatrommer and Bradc, please know I appreciate that you've given me some insight on the how and why your SW/HW methods have helped to solve your debug problems.

One thing that I've learned is I can easily waste hours to days playing debug when the most productive thing that I could really do is realize that I don't quite understand the dynamics of my pgm, or the problem to be solved, or how the MCU is working with the task at hand.

There  is a pgming problem that needs to be solved, and to do this best requires me to step back away from the tests and debug break points and look at my code and data and flow charts and just think about the how and what I am doing with my code.

The goal is to discover what is correct and correct or improve on what is wrong. I welcome any  SW/HW approach that is efficient to help me understand what is really going on, to find out what needs to be changed or fixed or improved to get things to work. A complicated IDE or debugging tool can sometimes only distract me from thinking about the big picture and so sometimes helps to make a time-wasting situation worse.

More often than not, I can easily fall in a trap of not thinking about how my pgm is trying to work, and instead sit hypnotized at the bench diddling around debugging what turns out to be an inappropriate and quite harebrained software strategy.

Sometimes I have to sleep on it, or take a long or short walk. Most often, with just a little debugging, I realize that by examining just a few results of my debugging, it is that my pgm is shouting at me to notice an obvious point that I am failing to see.

[22swg]

I was skeptical with PK3 debug before I began to use more advanced PIC's,   With MPLABX it's ability to report register / memory / pin contents at a breakpoint , then to resume running is essential, no led or serial output  will do that without some code timing / pin implications. It also helps in understanding the mcu workings in more or less real time.     

[bson]

I use a combination of techniques.  A 4x20 character LCD with an I2C backpack for displaying values like ADC readings, capture timing, decoded IR commands, event counters, calculated values, etc.  Makes things like integer over/underflow very obvious and makes it easy to exercise the full range of inputs and outputs.  A scope to check outputs.  An interrupt-driven IR decoder and a Vishay 38kHz IR (38238) receiver provides all the buttons I need using only one input pin and a timer.  Very breadboard friendly.  Assert()s provide early failure and I make them simply stop with a message on the LCD so I can attach a debugger and see why it stopped.  Even if they get compiled out in production builds they still provide excellent documentation about assumptions and correctness.  At other times I explicitly add code to look for failure conditions (invariant checks) and set breakpoints in the error handling.  Then once a design is functionally good I rebuild with __DEBUG and all instrumentation disabled and make sure it still works, then figure out the lowest clock it can work on, then measure power consumption (uA/nA for PICs) and implement idle/sleep functionality to reduce power consumption.  Finally, I see what the smallest flash and RAM is that I can shoehorn it into and what I can do to reduce the footprint without impacting power consumption.

[BradC]

Sometimes I have to sleep on it, or take a long or short walk. Most often, with just a little debugging, I realize that by examining just a few results of my debugging, it is that my pgm is shouting at me to notice an obvious point that I am failing to see.

This is really "old school", but when I get backed into a corner with a seemingly intractable bug I resort to a comfy chair, hard copy printout of the offending source, pack of highlighters and glass of scotch.

[22swg]

An interrupt-driven IR decoder and a Vishay 38kHz IR (38238) receiver provides all the buttons I need using only one input pin and a timer. 

Bson.. seems an ideal solution , care to share some code pls....

[bson]

Bson.. seems an ideal solution , care to share some code pls....

Sure!  I've attached a decoder for the Adafruit $5 remote:  http://www.adafruit.com/products/389
A suitable receiver is the Vishay TOPS38238, although I think most 38kHz active-low receivers will work.

[22swg]

Bson  , Thanks for file.

[BloodyCactus]

as to the original question, I believe the pickit3 schematic is published by microchip but not whats in the fpga's inside it. so, yes chinese cloners can make clone pickit3, I dont know what happens regards to the firmware. and the firmware will try and update each time you debug or program with mplabx (maybe its a switch to turn it off I dont know).

[exapod]

as to the original question, I believe the pickit3 schematic is published by microchip but not whats in the fpga's inside it. so, yes chinese cloners can make clone pickit3, I dont know what happens regards to the firmware. and the firmware will try and update each time you debug or program with mplabx (maybe its a switch to turn it off I dont know).

The pickit3 uses a PIC24F and the .hex file is available from microchip in case you brick the pickit. The problem of buying even an exact clone of the pickit is lack of support and the quality. Just get the original.

[ale500]

I wanted to start with PIC32s some months ago and asked myself the same question. Reading endless discussions on forums like this, the consensus seems to be buy the original instead of a clone. I didn't buy the original but I bought OLIMEX's clone (through amazon, I used a 10€ coupon I got a few months back, so it was 26 € shipped). It works well. A china clone would cost me also 25 €. Like someone said a couple posts back, if you have to debug your debugger... you have the wrong debugger. All this still do not answer your question, I know. I also didn't find a definitive answer.
If you are serious about the PIC32, you may consider the ICD3. Why do I say that, debugging with the PICKIT3 is slow, dog slow, I assume that it is better with the ICD3. The PICKIT3 doesn't allow you to change/add/delete a breakpoint when you are debugging. You set/clear bkpts, compile, load and debug.
Another point, a bit more worrisome is the lack of optimization options on the compiler without paying Microchip for GCC!. I tried compiling MC's toolchain but it aborts on different places depending on the host. There are other precompiled toolchains available but do not play well with MPLABX...  On this regard, the ARMs a bit better. No toolchain problems or programmer (for Cortex at least), but also no narrow 28 PIN version either .

[Howardlong]

The PICKIT3 doesn't allow you to change/add/delete a breakpoint when you are debugging. You set/clear bkpts, compile, load and debug.

My kosher PICkit 3 does allow breakpoints to be amended while debugging.

Another point, a bit more worrisome is the lack of optimization options on the compiler without paying Microchip for GCC!. I tried compiling MC's toolchain but it aborts on different places depending on the host. There are other precompiled toolchains available but do not play well with MPLABX...  On this regard, the ARMs a bit better. No toolchain problems or programmer (for Cortex at least), but also no narrow 28 PIN version either .

Agreed, Microchip really need to get back with the program on this, I do stuff on the full range of devices and now have a costly annual charge totalling about $600 (if I wish to use the latest devices) which I never used to have. I've had the old C18 and C30 compilers since 2005, and C32 since 2007 when it was a one off lifetime charge. Then XC8/16/32 was introduced, and C18/C30/C32 users were grandfathered in. Very generous you might think. Until last year when I updated one of the compilers and had a rude surprise that I had to shell out for an annual maintenance charge known as "HPA", or High Priority Access, $200 per compiler, so $600 total per annum for the PRO versions. If you're just coming into the game, each compiler is $1000, so $3000 total just to buy in. If you want XC32++, that's $1500, and luckily I don't have need for that.

As a comparison, the toolchains from TI and NXP are priced at ~$500 for fully unlocked versions of their Code Composer Studio and LPCXpresso respective toolchains but there is no hefty up front buy-in. The TI license is an annual subscription, but I am not sure about the NXP one. However you can do an awful lot with the free versions, there is no compiler crippling. For NXP, you are restricted to 256KB code size (that's a lot in an embedded system) and with TI you're restricted on the debuggers you can use.

[BloodyCactus]

good thing gcc is open source, and microchip follow the gpl license and make it available, so enabling all the optimisations is easy!

[ivan747]

good thing gcc is open source, and microchip follow the gpl license and make it available, so enabling all the optimisations is easy!

I didn't know Microchip had a GCC-based compiler. I thought XC8 and the others were fully proprietary. And, if there are open source variants, why doesn't anybody start a parallel project for it, just like Red Hat Enterprise Linux and Centos or SUSE and openSUSE?

[rolycat]

good thing gcc is open source, and microchip follow the gpl license and make it available, so enabling all the optimisations is easy!

I didn't know Microchip had a GCC-based compiler. I thought XC8 and the others were fully proprietary. And, if there are open source variants, why doesn't anybody start a parallel project for it, just like Red Hat Enterprise Linux and Centos or SUSE and openSUSE?

As I understand it, XC8 is based on the proprietary Hi-Tech C compiler, while XC16 and XC32 are gcc-based.

Microchip do their best to ensure that only their compilers will work with MPLAB X, and to defeat attempts to enable optimization.

[ale500]

I tried in 3 different evironments to compiles microchip's gcc: mingw, cygwin and centos 6 32 bit. it failed every time, on different packages. I found a post somewhere... that explained how to compile it (and also reported that it was broken) but  never made it as far as cc1 .
http://jubatian.com/articles/turning-on-optimizations-in-microchips-xc32/

on windows bombed on ppl or on cloog (cygwin/mingw). On centos bombs in binutils due to some sh*t microchip added to verify the license .

[BradC]

Microchip do their best to ensure that only their compilers will work with MPLAB X, and to defeat attempts to enable optimization.

No they don't. You're just not trying hard enough.
brad@bklaptop:/opt/microchip/xc8/v1.30/bin$ wc -l xclm.c
76 xclm.c

[rolycat]

Microchip do their best to ensure that only their compilers will work with MPLAB X, and to defeat attempts to enable optimization.

No they don't. You're just not trying hard enough.
brad@bklaptop:/opt/microchip/xc8/v1.30/bin$ wc -l xclm.c
76 xclm.c

Which proves what, exactly?

[BradC]

Microchip do their best to ensure that only their compilers will work with MPLAB X, and to defeat attempts to enable optimization.

No they don't. You're just not trying hard enough.
brad@bklaptop:/opt/microchip/xc8/v1.30/bin$ wc -l xclm.c
76 xclm.c

Which proves what, exactly?

It proves that Microchip are making *cursory* attempts to defeat enabling optimisation, not "doing their best". It is easy to defeat and they are making no attempt to make it harder.

[rolycat]

Microchip do their best to ensure that only their compilers will work with MPLAB X, and to defeat attempts to enable optimization.

No they don't. You're just not trying hard enough.
brad@bklaptop:/opt/microchip/xc8/v1.30/bin$ wc -l xclm.c
76 xclm.c

Which proves what, exactly?

It proves that Microchip are making *cursory* attempts to defeat enabling optimisation, not "doing their best". It is easy to defeat and they are making no attempt to make it harder.

You've still lost me, I'm afraid. How does a line count on a source file not present in the current distribution prove all that?

rolycat@zen /opt/microchip/xc8/v1.34/bin $ wc -l xclm.c
wc: xclm.c: No such file or directory

[Howardlong]

Microchip do their best to ensure that only their compilers will work with MPLAB X, and to defeat attempts to enable optimization.

No they don't. You're just not trying hard enough.
brad@bklaptop:/opt/microchip/xc8/v1.30/bin$ wc -l xclm.c
76 xclm.c

Which proves what, exactly?

It proves that Microchip are making *cursory* attempts to defeat enabling optimisation, not "doing their best". It is easy to defeat and they are making no attempt to make it harder.

Microchip, as with many other vendors these days use Reprise for licence enforcement. The node locked licenses use a MAC address to validate against, and the software chooses one from your list of several when you install it, and it's pretty likely it may not be the one you want it to use.

Regrettably I've historically had a lot of difficulty with Reprise node locked licensing as a bona fide punter of a couple of products, including the Microchip compilers, Made with Marmalade cross platform mobile development tools and ShadowProtect backup software. It breaks too easily, and for no apparent reason it will use up your "lives" from the internet-based license database with duplicate entries. In some cases the database is queried frequently, and it will break the software if it doesn't get a response on demand. Some vendors also choose not to allow deregistering and re-registering, or make it very time consuming to fix or move licences to replacement machines, usually with a manual process. In the meantime you have no software.

When, as a legit punter, your software breaks and the vendor makes it difficult to resolve, for example having to wait for an human email exchange, it encourages you to look for other means to enable it. I have no qualms in investigating other options, and it may well be worthwhile me looking into xclm bodges in case it suddenly breaks on me again.

[BradC]

You've still lost me, I'm afraid. How does a line count on a source file not present in the current distribution prove all that?

Ah, sorry. You compile the file and use the resulting binary to replace the xclm binary in all your microchip compiler directories. My point in the line count is that it is a tiny file. For XC8 you need to use that file, for the others you can use a 2 line bash file if you like. Either way you now have access to all the "optimisation" levels.

[BloodyCactus]

and all xclm needs to do is 'return 2' as in 'int main(void) { return 2; }'...

replace xclm binary with that, then replace its sha256sum thats embedded as a string inside gcc/g++

[rolycat]

OK.  Thanks, guys.

[ale500]

... I still want to recompiles microchip sources... not defeat their weak on purpose so they have an excuse system...

@BardC: Nice to see you around , I'm Ale from the propeller forums

[Howardlong]

and all xclm needs to do is 'return 2' as in 'int main(void) { return 2; }'...

replace xclm binary with that, then replace its sha256sum thats embedded as a string inside gcc/g++

Does this work with XC8 which isn't gcc? I couldn't find the sha256 in the files I looked at. It is present in xc16 and xc32 recent releases.

[BloodyCactus]

I only use it for xc32. xc8 is a different beast and is not open source.

[BradC]

Does this work with XC8 which isn't gcc? I couldn't find the sha256 in the files I looked at. It is present in xc16 and xc32 recent releases.

No, You need the xclm.c file I alluded to earlier. It has a simple hardcoded challenge response and requires more than just an exit code. I found it with a bit of google-fu. It's not hard.

[BradC]

... I still want to recompiles microchip sources... not defeat their weak on purpose so they have an excuse system...

@BardC: Nice to see you around , I'm Ale from the propeller forums

Hey Ale, thought it might have been you. Unfortunately the source for the XC8 compiler is not open, so you can't recompile it anyway.

[ale500]

Hei Brad !,

I'm after gcc.pic32 anyways. . I don't use 8 bit pics or xc8 . For the time being I'm using another pre-compiled (it does't work from inside mplabx) gcc outside mplabx... and then linking the resulting object. for testing purposes works well.

[Howardlong]

Does this work with XC8 which isn't gcc? I couldn't find the sha256 in the files I looked at. It is present in xc16 and xc32 recent releases.

No, You need the xclm.c file I alluded to earlier. It has a simple hardcoded challenge response and requires more than just an exit code. I found it with a bit of google-fu. It's not hard.

Ok, understood. I remember a couple of years back when they released a version of one of the compilers where they'd broken the licence check and each compiler invocation took several seconds making build times about four or five times longer. It is this kind of irritation that bone fide users have to put up with all too often from Microchip. I used to think the quality was primarily lacking in the software tools with the chips themselves being reasonably good, but I guess they took one of the software guys on to build the PIC32MZ series!

Actually the compilers XC16 and XC32 themselves are pretty good. XC8 much less so. It's the IDEs and now their Harmony framework that are bad in my experience. I still use the old MPLAB 8 IDE if I can get away with it, it's much faster for the edit-compile-debug cycle, and it is possible sometimes to hack it to use some of the newer chips (although not for simulator use). MPLAB X has improved functionally particularly in the debugger interface which was very buggy, not even the PICkit 3 worked for me at one time, and it's still slower than the old IDE.

Harmony, though, well that's a whole new level of pain. "Faster time to market" apparently, I'd love to see that marketing strapline proven

[ale500]

Maybe if Dave does a video about how bad Harmony is... they will fix it !  , I remember laughing on the floor with those videos.