PIC programming - where to start and which programmer to get

[Howardlong]

I use PICs for 95% of my day job, and as a result I have practice in everything PIC from PIC10F to PIC64. I keep example devices in stock for pretty much every device family released over the past 15 years, and most have dev boards where available. I also have _every_ debugger they've released in the past 25 years.

FWIW, my Microchip journey goes back to the General Instrument days of the 70s: Microchip was spawned from the GI Microelectronics division in 1987. Yes, I'm that crusty.

As for a programmer/debugger, I'd say PICkit 5 is the one to go for, not least because it:

o Programs high voltage Vpp devices;
o Has an integrated UART-serial bridge;
o Can power devices for tinkering about;
o Will program every MCU in Microchip's line-up
o Will debug every MCO with on-chip debugging (almost every chip over the past 15 years).

Neither the Snap nor the PICkit Basic have a high voltage programming mode, which excludes some old chips, and also imposes limitations on newer chips sharing a GPIO with the reset (MCLR) pin, not  big deal unless you're desperately short of pins.

PICkit 3 would be a mistake nowadays. The latest IDE has dropped support for Gen 3 programmers and debuggers, and support for new devices stopped some years ago.

Gen 4 and Gen 5 programmer/debuggers support all chips, barring the Vpp limitation of Snap and PICkit Basic.

o Gen3 includes PICkit 3, ICD 3, RealICE, PICkit-on-board3 (PKoB3 integrated onto older dev boards)
o Gen4 includes Snap, PICKit 4, ICD 4, ICE 4, PICkit-on-board4 (PKoB4 integrated onto newer dev boards)
o Gen5 includes PICkit Basic, ICD 5.

Another approach, if you're only interested in the 8 bitters PIC12 thru PIC18 released in the past 15 years or so is the Curiosity LPC board DM164137 for 8 to 20 pin devices. This has a DIP socket and PKoB4 programmer/debugger with a handful of LEDs and buttons.

For 28 and 40 pin DIP PIC16 & PIC18 devices, there's the Curiosity HPC board DM164136. Again it includes the PKoB4 programmer/debugger, and a few LEDs and buttons.

Both boards include a UART to Serial bridge integrated into the programmer/debugger. You can program your device on the board, then put it into your own circuit. You can also wire up the debug pins into your own circuit, and debug your target in its target environment.

Almost all PIC10 through PIC18, even newly released ones, are available in DIP. Only the higher pin count devices (over 40 pins) aren't.

For PIC24, dsPIC, and PIC32 generally need purpose built dev boards or your own design with an external programmer/debugger. For a while about ten years ago, there was the Microstick I and II that supported numerous 28 pin PIC24, dsPIC33 and PIC32 in DIP packages. There are also several 16 bits & 32 bit PIC32M available on PIMs (plug-in modules) that plug into the Explorer 16/32 board.

Unfortunately, no new PIC24, dsPIC or PIC32 have been released in DIP for some years, although those that are are not EOL.

One of the best things about Microchip is that as a general rule of thumb they don't EOL anything. Very occasionally a device will EOL, but that is due to things like them using an esoteric package that they can't make anymore.

However, one of the worst things about the Microchip ecosystem are the MPLAB X IDE and MCC frameworks, and it's become worse in the last year or so. My suspicion is that's because anyone who knew anything has been shipped off to work on the new VSCode implementation.

Unfortunately the VSCode implementation is even more bleeding edge than MPLAB X.

Something to note about the all 8 bit PIC cores is that their cycle time is 1/4 the clock speed.

The 16 bits PIC cores' cycle time is 1/2 clock speed.

All 32 bitters are 1:1 cycle time and clock speed.

Whether it's an archaic architecture or not isn't necessarily relevant. The first functioning ARMs out of the foundry came out over 40 years ago now, yet the basic underlying architecture pervades to this day, with some tweaks.

The same applies to the 8 bit PICs, with only 9 years ahead of ARM. I'm pretty sure we don't refer to ARM as "archaic". 8 bit PICs have undergone a number of improvements to their core architecture over the years. They're still regularly releasing new devices with new features, including some substantially more complex programmable logic on chip. For PIC16, it's these peripherals that keep it going.

PIC18 had a core facelift a few years ago with vectored interrupts and DMA, that was quite a shot in the arm for the product line up (no pun intended), and again they enjoy many of the same peripherals from the PIC16 heritage.

If you're programming the 8 bitters in C, the archaic nature of the core, particularly bank switching, won't affect you at all. But if it's assembler you're after, I can't really recommend these 8 bitters as a good introduction.

PIC24 and dsPIC30/33F/33E are 16 bit and use a rather pleasing architecture, a million miles away from the 8 bitters and their pesky bank switching. They're definitely not RISC, enjoying tons of addressing modes available to most instructions.

PIC32M is the MIPS core, so although it's the best supported PIC32, it's a dead end as far as development goes: MIPS' owners have switched to RISC-V. PIC32C is the ARM processor, and is the new kid on the block in PIC32 terms.

Regarding low power, it's all about experience, experimentation, and knowing your way around a datasheet. I did a sub-microwatt LCD clock with a PIC a few years ago, which shows what can be achieved. More recently, that technology found its way into a novelty wrist watch.

There are some interesting new developments coming out of Microchip, such as the dsPIC33A and PIC32A series. These are their own 200MHz 32 bit core, and it's not ARM, MIPS or RISC-V. I've been working with these chips intensively recently, and for raw compute in DSP applications they're difficult to beat in terms of efficiency. As well as a 72 bit fixed point DSP core, they include a double precision FPU. What really floated my boat as a game changer in my area of mixed signal work is that they have sin() and cos() in silicon, 4 cycles each, although with instruction interleaving you can get that down to a single cycle.

So that's my take. TL;DR PICkit5, or one of the 8-bit Curiosity LPC/HPC dev boards that I mentioned.

[Adrian_Taylor333]

Whether it's an archaic architecture or not isn't necessarily relevant. The first functioning ARMs out of the foundry came out over 40 years ago now, yet the basic underlying architecture pervades to this day, with some tweaks.

The same applies to the 8 bit PICs, with only 9 years ahead of ARM. I'm pretty sure we don't refer to ARM as "archaic". 8 bit PICs have undergone a number of improvements to their core architecture over the years. They're still regularly releasing new devices with new features, including some substantially more complex programmable logic on chip. For PIC16, it's these peripherals that keep it going.

Difference between the two is that ARM had a great idea and a vision. THis is why ARMs around the world rock in phones, tablets etc - their basic formula to decruft existing computing has survived and is thriving.
PIC OTOH has been misused desing from the start, which then methastasized all over MCU space and liquified  into diarrhea that started oozing everywhere.

Its initial mission was to act as a extremely dumb but cheap controller, executing small piece of code, while emulating some hardware.
Typically executing couple tens of instructions in a tight loop and having the context of maybe couple tens of bytes of data.

This is why it was extremely dumb from the start. Originally it didn't have even indexing mode FFS. And certainly no stack.

Since you can't make Einstein out of Frankenstein, this shows today big time.
PIC16 is totally braindead and should be avoided. For thousand reasons.

PIC18 had a core facelift a few years ago with vectored interrupts and DMA, that was quite a shot in the arm for the product line up (no pun intended), and again they enjoy many of the same peripherals from the PIC16 heritage.

PIC18 is PIC16 with a Band-Aid on its forehead. With extra charge for the Band-Aid.
Don't touch it with a 10ft pole if you don't have to.

If you're programming the 8 bitters in C, the archaic nature of the core, particularly bank switching, won't affect you at all. But if it's assembler you're after, I can't really recommend these 8 bitters as a good introduction.

Using C can't  hide its problems:

   * small controllers need one to be frugal with their resources
   * PICs are not that compiler friendly
   * Microchip's whole SDK stack and each component within has its own problems, compilers included
   * MC compilers are old and lag gcc/clang/etc. Those that are gcc-based, are fork of very old versions
   * free versions have only VERY basic -O0/1 optimisation level (no-O2/3, no LTO, AFAIK no PGO etc)
   * non-free versions are priced insanely for what they are
   * there is a speed tax. Already scarce resource (CPU muscle) gets dilluted further by C, both for covering its own inefficiencies and for plastering over the HW cracks and holes.

Outside of 5V world, 8-bit MCUs make little sense. AND PIC line makes no sense even within that niche.
Only exceptions that come to mind might be some special models with exact peripheral fit for a particular app. And/or an exceptionally low price.
Or maybe long-term availability.

For everything else there are far better options.

Why would one expect better price for a 8-bit micro, if its core is usually only a small part of the whole chip area ?
Most of the chip area  is consumed by FLASH etc.
Since these things are made on oldest processes, which are more robust (greater distances, gate-oxide thickness, less EMI, thermal and electromigration problems etc etc),
5V world makes sense. I suspect that its also easier to have more durable FLASH as a side-effect.

Once the performance need get bigger, oldest processes get more costly and bang/$€ equation changes.

[brucehoult]

Outside of 5V world, 8-bit MCUs make little sense. AND PIC line makes no sense even within that niche.
Only exceptions that come to mind might be some special models with exact peripheral fit for a particular app. And/or an exceptionally low price.
Or maybe long-term availability.

For everything else there are far better options.

With even I think 180nm (and TSMC for example offers 5V toleration down to 28&40 nm, and others to 130nm) 8 bit don't even have a cost advantage because you get pad-limited wth the MCU itself taking only a small portion in the middle of the silicon die with a lot of totally wasted space. You might as well use that space for a 32 bit processor.

With 32 bit Cortex-M0 and RISC-V flash MCUs selling for around 10c it's only the 3c 8 bit PIC clone Padauk priced significantly lower, and that's an OTP chip which is ok for volume manufacture but not development. The flash version of the Padauk actually costs more than the PY32F002A and CH32V003/002, and only has 1k instructions and 64 bytes of RAM, vs 6k-10k instructions and 2-4 KB RAM for the 32 bit chips.

[cv007]

If you want to try a pic, Microchip makes several pic16F curiosity nano boards. They are inexpensive (~$10), come with a programmer/debugger on board and are a quick way to get started. If you decide to go a different direction, you are out $10. They also have the same type of boards for their newer avr's also, which are a 'better' avr than the original.

I would recommend the curiosity eval board (DM164137), but prices now seem insanely high for that (I think they were ~$20 when I bought mine long ago).

I doubt you will find big differences in power consumption among the mega328/avr01/pic16F, and it pretty much boils down to voltage and clock speed (for the mcu). For the pic, you have to keep in mind the clock speed is x4 the cpu speed so datasheet power comparisons have to adjust (4MHz avr vs 16MHz pic). The power consumption data in the datasheets will be pretty accurate, provided you understand what mcu state the data apply to. If you have external power consumption, obviously that is a separate matter.

You can use MPLABX in Linux, and it will work fine. The C compiler they have (XC8) also works fine, and the 'free' version without every optimization is also fine.

An old project for a PIC16F15323 written in C-
https://github.com/cv007/3DigitLed/tree/master

These newer pic's (not so new anymore) are actually pretty nice. Peripheral pin select, nice peripherals, and quite simple to setup/use pretty much anything in the mcu. I have not used them in quite a while and prefer using the gcc toolchain (C++) so the 8bit pic wouldn't be my first choice, but I also would not exclude them if they had something that was a good fit for what is needed.

Also an old project for a 10F322 (I think it was an LF), also in C (must be before I decided I dislike defines/macros),-
https://github.com/cv007/2button_remote/blob/master/main.c
(this has been in use for many years, same cr2032 battery, I think it sleeps at maybe ~100 nA)

I think you should first figure out where all your power consumption is originating- mcu, external devices, etc. If you will be gaining nothing with a different mcu, it would probably be nice to know now instead of later.

[westfw]

I would consider a PICkit3 (or PICkit3.5 if these are geniune - note it says "Kit 3.5" not "PICkit 3.5") to dip toes in water so to speak if:

a) I could tell what is genuine and what isn't.

AFAIK, there are no more "genuine" PICKit3s being sold.  MicrochipDirect doesn't even list the PICKit4 any more.  (Microchip is pretty good at continued manufacturing of their chips.  Not so much, their development tools.)  (My records show I bought my PICKit4 in 2018.  That's a pretty long time ago.)

The PICKit3 was particularly long-lived and widely cloned because the firmware was downloaded "on demand", and the clones therefore didn't need to pirate the firmware.  (And then there was 3rd party firmware to program AVRs and other stuff, back before the Atmel acquisition.)

I think someone noted that [SNAP] may support a smaller range of chips and that does indeed seem to be the case - a much smaller range.

I don't think "much smaller range" is particularly accurate.  SNAP doesn't support the long-obsolete PIC16C chips, or the slightly newer Flash chips that still required HV programming.  And you have to avoid putting the newer chips into modes where they sacrifice a low-voltage programming pin to create another IO.  But those aren't very big limitations...

I did some adapters for SNAP to ISP/UPDI/SWD, since microchip charges (or used to charge) a small fortune for the various cables that went between their low-cost programmers and the actual chips and/or standard programming connectors:  https://oshpark.com/profiles/WestfW

[Howardlong]

Difference between the two is that ARM had a great idea and a vision.
... <long opinionated rant>...
Using C can't  hide its problems:

   * small controllers need one to be frugal with their resources

Well yes, but you also get more frugal devices when it comes to the power budget. In the real world away from banner specs, practically speaking you will almost never achieve better power consumption with an ARM device in button cell energy level applications.

   * PICs are not that compiler friendly

Why do you care? It's done for you.

   * Microchip's whole SDK stack and each component within has its own problems, compilers included

All of the compilers are pretty good in general. But I agree, the IDE and particularly the frameworks (MCC) are crap, which is why you don't use MCC except for very complex peripherals like USB. Bare metal is almost always the way to go with the 8 and 16 bitters.

   * MC compilers are old and lag gcc/clang/etc. Those that are gcc-based, are fork of very old versions

In general I find them pretty good and bug-free (unlike the IDE and MCC frameworks). And I use them every single day. I have discovered three compiler bugs in 20+ years of using Microchip C compilers, I'd say that's pretty good.

   * free versions have only VERY basic -O0/1 optimisation level (no-O2/3, no LTO, AFAIK no PGO etc)

The free versions of all the current XC compilers go up to and including -O2. IME, there's not much difference between -O2 and -O3 in most cases.

LTO/PGO: XC8 uses omniscient code generation, all offer procedural abstraction. LTO is offered in XC32. You will need a PRO or eval licence to use them.

For at least 90% of the time I work in -O0, not least because it's good enough and I like my debugging to step logically and be able to place breakpoints where I want. As I mentioned, practically speaking, the difference between -O2 and -O3 is marginal, particularly on XC8. I am sure you can find edge cases where -O3 is substantially better, but I can't think of one particular occasion when it has been. System & regression testing, and release to production? Yes, of course I use -O3, because I can!

   * non-free versions are priced insanely for what they are

I suggest that you revisit. If you want the PRO features, the licensing completely changed about six months ago. I agree though, that the sticker shock on three annual renewals was bad. Now there is a single licence for all three compilers at around the same price as just one of the three compilers previously.

Alternatively, you can also use a pay-as-you go monthly subscription.

Even more alternatively, there is a hack on this forum to enable the PRO features on the XC-16, XC-DSC and XC32 compilers which still works to this day.

BTW, development of XC16 is over, because it's been rebranded to XC-DSC. Gotta love marketing, however the rationale is that this compiler now also supports the 32 bit dsPIC33A series.

   * there is a speed tax. Already scarce resource (CPU muscle) gets dilluted further by C, both for covering its own inefficiencies and for plastering over the HW cracks and holes.

This applies to every C compiler on every architecture.

A reminder for you that the clock I mentioned up thread, is written in pure C, with no assembler. It draws 386nA at 1.8V, and that includes keeping the LCD running. I guarantee you will not find an ARM processor that will achieve that.

Outside of 5V world, 8-bit MCUs make little sense.

Microchip also offer a range of 5V ARM within the PIC32CM range.

AND PIC line makes no sense even within that niche. <more ranting>

Only exceptions that come to mind might be some special models with exact peripheral fit for a particular app. And/or an exceptionally low price.
Or maybe long-term availability.

Most of these peripherals aren't niche. Offloading work to hardware is a long tried and tested means of reducing the need for CPU resources.

The biggest friction to using 32 bit MCUs is the lack of the very peripherals you're discounting as "niche".

For everything else there are far better options.

<more ranting but now with several unsubstantiated claims, opinions and FUD>

Since these things are made on oldest processes, which are more robust (greater distances, gate-oxide thickness, less EMI, thermal and electromigration problems etc etc),

You do realise that even some of the 20+ year old devices have been refactored onto much newer process nodes? There is a downside to this... some old devices that had sleep currents in the picoamp range are now in the 10s of nanoamps.



The process nodes used for all devices have moved as time has gone on, not least because there are no foundries with the equipment to make them any more.

If you think 8 bit MCUs are going away, PIC or otherwise, you couldn't be more mistaken. You might not have an application for them, but there are plenty who do.

Of course the world has been increasingly moving to 32 bitters, but the market for 8 bit isn't declining, quite the opposite, and it's increasing at roughly the same rate as that for 32 bitters.

We also missed out one thing, low pin count. If you want low pin count, 8 bits is the place to be. Sure, there are low pin count 32 bitters, but the range is as limited as their generic peripherals.

I was quite excited by TI's announcement five months ago regarding the "world's smallest MCU", a Cortex M0+ XMSM0C1104 in a 1.62 x 0.88mm BGA package. And what do you know, it was a paper launch, and you still can't buy it. Frustrating, as I'd invested in the tools to evaluate it.

As you can tell, I'm open minded about the architectures I use. It's the best tool for the job at hand, and 8 bit, including PIC, is quite often a better fit than shoehorning in 32 bits just because you can.

[WaveyDipole]

PICkit 3 would be a mistake nowadays. The latest IDE has dropped support for Gen 3 programmers and debuggers, and support for new devices stopped some years ago.

Thank you for actually confirming that issue of support. I read that this might be the case, but it was not clearly confirmed.

As for a programmer/debugger, I'd say PICkit 5 is the one to go for, not least because it:

Agreed on that, especially after the comments from @westw as well below. Thank you.

Another approach, if you're only interested in the 8 bitters PIC12 thru PIC18 released in the past 15 years or so is the Curiosity LPC board DM164137 for 8 to 20 pin devices. This has a DIP socket and PKoB4 programmer/debugger with a handful of LEDs and buttons.

Had a look at the Curiosity boards. I thing I would presef the PICkit5 because it basically it support all types of PIC chip in pne package but thanks for pointing out the options.

However, one of the worst things about the Microchip ecosystem are the MPLAB X IDE and MCC frameworks, and it's become worse in the last year or so. My suspicion is that's because anyone who knew anything has been shipped off to work on the new VSCode implementation.

Unfortunately the VSCode implementation is even more bleeding edge than MPLAB X.

I actually saw a comment about that elsewhere where the author mentioned they had stuck with IDE 8 because they couldn't get on with IDE X although he didn't actually give any details. I didn't know there was a vscode plugin, but if that's even worse...

Just seen your new post appear....

[Howardlong]

I would recommend the curiosity eval board (DM164137), but prices now seem insanely high for that (I think they were ~$20 when I bought mine long ago).

I still do recommend it, but yes, what happened to the pricing?!? This is an order from May 2021.

Also an old project for a 10F322 (I think it was an LF), also in C (must be before I decided I dislike defines/macros),-
https://github.com/cv007/2button_remote/blob/master/main.c
(this has been in use for many years, same cr2032 battery, I think it sleeps at maybe ~100 nA)

Sleep current on the older PIC10F20x series is even lower, in the picoamps.



(I don't recommend the PIC10F20x or PIC10F22x by the way, unless you really need those picoamps, there are just too many other compromises).

[WaveyDipole]

Difference between the two is that ARM had a great idea and a vision. THis is why ARMs around the world rock in phones, tablets etc - their basic formula to decruft existing computing has survived and is thriving.
PIC OTOH has been misused desing from the start, which then methastasized all over MCU space and liquified into diarrhea that started oozing everywhere.

Ooh! That's quite a stong comment!

Its initial mission was to act as a extremely dumb but cheap controller, executing small piece of code, while emulating some hardware.
Typically executing couple tens of instructions in a tight loop and having the context of maybe couple tens of bytes of data.

Did notice from the specs that they generally have only a handful of kb's of flash andf less in terms of peripheral hardware, although some of the newer ones do appear comparable to AVRs.

Not quite sure whether that places the ATtiny? It seems closer to but more advanced than the PIC, but if you now look at the Microchip website for an ATtiny, they direct you to an AVR. The new range of ATtiny2 chips are apparently considered part of the AVR "family" which gets a little confusing, although it seems for a small Project like this one, the ATtiny would make sense.

Then again, I also see pics used in all sorts of hardware?

Outside of 5V world, 8-bit MCUs make little sense. AND PIC line makes no sense even within that niche.
Only exceptions that come to mind might be some special models with exact peripheral fit for a particular app. And/or an exceptionally low price.
Or maybe long-term availability.

For everything else there are far better options.

I did wonder whether to bother with the 8-bit versions. For this particular project and initial learning, an 8-bit with best clock speed and more than minimal memory (7kb+) would probably suffice. However, going forward in the longer term, especially where one needs to interoperate with a 3V3 environment, that's probably a valid point.

[brucehoult]

   * there is a speed tax. Already scarce resource (CPU muscle) gets dilluted further by C, both for covering its own inefficiencies and for plastering over the HW cracks and holes.

This applies to every C compiler on every architecture.

No, that's not correct.

Part of the design of the RISC architectures appearing from about 1985 on is that they provide everything needed to make compiling high level languages such as C or Pascal as efficient as possible, and they don't provide anything extra to that, that won't be used by C compilers. Most of the time there is really nothing to be gained by going to asm unless you are doing something very specialised that is outside the C execution model. An example of that is multiple entry points to the same function with some of them adjusting the arguments or doing a little work and then falling through past another entry point. Though even that example if less strong with ISAs that pass arguments both arguments and return address in registers and have compilers that know how to do tail calls ... and a peephole optimiser that removes a JMP to the next instruction.

In MIPS, any of the Arm ISAs, or RISC-V it is really very hard to beat a modern compiler on code that can be naturally expressed in C.

An example where you can still get a small advantage in asm is where you have a switch statement with a lot of cases that are mostly about the same amount of code. C will generate an array (jump table) with pointers to the code for each case, or offsets to add to the PC, or jump instructions. In asm you can scale the selector by a size that is large enough to fit the code for most of the cases (let's say 16 or 32 bytes, but it doesn't have to be a power of 2 if you have a fast multiply instruction, or a shift-and-add) and just jump directly into the appropriate code. Cases with less code need to be padded with NOPs (or followed with `.align`), and cases with more code have to end with a JMP to the rest of the code somewhere.

Actually, it not that a compiler can't do this -- in fact they could do the tedious bookkeeping of keeping track of the code size in each case and optimising the common size better than a human can -- but just that no one has programmed the necessary algorithm into the compiler. And in most cases the 1 or 2 instructions saved is not worth the trouble. Unless that switch, in a loop, is the hot code for the program e.g. in Apple's original M68k emulator on PowerPC, where the vast majority of m68k instructions could be emulated by one PPC instruction [1] and Gary Davidian built an array of 65536 entries containing two PPC instructions each (the 2nd being a JMP).

I should mention CISC. CISC ISAs were designed to maximise programmer productivity, even at the expense of producing larger slower code. DEC knew darned well that the VAX 11/780 was going to be slower than the PDP 11/70, but to them it didn't matter because machines were getting cheap and programmers were getting expensive and overworked, and customers could just buy more machines. It is also very convenient for compilers to  take advantage of the CISC features. It simplifies the compiler. But on those CISC machines you could often get faster code by not using the single-instruction convenient things that, actually, did too much, did more than you needed in a particular case, in a too-general way. So a good asm programmer could beat either of a lazy asm programmer or a compiler that used the powerful instructions.

[1] or at least set up, and then branch to common code that handled many instructions.

[WaveyDipole]

If you want to try a pic, Microchip makes several pic16F curiosity nano boards. They are inexpensive (~$10), come with a programmer/debugger on board and are a quick way to get started. If you decide to go a different direction, you are out $10. They also have the same type of boards for their newer avr's also, which are a 'better' avr than the original.

I would recommend the curiosity eval board (DM164137), but prices now seem insanely high for that (I think they were ~$20 when I bought mine long ago).

Yes, I stumbled across a couple of those nano evaluation boards as well. Of course one is limited to just that single onboard PIC chip, but I guess it is a possible "student" learning option.

On the other hand the Curiosity board would be a more flexible option and I did find a DM164136 board on eBay for GBP30 in a somewhat tatty box, but then discovered that it can e purchased from one of the main resellers for about the same price. The DM164137 is rather more expensive as you point out.

I just discovered that the PICkit5 is now available in the UK from Mouser. Even though the cost is higher it does have several advantages. I was almost ready to pull the trigger to invest in it with the goal of learning and alternative to AVR hobby project use but....

It is unfortunate that some recent comments are calling into question the programming of PICs in the first place which has rather muddled the picture. I am willing to branch out and learn, but its pointless to spend money if the technology no longer makes sense today.

 

[WaveyDipole]

I would consider a PICkit3 (or PICkit3.5 if these are geniune - note it says "Kit 3.5" not "PICkit 3.5") to dip toes in water so to speak if:

a) I could tell what is genuine and what isn't.

AFAIK, there are no more "genuine" PICKit3s being sold.  MicrochipDirect doesn't even list the PICKit4 any more.  (Microchip is pretty good at continued manufacturing of their chips.  Not so much, their development tools.)  (My records show I bought my PICKit4 in 2018.  That's a pretty long time ago.)

That explains a lot.I did wonder why there were no PICkit4 on the shelf anywhere at alk but lots ot PICkit3.

I think someone noted that [SNAP] may support a smaller range of chips and that does indeed seem to be the case - a much smaller range.

I don't think "much smaller range" is particularly accurate.  SNAP doesn't support the long-obsolete PIC16C chips, or the slightly newer Flash chips that still required HV programming.  And you have to avoid putting the newer chips into modes where they sacrifice a low-voltage programming pin to create another IO.  But those aren't very big limitations...

I based that on the compatibility list that I recently downloaded from Microchip, where quite a few chips are shown as not supported on the SNAP comapared to the PICkit4. Then again, PIC is still all new to me so I am learning here from everyones comments which I am grateful for. The first dozen or so PIC chips that I chose from that were avaialble on Farnell were not supported. I then resorted to searching the other way around - looking at the compatibility list and then checking stock at Farnell. None of the PIC18 chips appear to be supported by SNAP, but some of the (I presaume newer) PIC16 ones are. A lot of the lower numbered ones (PIC12 etc are not supported.) There are quite a few in other ranges as well, up and down the list. Haven't looked too deeply into the reasons. What did also become apparent is that although Farnell still had stock of some DIL chips, the ones like PIC16F99999 (i.e. with 5 digits following) were not available in DIL packages, only SOIC and other square types. No surprise I suppose because everything very much  SMD now. But yes, my comment probably was a bit inaccurate.

[Howardlong]

However, one of the worst things about the Microchip ecosystem are the MPLAB X IDE and MCC frameworks, and it's become worse in the last year or so. My suspicion is that's because anyone who knew anything has been shipped off to work on the new VSCode implementation.

Unfortunately the VSCode implementation is even more bleeding edge than MPLAB X.

I actually saw a comment about that elsewhere where the author mentioned they had stuck with IDE 8 because they couldn't get on with IDE X although he didn't actually give any details. I didn't know there was a vscode plugin, but if that's even worse...

MPLAB X first...

Difficult to know where to start, but it has so many quirks when using it you come to accept them. Once you're in the zone on a single project, it mostly works OK, but if I start changing projects it gets confused, and I often find I have to restart it.

Perhaps one of its ongoing biggest issues is its flakiness with the hardware programmer/debuggers, however I've yet to use any IDE that doesn't have problems in this regard. Again, once you're in the zone and everything's working nicely on a single project you can go for hours without a hitch.

Microchip have a terrible QA on their updates, and just like everyone else these days there's a CI/CD mantra of releasing frequently, foregoing full regression testing, and to hell with the end users. Thankfully there are ways to sandbox your MPLAB X versions, and have multiple versions with different updates coexisting (look for the "-userdir" option).

MCC, a collection of frameworks that they promote, is a whole other can of worms, and again, it's difficult to know where to start.

While configuring the chip and its peripherals with a GUI has its attractions, you still have to understand your chip at a datasheet and errata level if you intend to do anything more than a blinky.

It suffers from the same squidgy balloon effect: they fix one thing, then break something else.

For almost all of my 8 and 16 bit work I use bare metal, and use MCC for two things:

1. Generate code for programmable logic peripherals, then I paste the generated into my bare metal project;
2. USB: there's not really any practical alternative.

For PIC32 work, particularly in the past couple of years, I've gradually moved over from bare metal to MCC Harmony for 80% of my work. This isn't because MCC Harmony is particularly good, it's because the complexity and breadth of these devices has developed to a level where it simply is faster to use the code generator, and both accept and work around its limitations & bugs (of which there are many).

The biggest problem of MCC Harmony (Harmony is for 32 bitters only) is its learning curve. To use it effectively you have to get into the grove and resist fighting it. This means you have to consider everything within your application must be written as a state machine. Your code will be state machines dependent on other state machines. Once you're comfortable with that, the friction to adoption is much, much less.

Unfortunately the MCC Harmony examples often confuse things by flattening their application code into a single monolithic state machine, rather than implementing multiple state machines, each with a single responsibility. Now I generally object to the inorganic forcing of software programming principles onto people, however MCC Harmony pretty much enforces much of the SOLID principles mantra without you realising it if you want your code to be maintainable. After a while, it all makes sense, but man, is that learning curve steep.

Edit: One of my biggest bugbears with Microchip is their content management.

For example, they release changes that render their own tutorials useless. Nothing could be more off putting than investing time, effort and $ only to find that the beginner tutorial just doesn't work. I don't think Microchip is alone in this.

I'll also add that Microchip's repo and document management is dire. As well as documentation, they lose entire repos. Because much of their development framework is now on cloud-based repos, the loss of a framework repo can and does make maintaining older projects impossible as you can't even recreate a functioning development environment to maintain your project.

[tooki]

What the hell is up with those prices you found? On Digikey, a Pickit 5 costs £56+VAT. It's currently out of stock, but they're expecting stock tomorrow. That is well above their free shipping threshold.

Microchip itself has over 700 pieces in stock right now, at £55.47, presumably plus VAT. No idea what their shipping costs are. (To Switzerland, it's about $11, shipping from the UK. So I can't imagine UK shipping is expensive.)

Waveshare is simply taking a stock Pickit 5 and bundling it with adapters, cables, and a micro-SD card. Is that really worth an extra £100? I very much doubt it.

I don't know. Its just what I found with a random search. I have no problem paying the £55.47 but I suspect it will have VAT of 20% added plus a postage charge, probably at least 5GBP so I expect the overall cost will be somewhere around £70 or more. That's before one considers import taxes and tariffs on goods from the USA. Unfortunately it looks like I need to create an account and give away a significant amount of personal detail just to get the full cost details which is annoying. I don't generally deal with companies that cannot be upfront about things like tax and shipping costs. I have contacted them for this additional information and will sleep on it as they say. Its might still work out much cheaper than the 160GBP being asked by Waveshare on Amazon so thank you for pointing them out. The sad things is some people may end up paying the Waveshare price without realizing.

FYI: To the UK, Digikey ships with DDP incoterms if you use UPS shipping, which means VAT is collected at the time of ordering, and all customs clearance is taken care of: the price you see at checkout is the total final price, full stop.
Mouser UK says: “Incoterms:DDP
All prices include duty and customs fees on select shipping methods.”

As for Microchip direct: I already told you that Microchip ships those from their UK warehouse, so why would you think you’d be paying for taxes and tariffs on US goods? They’re already imported. You’d be placing a domestic order.

Between this and your subsequent statement about the power consumption, you seem to like to base your decisions based on defeatist assumptions, rather than going to the effort to find the actual answers…

[Howardlong]

On the other hand the Curiosity board would be a more flexible option and I did find a DM164136 board on eBay for GBP30 in a somewhat tatty box, but then discovered that it can e purchased from one of the main resellers for about the same price. The DM164137 is rather more expensive as you point out.

I'm going to put a fly in the ointment here!

There are two versions each of DM164136 (28 & 40 pin) and DM164137 (8, 14, & 20 pins). Microchip never changed the part number.

The earlier versions have PKoB3 so will not support the newest chips, nor will they work with the latest 6.25 version of MPLAB X (6.20 is the last version to support Gen 3 programmer/debuggers). They don't have a UART serial bridge either.

The newer versions have PKoB4 which will support all the current PIC12/16/18 DIP devices released over the past 15 years or so. They also have a UART serial bridge on board.

A gentle reminder that none of these boards support high voltage programming.

Here's how to identify them visually:

[WaveyDipole]

   * there is a speed tax. Already scarce resource (CPU muscle) gets dilluted further by C, both for covering its own inefficiencies and for plastering over the HW cracks and holes.

This applies to every C compiler on every architecture.

No, that's not correct.

Part of the design of the RISC architectures appearing from about 1985 on is that they provide everything needed to make compiling high level languages such as C or Pascal as efficient as possible, and they don't provide anything extra to that, that won't be used by C compilers. Most of the time there is really nothing to be gained by going to asm unless you are doing something very specialised that is outside the C execution model. An example of that is multiple entry points to the same function with some of them adjusting the arguments or doing a little work and then falling through past another entry point. Though even that example if less strong with ISAs that pass arguments both arguments and return address in registers and have compilers that know how to do tail calls ... and a peephole optimiser that removes a JMP to the next instruction.

Must admit I hear that C compilers are pretty much well optimised these days, although I gather the offering with the free MPLAB X IDE is rather inefficient. Could one simply use an alternative compiler e.g. gcc?

The last time I used assember was while hacking BBC Micro 6502 code in the 80s. That knowledge might still be around in the grey cells somewhere, but might be rather difficult to retrieve some 40 years later..... I have no objection to learning PIC assembler, but I think you hit the nail on the head when you said "unless you are doing something very specialised".

Just one question; I presume that for PICs, when various comments are referring to C, that does literally mean C and not C++? So its no Arduino-like language but and one loses the object oriented stuff that is available on Arduino AVRs? Does one still have std:: libraries at least?

[tooki]

I did a bit more digging on the TL866II and it seems that it might not be compatible with MPLAN X IDE. It seems Microchip only support their own devices, so if I go with Microchip, then I will need to buy the Pickit.

I very much doubt MPLAB X supports the TL866II directly in any way. I can’t find any evidence to that effect.

But moreover, why would you want to? The PicKit gives you a HUGE advantage, in being able to do in-circuit programming and above all, debugging. That’s incredibly useful.

I don't know anything about any other brands of PIC chips so if anyone could fill me in it would be appreciated. Are there ny competitors that are worth considering?

You mean like a PIC clone? I don’t know of any, but who knows what Chinese semiconductor makers make. But what would this accomplish for you?

Have you actually done anything to minimize the current draw of the Micro? The ATmega32U4's maximum current draw, excluding whatever you power from GPIOs, is specified at 27mA. The blue power LED on the board draws 2.5mA by itself. You can reduce current dramatically by running it at 4 or 8MHz instead of 16MHz, and a bit further if you run it at 3.3V instead of 5V.

See also: https://docs.arduino.cc/learn/electronics/low-power

I must admit that I haven't and am only looking at ball park figures. Yes LEDs could certainly be removed. I am also only needing to drive one GPIO pin. That's all it needs. Haven't tried driving at lower frequencies yet but the project does deal with sub-millisecond time intervals. So long as that is still possible with reasonable accuracy then I see no problem reducing the clock speed and adjusting the code execution timing.

BTW, is there much difference between the Pickit 3 and the 3.5? Is the 3.5 actually genuine?

I don’t know. But who cares? You can’t buy either of those new anymore. And newer PIC chips are only supported with newer PicKit devices anyway. I don’t know why you wouldn’t just buy a PicKit 5 and call it a day.

[tooki]

I am very familiar with Arduino, but even at 50mA, the Micro draws more current than I would like

An Arduino draws 50mA because nothing on the board makes any effort toward being low-power.  It's got a power-hungry regulator, a power-hungry op-amp, a power-hungry USB/Serial converter, and a bunch of power-hungry LEDs.  ("power-hungry" might be a bit of an exaggeration, but they're certainly NOT "optimized for low power.") The ATmega328p itself (which can still be programmed with Arduino) should consume less than 10mA at 16MHz and 5V (and less than that at lower speeds/voltages.  Even before you make any attempts to lower "average" power consumption with the low-power modes.)

What you wrote here is completely correct for an Arduino Uno, Arduino Pro, or Arduino nano, all models based on the ATmega328p. But the Arduino Micro is not based on the Atmega328p, but on the ATmega32u4, which has native USB and doesn’t use a bridge.

[tooki]

I spoke with Microchip via chat this morning and am very disappointed. I guess its because they are a manufacturer and ship in volume, but they wouldn't provide any information unless I created an account with them and placed a firm order. They wouldn't even tell me whether the order would ship from the UK or the US. That would make a BIG difference. However, I did manage to get a page of US shipping information.

https://www.microchipdirect.com/shipping-info

Looks like it would cost GBP28 (I am assuming that the package will weigh more then 500g) to ship from the states. When it arrives in the UK, I may or may not get hit with further import fees - depends what mood the customs official is in and which way the wind is blowing. If its shipped from the UK it might cost a lot less to ship, but will still carry 20% VAT.

While you do have to create an account to use the web shop, you do NOT have to place an order to find out shipping information. When I checked for Switzerland, it said it would ship from the UK warehouse. (I already told you this, remember??) There is no way they’d ship from their US or Thai warehouse to a UK customer when they can ship from the UK warehouse.

On the Microchipdirect website, the footer has a link about international ordering, with shipping info and prices. UK shipping is like £5.

[WaveyDipole]

However, one of the worst things about the Microchip ecosystem are the MPLAB X IDE and MCC frameworks, and it's become worse in the last year or so. My suspicion is that's because anyone who knew anything has been shipped off to work on the new VSCode implementation.

Unfortunately the VSCode implementation is even more bleeding edge than MPLAB X.

I actually saw a comment about that elsewhere where the author mentioned they had stuck with IDE 8 because they couldn't get on with IDE X although he didn't actually give any details. I didn't know there was a vscode plugin, but if that's even worse...

MPLAB X first...

Howard, you're on a roll! Having a hard time keeping up....
Thank you so much for all the detail. Very helpfull indeed!

Perhaps one of its ongoing biggest issues is its flakiness with the hardware programmer/debuggers, however I've yet to use any IDE that doesn't have problems in this regard.

Again, once you're in the zone and everything's working nicely on a single project you can go for hours without a Microchip have a terrible QA on their updates, and just like everyone else these days there's a CI/CD mantra of releasing frequently, foregoing full regression testing, and to hell with the end users.

All very true, especially the latter unfortunately.

Thankfully there are ways to sandbox your MPLAB X versions, and have multiple versions with different updates coexisting (look for the "-userdir" option).

Now that's something not easily done with Arduino IDE.

MCC, a collection of frameworks that they promote, is a whole other can of worms, and again, it's difficult to know where to start.

While configuring the chip and its peripherals with a GUI has its attractions, you still have to understand your chip at a datasheet and errata level if you intend to do anything more than a blinky.

It suffers from the same squidgy balloon effect: they fix one thing, then break something else.

That's not so unusual in the Arduino world either. But yes understanding chips using datasheets - that's something I have already become accustomed to as I have worked with direct writing to registers etc

Unfortunately the MCC Harmony examples often confuse things by flattening their application code into a single monolithic state machine, rather than implementing multiple state machines, each with a single responsibility. Now I generally object to the inorganic forcing of software programming principles onto people, however MCC Harmony pretty much enforces much of the SOLID principles mantra without you realising it if you want your code to be maintainable. After a while, it all makes sense, but man, is that learning curve steep.

Uugh. Have to agree with that. To me, it all depends on what you are ttrying to achieve and the best way of acheiving that goal. I guess I will have to bear that in mine when looking at their examples.

The earlier versions have PKoB3 so will not support the newest chips, nor will they work with the latest 6.25 version of MPLAB X (6.20 is the last version to support Gen 3 programmer/debuggers). They don't have a UART serial bridge either.

The newer versions have PKoB4 which will support all the current PIC12/16/18 DIP devices released over the past 15 years or so. They also have a UART serial bridge on board.

A gentle reminder that none of these boards support high voltage programming.

Ok, so I am still learning the terminology and although I noted it, was still not sure what PKoB3 and PKoB4 mean so did a google search. This is what I got as a reply:

AI Overview
PK3 and PK4 refer to pre-kindergarten programs for 3-year-olds and 4-year-olds, respectively. These programs are designed to prepare children for kindergarten by focusing on social-emotional development, cognitive skills, fine motor skills, and early literacy and numeracy.

Ok, just posted that for a bit of humour, but eventually I found the answer I think:

https://onlinedocs.microchip.com/oxy/GUID-B9254D1C-4CD6-466C-8BEB-7E7560FD6FBC-en-US-1/GUID-A72BDCBF-1DC2-44DC-82FF-1898F399E4C2.html

I think its clear that I would be better off buying a device with PKoB4 support. Thank you for that information and the 'gentle reminder' :-).

[tooki]

You really want to buy from DigiKey or Mouser, don't bother talking to Microchip they will not be interested. The US distributors like Digikey have free shipping over £33 or thereabouts and make it just as easy as ordering from RS in the UK (and usually quite a bit cheaper); delivery is typically 2-3 days. So for a picKit5 from Digikey you are looking at about £67 including VAT (which they charge, so you don't need to worry about any import charges this end).

Microchipdirect is literally their direct-sales website. Why would they be “not interested”? You sign up, you add the item to the cart, you pay, and they send it to you. They wouldn’t set it up to work that way if they didn’t want it.

[Howardlong]

   * there is a speed tax. Already scarce resource (CPU muscle) gets dilluted further by C, both for covering its own inefficiencies and for plastering over the HW cracks and holes.

This applies to every C compiler on every architecture.

No, that's not correct.

Part of the design of the RISC architectures appearing from about 1985 on is that they provide everything needed to make compiling high level languages such as C or Pascal as efficient as possible,

Respectfully, I don't agree.

It could be argued that x86, PIC24 and dsPIC, for example, are better suited to C than load-and-store RISC architectures like MIPS, ARM or RISC-V because of their base/frame pointer and the pointer addressing modes available to most instructions, not just load and store.

Perhaps I should've phrased it better, how about "This applies to every C compiler on every architecture to some degree".

Yes, I fully agree that PIC16 makes a C compiler work hard. But in almost all circumstances, one just doesn't care because you almost never need to concern yourself with it when writing source code. I am not saying you don't need to concern yourself with the generated code. I look at compiled code every day of my working life whatever architecture I'm developing on. What I am saying is that as a programmer, from experience when writing C for the PIC10/12/16/18, you almost never need to concern yourself with the mundane aspects of dealing with bank switching or how variables are allocated when writing code, or the visibility of data, something you do have to when writing assembler. But I am also not advocating for people to jump into writing assembler on PIC either. I do think it's valuable to be able to at least read assembler on any target processor that you're writing C on.

[tooki]

You really want to buy from DigiKey or Mouser, don't bother talking to Microchip they will not be interested. The US distributors like Digikey have free shipping over £33 or thereabouts and make it just as easy as ordering from RS in the UK (and usually quite a bit cheaper); delivery is typically 2-3 days. So for a picKit5 from Digikey you are looking at about £67 including VAT (which they charge, so you don't need to worry about any import charges this end).

TME.eu may be an option if only for the cheaper shipping - they ship from Poland, probably still gonna have to deal with customs but otherwise...

How is that cheaper than free shipping, with customs already cleared, with Digikey or Mouser?!?

[Adrian_Taylor333]

   * there is a speed tax. Already scarce resource (CPU muscle) gets dilluted further by C, both for covering its own inefficiencies and for plastering over the HW cracks and holes.

This applies to every C compiler on every architecture.

No, that's not correct.

Part of the design of the RISC architectures appearing from about 1985 on is that they provide everything needed to make compiling high level languages such as C or Pascal as efficient as possible, and they don't provide anything extra to that, that won't be used by C compilers. Most of the time there is really nothing to be gained by going to asm unless you are doing something very specialised that is outside the C execution model.

Must admit I hear that C compilers are pretty much well optimised these days, although I gather the offering with the free MPLAB X IDE is rather inefficient. Could one simply use an alternative compiler e.g. gcc?

When people are talking about how good have compilers got, they mean modern, powerful many-core CPUs as targets.
And even there humans are at disadvantage as no assembler I know of does tracking instruction interdependencies, their various execution phase latencies and trhoughputs of various execution chain elements etc.
And yet some crews like FFMPEG developers still insist on using pure assembler in hot paths. And they win with hand-written assembly even there.

Whomever said that PIC16/18 is streamlined for compiled code is a clueless or moron, possibly both.
It is only somewhat less of an utter crap than previous PCI generations.

With old micros like PIC, MCS48/49/51 (8051 and brethren) one can't really optimize the algorithm but data form and layout.
On any 8-bit PIC DATA LAYOUT IS THE KING.
CPU core it basically tetraplegic, so data has to be manuevered and shaped so that it flows through the crappy core with the least hickups and womits.

I usually have to rewrite the code and data a few times to get it right.
There is no way any C/C++/etc compiler can do that.
Reason is simple - compiler has to make extremely conservative assumptions on code transformation during the optimisation and data transformation is almost non-existent.
It can't do much more than to optimize-out some variable etc.

IMO, on PIC16/18, one has no luxury of using C, even if there were no other problems within the SDK stack.

On more decent things like AVR and similar tools, one has no reason to do so. Assembly is there is already awesome.

In general, I find it less unnerving to write my own asm source than to wrestle with C compiler and/or (god forbid!) Microchip's libraries, like Harmony etc.
Those are on whole another layer of crappiness.

[brucehoult]

   * there is a speed tax. Already scarce resource (CPU muscle) gets dilluted further by C, both for covering its own inefficiencies and for plastering over the HW cracks and holes.

This applies to every C compiler on every architecture.

No, that's not correct.

Part of the design of the RISC architectures appearing from about 1985 on is that they provide everything needed to make compiling high level languages such as C or Pascal as efficient as possible, and they don't provide anything extra to that, that won't be used by C compilers. Most of the time there is really nothing to be gained by going to asm unless you are doing something very specialised that is outside the C execution model. An example of that is multiple entry points to the same function with some of them adjusting the arguments or doing a little work and then falling through past another entry point. Though even that example if less strong with ISAs that pass arguments both arguments and return address in registers and have compilers that know how to do tail calls ... and a peephole optimiser that removes a JMP to the next instruction.

Must admit I hear that C compilers are pretty much well optimised these days, although I gather the offering with the free MPLAB X IDE is rather inefficient. Could one simply use an alternative compiler e.g. gcc?

My comments above about modern instruction sets (post 1985) DO NOT APPLY to PIC, which is from 1976 and was designed as a simple Peripheral Interface Controller and not as a general-purpose CPU.

No you can not use gcc for PIC. GCC in general only supports 32+ bit CPUs and a few selected 16 bit ones.

The original PIC instruction set (PIC16 and below) is extremely unfriendly to compilers and can not support the normal full C language.

PIC18 (in 2000) added a few things that help a bit but it's still awful, and is still a minority of the 8 bit PIC market. PIC24, PIC32, PIC64 are completely different instruction sets and not what people mean when they simply say "PIC" without qualification.

The last time I used assember was while hacking BBC Micro 6502 code in the 80s. That knowledge might still be around in the grey cells somewhere, but might be rather difficult to retrieve some 40 years later..... I have no objection to learning PIC assembler, but I think you hit the nail on the head when you said "unless you are doing something very specialised".

My "unless you are doing something very specialised" applied to modern CPUs, not PIC. In (8 bit) PIC you absolutely should use asm, or you should use another better ISA such as AVR or Arm or RISC-V.

Just one question; I presume that for PICs, when various comments are referring to C, that does literally mean C and not C++? So its no Arduino-like language but and one loses the object oriented stuff that is available on Arduino AVRs? Does one still have std:: libraries at least?

No, C and C++ are the same language in this conversation.

C++ makes more use of pointers to structs and pointers to functions (virtual functions in C++) but all the same fundamental features exist in C and require the exact same kinds of instructions from the CPU, even if idiomatic C++ code uses them a bit more often than idiomatic C code (let alone contorted restricted C code designed to compile efficiently on PIC).