Why do people not like Microchip?

[Simon]

Just goes to show how much I need to get into the 32-bit world.  Now if I can just wrap my head around the config...

This is a myth than different worlds exist. All MCUs are roughly the same. If you can work with MCU A, you can work with MCU B using the same principles. All is very similar - how to arrange things in time, how to divide work between CPU and peripherals, how to think and plan before writing code. If something looks complex to you, 99% of the time this is because you don't know how it works. Once you figure this out, it will not look so complex any more.

Choosing an MCU is not a matter of getting into a particular "world", but rather reconciling your requirements against a particular MCU. Often, important characteristics have nothing to do with the MCU internals at all, like you may want a very small MCU, an MCU which is easy to route, an MCU which consumes very low power, or whatever. Most of the time, you envision how you would do things then you select the MCU which can do what you have envisioned.

Precisely, I now find myself thinking: I could do that with one of those new mega's. I only use or think to use ARM because it is faster for complicated things and can handle 32 bit at a time but I have done large number calculations on AVR no problem. Really it's all about the peripherals and the peripheral combinations that drive a particular µC long before you give a damn about the CPU on that µC.

[Kleinstein]

The CPU can be important when more memory is needed. Beyound 64/128K a 8 bit µC add extra complications.
A simple CPU with deterministic run speed can be used with timing from code speed - though usually on with ASM coding. In this case the CPU also makes a difference.  Ideally the critical timing should be set by the HW and not the code, but it is possible for simpler tasks.

In the early days the quality of the IDE and compiler was also a big factor - the limited C for the early PICs was definitely a factor against them. Today something like support by GCC is wide spread and the field leveled a bit.

[hans]

I think the transition from 8-bit / 16-bit MCUs to 32-bit will have a few things to learn, but not as much as some people make it out to be.

I think in terms of CPU, you have the difference of Modified Harvard (8-bit PIC/AVR) and Von Neumann (most 32-bit chips). Reading constants on PICs or AVR requires special treatment with (code-LUT on PIC or LPM instruction on AVR). On Von Neumann it is just a normal memory load operation, since RAM/ROM/peripherals are in the same memory space.
PIC24 is also a Modified Harvard architecture, and has 2 memory spaces for program and data, with accompanying TBLRD instructions (similar to LPM). However, it is also possible to map (a part of) FLASH memory into data memory space, so takes inspiration from Von Neumann.

Design of peripherals on 32-bit MCUs is similar, but perhaps everything is a bit bigger as it has more bells and whistles. But if you learn how setting up the clock (clock tree + enable per peripheral) and GPIOs (remapping/alternate functions) work, I think you're already on the same level as learning a new modern 8-bit MCU. Sure a SPI peripheral on a STM32 may have a few extra configuration/status registers, but most features/bits can be left at zero unused..

Other than that I can't really find any fundamental differences on how you would go about writing C/C++ code on an AVR (e.g. ATTINY/ATMEGA) or a 200MHz Cortex m4. Know what instructions run fast on the CPU, how you can set up peripherals to do the operations you need, etc.

The Cortex-m7 does get a bit more complex because of (data) caches and multi-master memory buses. But I think these MCUs are converging towards application microprocessors (where average-case performance is increased), instead of being "very deterministic" microcontrollers.

[Simon]

The CPU can be important when more memory is needed. Beyound 64/128K a 8 bit µC add extra complications.
A simple CPU with deterministic run speed can be used with timing from code speed - though usually on with ASM coding. In this case the CPU also makes a difference.  Ideally the critical timing should be set by the HW and not the code, but it is possible for simpler tasks.

No, you would be changing the CPU for the sake of the memory, Do you still really care about any non memory related features of just the CPU? by this time you probably wanted those nicer peripherals. I have never really thought about the CPU but then I am not an asm programmer.

Any yes looking at the ARM based SAMC I picked it for the CANbus support and the general speed, but I never said I need ARM, it could have a fast 16 bit CPU for all I care. Even on a 32 bit system I will not waste my memory on oversized variables. It's a bad habit that spills into 8 bit work.

Indeed the clock system was the most complicated bit I have had to get my head around. Things like counters are as simple as AVR.

[hans]

Looking at ESP32.. people really don't seem to care that much it is using a relatively non-mainstream CPU core..

Now there are also RISC-V MCUs on the horizon.. and when I see how popular it already is within the FPGA OSS community, it is incredible. People write a functionally working 32-bit RISC-V CPU in 100 to 200 lines of Verilog. There are plenty of quite performant cores that get to approximately the same calculation power as a Cortex-m3 (barrel shifter + multiplier) or even m7 (dual issue CPU). Attach code and data memory blocks, add your own peripherals, and you have got your own SOC or MCU! .. well running on a FPGA of course.

I was actually profiling some of my firmware codebase for fun over the holidays. I was testing with the RV32I (base spec) and RV32IM (Hardware Multiplier/Divider) in emulation.. In my experimentation you would need a RV32IM with a good pipeline to get close to the speed of a Cortex-m3 CPU. However, to my surprise a lot of code runs at almost the same speed (-I or -IM). Some parts are a bit slower (10-20%) that involve indexing arrays of structs or do other (miscellaneous) arithmetic operations. Some code I refactored because it was possible to replace an integer division with a simple 2^n multiplication (tail division is a lot slower than some 64-bit shift/add/compare). But sometimes CPU benchmarks like Dhrystone etc. really put a lot of weight in the basket of number crunching, while a lot of firmware consists of moving some data around and (conditional) branching. You don't need much more than a RV32I, MIPS, Cortex-m0+ or m3 for that.
(Heck perhaps even 8 or 16-bit CPUs are fine )

[Howardlong]

Looking at ESP32.. people really don't seem to care that much it is using a relatively non-mainstream CPU core..

Now there are also RISC-V MCUs on the horizon.. and when I see how popular it already is within the FPGA OSS community, it is incredible. People write a functionally working 32-bit RISC-V CPU in 100 to 200 lines of Verilog. There are plenty of quite performant cores that get to approximately the same calculation power as a Cortex-m3 (barrel shifter + multiplier) or even m7 (dual issue CPU). Attach code and data memory blocks, add your own peripherals, and you have got your own SOC or MCU! .. well running on a FPGA of course.

There's already a RISC-V ESP32, the EXP32-C3 generally available... if you can find them in stock ;-).

In addition the ESP32-C6 has also been announced, another RISC-V based device.

I agree with your sentiment though, if the dev environment and support is there, and it's cheap, the core itself isn't particularly relevant.

IME the IDE and hardware debug for ESP32 in the ESP-IDF is flakey as ****, but the chips are cheap. I can understand why not many get much further than Platform IO.

If you want WiFi, you'd be nuts not to be considering ESP32 considering the price in comparison to traditional vendors' offerings.

[Sal Ammoniac]

People write a functionally working 32-bit RISC-V CPU in 100 to 200 lines of Verilog.

Do you have a link to an example of this? I'd like to see it.

[SiliconWizard]

People write a functionally working 32-bit RISC-V CPU in 100 to 200 lines of Verilog.

Do you have a link to an example of this? I'd like to see it.

Yes, that was a slight exaggeration IMO =)
If you can find a *working* RISC-V core in 100 to 200 lines of Verilog, so at least complying with the RV32I base, that's either bullshit, or obfuscated Verilog in the same spirit as obfuscated C.
So i'd like to see that as well =)

[hans]

200 lines of code:
https://github.com/BrunoLevy/learn-fpga/blob/master/FemtoRV/RTL/PROCESSOR/femtorv32_quark.v

RISC-V CPUs can be really quite basic. The ALU only has half a dozen operations, in reg[op]reg or reg[op]imm mode. Then there is reg load, memory load/store, jumps and conditional branches.
It's debatable whether the SYSTEM group is needed, which includes ECALL. In an embedded system without OS or system calls, it could be omitted, or implemented as a jump to a fixed PC in FLASH.

IMO this one is even more impressive, but not in straight Verilog (yet a language Silice that is not too abstract from Verilog). This core acoomplishes a dual-core RV32I with only a small fraction of increased code/resources, comparing tot a common 4-stage non-pipelined implementation:
https://github.com/sylefeb/Silice/blob/master/projects/ice-v/IceVDual.md

Obviously you can use varying degrees of "complying" or "compatible". I think these cores miss the ECALL instruction which is often not used, unless you want to implement an OS using system calls.
There is also the SERV bit-serial RISC-V softcore which only takes a few hundred LUTs. But it is incredibly.. incredibly slow. Nonetheless it is possible to fit 1k+ RISC-V cores in a medium/large sized Virtex/Kintex FPGA. However, the SERV core does explicitly document that the core may execute illegal instructions, as the 5-bit opcode was hand-optimized to be decoded by a 4-input LUT to save space. So some opcode bits are handled as don't-care instead of their exact value..

A CPU core only does not make a SoC, which obviously adds a lot more code to connect to a bus (Avalon, AXI, etc.), memory systems, let alone peripherals, etc..
I was amazed nonetheless, because with modern toolchains and CMSIS/HAL libraries, it's easy to get drowned in over 200 lines of boilerplate code just to get PLL, clocks, I/Os set up to create a blinky program.

[nigelwright7557]

PIC's are cheap.
Having to make a pcb for one isnt a hard task so thats what I have always done.
MPLAB X and Harmony can take time to get to grips with but they are free.
Been using PIC's since 1985.
Always read errata sheet first before picking a PIC.
I bought one in and had a pcb made only to find USB wasnt right on it.
I asked Microchip and they said USB doesnt work on 64 pin IC and to read errata sheets first.

Many years ago my boss designed a PIC into a washing machine.
None of the 100 circuit boards worked.
Turned out no one told production the PIC has to be progarmmed first !
So I got them to desolder, program and refit.

[AaronD]

MPLAB X and Harmony can take time to get to grips with but they are free.

Since the PicKit programmer doesn't have a Linux driver, I rigged up a programmer from the GPIO pins of my Raspberry Pi instead, and used a free GPL-licensed command-line tool to run it:
https://wiki.kewl.org/dokuwiki/projects:pickle

And SDCC is better than MCHP's free compiler (doesn't take much at all to say that!):
http://sdcc.sourceforge.net/

So, since I now have a standalone toolchain for PIC too, like I always have for AVR, I just set it all up in Code::Blocks like I always have for AVR:
https://www.codeblocks.org/
No debugger for either one (probably could if I really wanted), but a UART spew and/or oscilloscope output works just fine for what I do.

Many years ago my boss designed a PIC into a washing machine.
None of the 100 circuit boards worked.
Turned out no one told production the PIC has to be progarmmed first !
So I got them to desolder, program and refit.

 

[seamusdemora]

And SDCC is better than MCHP's free compiler (doesn't take much at all to say that!):
http://sdcc.sourceforge.net/

I'm completely new to this, so I have no opinions yet. I decided only recently to try a PIC uC in my Zero Power RPi project - it will interface with a DS3231, monitor battery voltage and replace some discrete logic & a one-shot. I've read a number of posts in this thread, and the compiler seems a sore point with many for a few reasons - quality and licensing seem to be most prominent. SDCC is mentioned often as a replacement for mc8.

I'm a Mac user, and was glad to see that MacPorts covers sdcc : https://ports.macports.org/port/sdcc/

However, both MacPorts and the SDCC SourceForge page (http://sdcc.sourceforge.net/) seem to suggest I stick with mc8:

• SourceForge: 'Microchip PIC16 and PIC18 targets are unmaintained.'
• MacPorts: 'Work is in progress on supporting the Microchip PIC16 and PIC18 targets'

Am I missing something? These two statements are contradictory, but neither one of them is "encouraging" re using sdcc - at least wrt PIC16. If 'gcc' is a btter choice for 8-bit platforms, where can I find that?

Thnx,
~S

[hli]

Since the PicKit programmer doesn't have a Linux driver

They have. I'm using it (on Kubuntu) for quite a while now. They might need some tweaking with the udev rules, and the PicKit seems to be a bit picky with the USB ports, but it works. (Although I upgraded to an ICD4 a while ago).

[DavidAlfa]

I love how Linux guys always use diminutives, "some", "little" "a bit"... which in the great majority of cases means "a lot", "take the poison", "search for a window in the 27th floor" 

[JPortici]

ah, an unmantained compiler is better than the microchip one.
of course.
if you said MikroC i would have said well, ok, maybe, but i completely disagree whenever SDCC is brought in
XC8 is extremely clever in code generation, you just hate ti write clear and understandable C.
When you try to be smarter than the compiler, add inline assembly, use volatile where it's not needed, in that case code generation kinda sucks but that's probably true for most compilers.
Please don't point at useless tests like "LOOK IT'S NOT USING INC BUT IT'S USING TWO INSTRUCTIONS TO INCREMENT A VARIABLE" (insert heavy breathing) but try using meaningful code instead.

one of my favourite examples is the correct use of qualifiers
this function for PIC18

Code: [Select]

uint16_t readFlash(uint16_t address) {
  uint16_t __rom *ptrProgMem;
  ptrProgMem = (uint16_t __rom *) address;
  return *ptrProgMem;
}will generate the exact code needed to read flash, without having to mess with inline assembly. Use a 24 bit address and you can point to configuration, IDLOC, etc, as well.

by the way, does SDCC support the 24bit type and 24bit arithmetics natively? code becomes nonportable, but gives a huge boost in performance over 32bit

what i don't like in XC8 is the linker, it's prone to fail when there is less than one code page available and it still doesn't recognize code spaces that have been added in recent parts (the memory access partition feature) but hey, every version has a small

[seamusdemora]

ah, an unmantained compiler is better than the microchip one.
of course.

Sorry - but I'm not quite clear on this... are you saying that one is better served using the 'sdcc' over the free version of 'xc8' ?

[Simon]

If you are using 8 bit I would use one of the new AVR chips, clearly they are good or microchip would not be coming up with new ones although they stuffed the naming right up. And yes objectively we know that the AVR is 4 times faster than the PIC, why use old designs?

[AaronD]

...SDCC is mentioned often as a replacement for mc8.
[...]
However, both MacPorts and the SDCC SourceForge page (http://sdcc.sourceforge.net/) seem to suggest I stick with mc8:

• SourceForge: 'Microchip PIC16 and PIC18 targets are unmaintained.'
• MacPorts: 'Work is in progress on supporting the Microchip PIC16 and PIC18 targets'

Am I missing something? These two statements are contradictory, but neither one of them is "encouraging" re using sdcc - at least wrt PIC16.

ah, an unmantained compiler is better than the microchip one.
of course.

"Unmantained" simply means that no one is changing it.  What's already there still is what it was when the last person touched it.  It may not be perfect, but if it's still better for the same price (free), use it.

If 'gcc' is a btter choice for 8-bit platforms, where can I find that?

GCC doesn't work for PIC.  It does work for AVR.  Different instruction sets.  One is designed to be "C-friendly", so it's easy to port GCC to it.  The other is "silicon-friendly", originally meant to be programmed only in assembly (as I understand), and backwards-compatibility means that it can't change now.  It works so much differently that a GCC port to that would cease to be GCC altogether.

Since the PicKit programmer doesn't have a Linux driver

They have. I'm using it (on Kubuntu) for quite a while now. They might need some tweaking with the udev rules, and the PicKit seems to be a bit picky with the USB ports, but it works. (Although I upgraded to an ICD4 a while ago).

I love how Linux guys always use diminutives, "some", "little" "a bit"... which in the great majority of cases means "a lot", "take the poison", "search for a window in the 27th floor" 

I didn't know about the Linux driver for PicKit.  I must have missed it, or it must be a new development, or maybe it only supports the older ones while I have a newer one.  Anyway, the thing about tweaking udev rules is also something I have experience with, for a different project, and it's not particularly pleasant.  I still prefer an independent GPIO-based programmer for the Raspberry Pi: https://wiki.kewl.org/dokuwiki/projects:pickle

Read the documentation of course, set it up like it says, and it "just works".  (at least it did for me)

The vast majority of Linux (desktop) uses are no more customized than Windows is, and there are tools built into the GUI package (no matter which of several you end up with) to do just that.  No need to go fumbling around the internals.  If you do, then DavidAlfa has a point, but it's the exact same for Windows too, so... 

...code becomes nonportable...

For a lot of things, that's important, but sometimes it's not.  For most of what I do at home, it's not.

I don't copy code verbatim and "watch it work", which implies frustration to me when the "magic block of text" doesn't "just work".  Instead, I understand the logic and what it's actually doing, and rewrite it for the new platform.  Sometimes it's similar or even identical, sometimes not.  It also helps me remember the context of what I was thinking/doing when I wrote it the first time, which is a big deal too.

Where portability clearly becomes important is when you're not married to any particular platform - like maybe a library, or you're using a dev board that you already have, to get a jump-start before the real hardware comes in - and so the same code verbatim does indeed have to compile successfully and bug-free to several different chips.

My projects are more serial than that, stopping at the "generic block diagram" stage until I have the real hardware, and then I implement it directly for that specific platform.

[joke]

Code: [Select]

#if PLATFORM_1
//complete standalone code for platform 1
#elif PLATFORM_2
//complete standalone code for platform 2
...
#else
#error Platform not supported
#endif
[/joke]

what i don't like in XC8 is the linker, it's prone to fail when there is less than one code page available and it still doesn't recognize code spaces that have been added in recent parts (the memory access partition feature) but hey, every version has a small

Ah yes, I had a project that needed that too.  I think it was using the pro version, as my company at the time wanted to port an existing product from 8051 to PIC and bought "the good tools".  (as you should at that level)  Even so, it was quite a challenge to convince the linker to put this here and that there, keep all of this empty, etc.  According to the (lack of good) documentation (at the time at least), it really wants to just do what it wants and say, "See?  Your code is 'running' just like you said!"

Adding to the challenge was the need to field-update the entire program, without a chance of bricking it (from the customer's perspective), when the fully-optimized binary was already more than half of Flash.  I ended up with kind of an odd architecture, with multiple partial downloads, the "bootloader" never fully releasing control, and the application being more like an Arduino's init() and loop() functions where loop() doesn't contain the loop but is instead called once per loop from somewhere else, etc.  But it worked!

...and then our 8051 supplier told us about a new chip that would significantly undercut the PIC again ("You couldn't have told us sooner?!"), so we didn't actually sell my version.    Oh well, they did say I could take the PIC code home and use it, so I guess that's a plus.

[cv007]

but I'm not quite clear on this

Is saying just use xc8 since its current and supported. No need to seek out another compiler for a pic16/18, xc8 will work just fine. If you have mcu's that can use gcc, then that is nice as you then can also use c++ and will have a toolchain that will be familiar when moving from one mcu to the next. The pic16 you have now is the newer series and has some nice features, so just make it do what you want using xc8.

Here is a simple example using the newer pic16-
https://github.com/cv007/3DigitLed
and there was nothing about xc8 that was a hindrance.

I also created the same project for an avr tiny416 (newer avr0/1 series), where I used c++ (gcc). The end result was the same, the code is a little nicer since c++ was in use but when the device is finally doing its job it makes no difference.

Just start using your pic16 curiosity board, making it do things, which is the end goal. Eventually you will get another board with a different mcu, and do the same. Repeat. The things like ide/toolchain/programmer are the obstacles in between your mcu and your end goal (mcu does something useful), and you just have to get your hands dirty in that middle layer, where nothing is perfection.

[hans]

"Unmantained" simply means that no one is changing it.  What's already there still is what it was when the last person touched it.  It may not be perfect, but if it's still better for the same price (free), use it.

I can't debate IF SDCC is better than XC8. No experience. But from my personal experience with XC8, I tend to believe it.
However, I do have doubts about planning to use unmaintained tools. They can work today, break tomorrow for all I know, and it's unlikely to be maintained or fixed. Also, how are new parts going to be supported? Because I don't think you will want to keep using the same PIC parts for the upcoming 10 years.

I didn't know about the Linux driver for PicKit.  I must have missed it, or it must be a new development, or maybe it only supports the older ones while I have a newer one.  Anyway, the thing about tweaking udev rules is also something I have experience with, for a different project, and it's not particularly pleasant.  I still prefer an independent GPIO-based programmer for the Raspberry Pi: https://wiki.kewl.org/dokuwiki/projects:pickle

Read the documentation of course, set it up like it says, and it "just works".  (at least it did for me)

The vast majority of Linux (desktop) uses are no more customized than Windows is, and there are tools built into the GUI package (no matter which of several you end up with) to do just that.  No need to go fumbling around the internals.  If you do, then DavidAlfa has a point, but it's the exact same for Windows too, so... 

Technically speaking, you don't use a 'driver' for a PICKIT. As in, a kernel driver, that is. The purpose of udev rules is to handle device events, and very often those events are used to make USB devices accessible by any user in user land. Otherwise you would need root access to do so.

If the kernel doesn't have a driver for a particular device, it doesn't understand what to do with it, yet still enumerates the device and makes it available in the system for general communication. By using a library like libusb, any program can directly talk to USB devices as if they were a "driver": an user-space driver as it's often called. These drivers aren't installed into the kernel, but rather the protocol is baked into MPLAB or other programs that access the PICKIT.

The advantage of this is that every user-land program can do whatever it wants with it, in it's own way. For example, it's trivial to send commands to a PICKIT2 using a python library, and then the next second use the PICKIT2 in MPLAB again.

Technically you can do the very same things in Windows, but in order to use libusb to talk to a specific device, you need to swap out the USB driver for a generic libusb one. This driver only does enumeration and then leaves the device alone. This would work great with a PK2 Python library, but if MPLAB expects the PICKIT2 to use Microchips custom driver, it may not be so happy to work with it anymore. And reinstalling drivers and replugging cables gets tiresome real fast.

In my experience, the degrees of freedom on Windows is almost a complete subset of the degrees you have on Linux. The only exception is particular programs that are only on Windows, for example, the PICKIT stand-alone utlity, older MPLAB IDE, etc. But perhaps I'm also a bit biased as a long time linux user

[hli]

I didn't know about the Linux driver for PicKit.  I must have missed it, or it must be a new development, or maybe it only supports the older ones while I have a newer one. 

AFAIK MPLAB has always supported the current PicKit (and the previous one, to a certain degree) under all OSes. I'm using Linux for more than 10 years now exclusively, and never had issues. Yes, there are no _kernel level_ drivers, but MPLABX (the IDE, and the programming tool) always worked. Yes, a too-old MPLABX will not work with a too-new PicKit (and vice versa), but that the same under all supported OSes as well.

[hli]

I love how Linux guys always use diminutives, "some", "little" "a bit"... which in the great majority of cases means "a lot", "take the poison", "search for a window in the 27th floor" 

Well the tweak actually was just changing something small (this was a year ago, I forgot the details - with a current MPLABX it worked out-of-the-box). And when it would have been a 'you need to install 10 additional packages and spend one day configuring the system' I would have called it that.
I guess you do like Windows more than Linux - but there you need to rely on the software (and hardware) vendors to support the combination of tools and software you currently need to work correctly. If not, go looking for something else.
In a computer system the are always moving parts - there is a newer PIC you want / need to use, then you need a new PicKit / ICD to program it, which needs a new MPLAB, and there you go. Or there is a new OS version which you want to upgrade to, and the you need to hope that its changes will not affect your software (or hardware devices).
Yes, you can keep all in a single state, and then you will not need any tweak anything, but it also means you cannot do new things. And thats the same for Windows as for Linux. (and you need to hope your computer is not connected to the internet, because then there will be someone finding a new way attacking all computers, and you are back to the moving parts
The difference between Linux and Windows is that under Linux you can do the tweaking in case the vendors does not help you (and under Windows you just go, looking for that windows in the 27th floor for the computer to be thrown out). Unfortunately it is needed more than I would like, because vendors do not support it as well as they could. Its getting better though.

[seamusdemora]

If you are using 8 bit I would use one of the new AVR chips, clearly they are good or microchip would not be coming up with new ones although they stuffed the naming right up. And yes objectively we know that the AVR is 4 times faster than the PIC, why use old designs?

Makes perfect sense - except for the 16F15244 I've already invested in. . But that's not a concern - if the AVR parts are superior, I'll be better off in the long run. Since AVR is owned by Microchip, isn't the development environment the same as for PIC?

I don't think my application is resource-intensive: I want to use the AVR/PIC/Whatever to manage power for a solar-powered Raspberry Pi project. I thought initially I could get the Pi to manage itself, but that's gotten out of hand. There's a DS3231 RTC, comparator, one-shot, etc. I want the uC to control the RTC (i2c) to set the alarm, service the interrupt, actuate the power switch (a latching relay), and monitor the battery voltage. I do need x-low power consumption... well, that's probably best addressed in a new question?

Thnx,
~S

[AaronD]

...the protocol is baked into MPLAB or other programs that access the PICKIT.

The advantage of this is that every user-land program can do whatever it wants with it, in it's own way. For example, it's trivial to send commands to a PICKIT2 using a python library, and then the next second use the PICKIT2 in MPLAB again...

AFAIK MPLAB has always supported the current PicKit (and the previous one, to a certain degree) under all OSes. I'm using Linux for more than 10 years now exclusively, and never had issues. Yes, there are no _kernel level_ drivers, but MPLABX (the IDE, and the programming tool) always worked. Yes, a too-old MPLABX will not work with a too-new PicKit (and vice versa), but that the same under all supported OSes as well.

That might be what I was thinking of.  It requires MPLAB specifically, to use a PicKit.  No other IDE knows the protocol, and AFAIK there's no standalone command-line utility either.  Yes, MPLAB is free and runs everywhere, but I really like to have the same IDE for everything if I can get it.  So far, I've settled on Code::Blocks.  Thus, my PicKit doesn't work.

Any command-line utility should work with any IDE, either as the compiler itself, or as a pre-build operation (gathering required resources), or as a post-build operation (distributing the binaries and/or programming the chip), or as a user-triggered "whatever" (also programming the chip, if you'd rather that be explicit like I do).  XC8 is, so it's possible to use that in Code::Blocks or any other IDE, but AFAIK the PicKit "driver" isn't anything beyond MPLAB itself.

[seamusdemora]

If 'gcc' is a btter choice for 8-bit platforms, where can I find that?

GCC doesn't work for PIC.  It does work for AVR.  Different instruction sets.  One is designed to be "C-friendly", so it's easy to port GCC to it.  The other is "silicon-friendly", originally meant to be programmed only in assembly (as I understand), and backwards-compatibility means that it can't change now.  It works so much differently that a GCC port to that would cease to be GCC altogether.

OK - Did not know that, but it's important!!