Also the way some peripherals are setup isn't helping. Compare the complexity of the clock distibution of the LPC1700 versus the STM32G0; the latter is much more complex while adding very little in terms of functionality. Or take the ADC for example. On NXP LPC series, each channel has it's own conversion result register so you can let the ADC sample inputs freerunning and read the value when needed.
If you're counting microamps, the clock distribution complexity is surely handy. I have a project where the clock distribution is a PLL off of 32kHz to 24MHz, and that gets PLL'd to 144MHz. The CPU clock speed is then completely variable based on workload, while peripherals run off of a fixed 4MHz clock. All this crap might seem unnecessary until you actually need low power and autonomous peripherals. Regarding ADC, I agree the ST implementation is a bit of a pain, but it's generally quite workable.
Hans, SiliconWizard, Siwastaja: Thanks for so much insight into the pros and cons of NXP/STM, kinda scary how much hassle one could have to deal with docs.
There can be something so elementary and simple as not turning on misconfiguring a clock or dealing with DMA reg bit.
The devil is in the details. I see it can be so hard to troubleshoot because it can b so hard to find the right page.
Too easy to not RTFM to finally find that demon one single reg, the miss set one bit of a reg, finding the one line of code that is missing, misplaced and misconfiged and messing up the MCU from working.
Returning to the original subject, by far the easiest upward migration from PIC8 is PIC32.
Same hardware tools, same IDE,same datasheet layouts
and many peripherals are supersets of the PIC8 ones.
Peripheral pin mapping is the only major additional step, though if you're using fairly recent PIC8s you'll already know about that
Once you've set up the config fuses you rarely need to worry about clocks, only if you're doing stuff like audio or usb.
I don't see the feared clock thing a big issue, at least in STM32. If you buy the simplest STM32F0 or something, it doesn't have this complexity. If you buy higher end devices, it does, but it boots with good default settings with internal RC oscillator, so you get started no problem. Only when you start having CPU performance requirements and need to go to higher clock frequencies, only then you need to start looking at the clock configuration. And it's still <10 LoC.
Unlike a lot of the other people responding to this post who are comparing ARM with PIC, I have used LOTS of NXP LPC devices (modern to old). I've also used STM32s, Atmel AVR32s (when Atmel were real) and STR7 devices amongst a smattering of other devices including the TM4C range (formerly Luminary Micro, also used them as LM) and TMS470s and even the... can't remember what it's called, is it MSP430s?
Of all of these (yes even including the TI devices!) the LPCs were my least favourite. Their datasheets appear simple but are so simple they don't include all the information you need. The website is frequently down. The internal peripherals across various families in the range are old fashioned. The DMA controllers in all the devices I used were so bad (inflexible) that it was (orders of magnitude) quicker to not use them! And I experienced issues with RTCs that I didn't expect to experience; I still can't tell you more about those! The driver libraries are also a bit of a pain. They tend to focus on runtime code rather than compile time macros so are quite slow. They're suppose to be relatively common between families but in practical terms, aren't though they are fairly well documented. MCUExpresso is also pretty terrible. I would edge towards Keil or similar alternatives for building code even if there is a cost associated.
So, specifically relating to NXP, I would avoid. ARM is a bit of a leap in functionality but for performance hungry code is worth it. It's much easier these days since the Cortex processors now include the interrupt controller. On the ARM 7s these were unique to each manufacturer! As a result it's fairly practical to write mostly portable application code, even if the low level code isn't easy to port. If your Microchip code is good, that will help.
If you any up with more specific NXP questions, I will try to do my best to make a comment.
Let's try PSoC4 or PSoC6 and PSoC Creator 4.4.
it is cortet m family but with a bit different peripheral stack, for example some uC have PLD (up to 128 macrocells).