NXP LPC series Better than an STM32 Which is EASIER/Better for PIC migration?

[SuzyC]

In a earlier similar posted topic, everyone ignored a suggested easier option to choose NXP over STM for an experienced PIC coder to first try to migrate..why?

STM bandwagon post: https://www.eevblog.com/forum/microcontrollers/from-pic-to-stm32/msg5107758/#msg5107758

Above Topic, According to user nctnico:
"May I suggest not to blindly follow everyone into STM32. Especially for a beginner, NXP's LPC series of ARM microcontrollers are much easier to get going with. Better (correct!) and clearer documentation, peripherals that are designed so that they are easy to configure and all of the controllers have a serial bootloader besides SWD. I have been using both and I'd take an NXP LPC series over an STM32 any day because the latter just take more time to get going."

[DavidAlfa]

Can't really tell as I never used NXP.
I have two LPCXpresso LPC1114 boards I got for free in 2010 or so, but never used them! (OMG how time flies!).
But no matter how experienced you are in PICs (Unless you did plenty of PIC32), ARM is a completely different architecture with lots of quirks, it's a steep learning curve!

[SuzyC]

I have not experienced great difficulty in first using Infineon 5V Vdd PSC4200 series of ARM, not much difference in getting things to work properly, just had to deal with the tiresome  necessity to download many datasheets for any peripheral/topic needed  to setup the PSC4200  MCU.  Having a break-off USB-->Serial bootloader module built-in on a PSC4200 developer stamp made breadboarding and programming seamless, so quick  and the programming is the break-off part  the stamp, so programming is free of charge.

What I dislike using MCU dev. bds is their size, while a stamp dev. board is sometimes small enough to fit into a small enclosure when soldered into/added onto a proto PCB. A  revised PCB after debugging/modifying, can then easily shrink the MCU into the smallest footprint size on the final board. With a stamp, I can quickly show a customer a working proto without a scary array of flying wires!
I have three large Arduino Mega2560 boards gathering dust because they are so damn big and clumsy to work with.

When I compare this with running through the prev topic showing a gauntlet to overcome using CubeIDE to get the STM device to blink a led, the Infineon was a piece of cake.

What I dislike about the Infineon is the dev. stamp cost, 20x more expensive than a STM on Allibaba. However, the Infineon part is now only a day away after being ordered from Mouser while Alli Bab's cheap part takes a mth to wait for.

What about the NXP?

[hans]

I think the statement was "ignored", because objectively its not true.

The most idiocracies I had when switching to an ARM CPU had more to do with the CPU instead.
For example, having to enable "power" or "clocks" to each peripheral before using it. Or having a 8-bit CPU nicely matches the smallest addressable data size in C, making it easy to program. A 32-bit CPU may introduce some gotcha's such as unaligned memory access and whatnot. Likewise, debugging HardFaults is also one of such things.
The longest bug I had to chase down took 1.5 weeks to find. It was on a LPC1768, but it had nothing to do with NXP's work: it was a bit we forget to manipulate within the ARM CPU core itself that led to stack problems.
etc.

And even if there are idicoracies with peripherals, in my experience its mostly to do with chip scaffolding (buses, memory, clocks, power, DMA) than individual peripherals. Its not like setting up a UART or SPI controller on STM32, LPC or PIC is going to make you jump through half a dozen hoops to make it work: a single pass through the peripheral registers is typically enough to make it to work. ST reuses their peripherals among chips and may add a feature here or there, but typically the "i dont care about this feature" => "keep the bit at zero" works, just like a PIC, AVR or any other sanely designed MCU.

Now that doesn't mean there are no issues with e.g. peripherals of a particular vendor.  STM32s for example (used to) have a frustrating to use DMA controller. The peripheral requests could only be mapped to a particular DMA channel, which could lead to conflicts. This "firmware driver work" is in actuality hardware design, similar to how you would allocate peripherals depending on e.g. I/O pad locations. Similarly, some internal signals only have a handful of options on STM32, while a more generic solution would be needed.
Other vendors like SiLabs and Atmel have tried to find solutions for this with PRS and alike, which were easy to use, however, for some of these chips the silicon itself may not tick all the boxes. E.g. if you need industrial peripheral set (many CAN buses), then you probably skip SiLabs offerings. If you need ultra low power, then you probably wont find many suitable options from NXP.

There just isn't a way to "have it all".

All these "easy to configure" aspects are similar for STM32s, LPC's, SiLabs, etc. I've yet to see any vendor to do things drastically different.
And the question is whether thats even possible or desirable. As soon as a vendor says something is "smart", then I can translate also into the terms of non-transparent, frustrating and a can of worms. Similar to how a software ecosystem is a design lock-in, or a "prison".

The reason I think PICs and AVRs have none of these adaption issues is because those chips contain very very little hardware. There is only so much to go wrong with a handful registers for an UART! And also only so many things to use it for....

Regarding documentation: I think all vendors try to do their best, but at one way or another will fall short. They cannot possibly list all possible configurations of their chips. I've been looking at an (admittedly old:rev2) user manual of the LPC1768, and I'm not that impressed. The DMA controller chapter is only 29 pages long, of which 22 is register documentation (e.g. some auto generated tables with some bitfield annotations). The chapter says the DMA controller has support for scatter-gather using linked-lists, but then doesn't mention it once in the remainder 7 pages. Its basically undocumented as the register listing doesn't specify how to use it neither. Probably better to mail their sales/app team on it works.. but that requires human interactions. Eek.

Now STM32 documents can be on the opposite side of an enormous amount of redundant 'blabla' and then (forgetting to) reference content from half a dozen other places in a 2000+ page document. But at this point I also get the impression that using those chips 'bare metal' is the non-mainstream way: many people use ST's HAL and CubeMX software to generate driver initialization code.
Which one is better? Again: can't have it all, pick your poison.

My point is: in the end these 32-bit ARM chips have similar complexity, and some chips may have more quality-of-life features in the silicon (such as remappable I/O) and some in the datasheet. Which one you like to use more is subjective and that's fine. I think this statement however has been repeatedly posted by this user. Subjectively speaking, such statement cannot be false, but I don't think its true neither.

[peter-h]

I've spent the last few years of my life on an arm32 (32f417) product. If you read through the many threads I started, you will get the idea

And I went from asm programming (decades of it) on the Z80/Z180 and similar chips to C on the arm32.

I'd say the hardest bits have been not related to the chip but to the fact that in modern times a product is 10% basic function and 90% connectivity, and the latter is so complex (TCP/IP i.e. LWIP, TLS, etc) that you have to use open source code for that which is often buggy, usually with no support, and is huge e.g. TLS at 200k is ~ half of my whole product! And yes I started a thread on the crap situation with open source code, too

If I was merely moving from a Z180 or H8 to the 32f417, I would have probably spent a week or two to get it going and then it would be downhill all the way. The chip is so fast that typical bottlenecks just disappear.

FreeRTOS integration is also easy enough (and highly desirable).

It is however true that in certain cases the open source code is supplied pre-integrated and the classic one is the ESP32 where Espressif paid some guy to package the whole thing into something that works fully out of the box. The downside? Chinese political risk, and doubtful production life (nobody is likely to beat STM, or Hitachi/Renesas, on production life). The chinese do not really care about shafting customers; their entire culture is opportunistic.

All that said, this project will be my last one in terms of hardware and software integration. I plan to use this as a base for all future products, and with 168MHz I am confident it will do everything I need.

[DavidAlfa]

If you read through the many threads I started, you will get the idea

Not wanting to be a jerk, but lot of those were due not doing enough RTFM  .
-Ahh so hard, so messy! -Read manual page 34 -Ahh now it all makes sense!!

[Siwastaja]

nctnico probably slightly exaggerates the difference in peripherals and documentation, but he's kinda right that STM32 documentation is messy. Nothing's perfect, though. I managed, from the very start. My biggest and only real hurdle was using a faulty linker script off the interwebz which initialized stack pointer aligned(4) when it needs to be aligned(8). Such small detail wasted literally hundreds of hours of my time. Wasn't experienced enough back then to find the issue quickly. Would have happened with any ARM MCU.

My recommendation is, use base GNU tools and any code editor instead of manufacturer software packages, and write register level code instead of wasting time on manufacturer libraries, probably just like you did with PIC. Then, mentally prepare / learn to surf through manuals (which you probably already did with PIC), and then you can pretty easily use any ARM Cortex microcontroller, enabling you to choose best tool for each job based on availability, cost, peripherals - whatever. No need to install anything on your computer when you switch manufacturers. Just RTFM and start writing code! A lot of it is directly portable.

In other words, "both" is not a bad choice. Whichever you choose, you won't go too wrong; better get started sooner than later.

[peter-h]

Not wanting to be a jerk, but lot of those were due not doing enough RTFM  .
-Ahh so hard, so messy! -Read manual page 34 -Ahh now it all makes sense!!

I don't agree. This is true if you already know it. Then sure enough you can find the bit in the RM which corresponds to what you already knew

But there is a whole new philosophy - like the above mentioned peripheral clock enables - and even those have gotchas
http://efton.sk/STM32/gotcha/g183.html

[DavidAlfa]

Ok I'll agree by a 50%. But not entirely!   

[SiliconWizard]

nctnico probably slightly exaggerates the difference in peripherals and documentation, but he's kinda right that STM32 documentation is messy. Nothing's perfect, though. I managed, from the very start. My biggest and only real hurdle was using a faulty linker script off the interwebz which initialized stack pointer aligned(4) when it needs to be aligned(. Such small detail wasted literally hundreds of hours of my time. Wasn't experienced enough back then to find the issue quickly. Would have happened with any ARM MCU.

Yes. Good documentation has some subjective sides to it anyway, but it is rare. I personally haven't found NXP docs to be any better than STM ones, but have not use the LPC series, only the iMXRT one. It isn't any clearer, and since the chips are more complex on average, it's even worse.

My recommendation is, use base GNU tools and any code editor instead of manufacturer software packages, and write register level code instead of wasting time on manufacturer libraries, probably just like you did with PIC.

Yep. As was discussed recently though, if you want something a bit easier to start on STM32, you can use the LL library instead of the bloated HAL, and go from there. At least they provide that, not all vendors provide a low-level library.

But investing time in understanding and setting up your toolchain and build environment, instead of relying on pre-digested vendor crap, will be time very well invested, as it will make migrating to different MCUs, much, much easier. You just need to bite the bullet.

I was a long-time PIC user (8-, 16- and 32-bit) and always used my own build environment. Having that experience, base tools and knowledge made migrating to ARM-based MCUs a snap, at least for the tooling.

And then I suggest reading some basics about the ARM Cortex-M architecture (if that's what you're heading to) just to understand the structure - the various internal busses, the typical memory map, and how clocks are gated to (almost) all peripherals and core features on these MCUs. Yes, failing to enable the clock to some peripheral is one common source of head scratching when you start with those MCUs (and it can bite you later on too.)

[SuzyC]

SiliconWizard, could  you please expand on what you mean by "always used my own build environment".
I am a pre-noobie STM/NXP coder. I know nothing about tool chains, do not know how to get my text editor C pgm somehow ported by some HW/SW path into these chips.

However, with the INFINEON PSOC4/5 ARM chips, composing code, compiling and using USB serial programming is a snap using the free PSOC Creator SW IDE.

With PICs, I always configured any peripherals myself from carefully RTFM and I manually carefully setup the "Special Features of the CPU" CONFIG regs.
Next, I would then compile using XC2x  in a DOS Shell to create an Intel .hex file.
Then, using my own custom software and custom HW on a breadboard with a ZIF socket, I am able to burn/verify/view the hex code burnt into the target chip, always using HV pgm mode using only the 5-wire power, DATA, Clk, Gnd, Reset/HVpgm pins. My SW/HW also pgms setting Vdd/Vpgm/Reset voltage levels while following all scripted timings during burning, and always in strict conformation to the applicable PIC12/15/16/18 Programming.PDF scripted routines.

I do use the PC RS-232 serial port on the PIC's with my own HW/SW to debug/examine MCU var vals on the project breadboard.

I never found it necessary to modify the Link script or modify a Make file.

I let the free PIC XC compiler in a DOS Shell to do all the heavy work to create an INTEL .Hex file with whatever level of optimizing is available and set F Pt math accuracy .   

But what exactly are the best steps..what does it take (without paying for special SW or HW) to get from an ASCII C source file into a NXP or STM chip using standard serial programing?

[dobsonr741]

If I were to migrate from pic to Arm and you are to make the learning curve I’d use platformio. So your code supposedly stays platform independent.

So you do not need to make to chose NXP vs STM32, you can hop from one to another with relative comfort.

[SuzyC]

Dobson741: Thanks for input, but I took a quick  look at Platformio and from what I saw, think it is just another way to retro back into Arduinoland and not learn how to master the use of STM or NXP chips while enduring a learning curve to learn and trust a rather beta level developed IDE.

[uer166]

Instead of mastering Arm chips of brand X, instead try to master reading of reference manuals/erratas, and direct implementation of stuff. That'll be transferable to any MCU and HAL you're gonna use, if any.

[peter-h]

Sure, but the learning curve is steep, and much detail is wasted on chasing details.

The STM Cube-MX project setup / code generator thingy works OK for getting started on simple projects, usually using one of their demo boards. It would be a mistake to use MX after that because you get so much bloat (the stuff called "HAL" mainly).

The Cube-IDE editor/compiler setup is pretty good nowadays. I would never go back to makefiles etc. After all, a lot of the compiler or linker command lines are huge. One little mistake and something breaks.

As I have often written, so much depends on whether you work for yourself, or you are a paid employee.

If the former, you will want to develop a multi purpose platform, usually with a higher-end chip than you immediately need, and repurpose that for ever. STM chips have long manufacturing lives so are good for that. Developing new technologies is needed like one needs a hole in the head. Common stocked parts, generic chips, etc, are the name of the game. If you can use an LM358, you use an LM358, 20 pence, not one of the 1000 other op-amps.

If the latter, then you will probably love every new chip, because it means job security. So many posts I see are from these people. It is also these people who specify most of the other 999 op-amp types and keep outfits like Linear Tech in business Well, a TLV2333 will fill in the precision requirements, etc.

[JPortici]

All my experience with NXP was with the LPC11U68, which i needed for a project with USB, CAN and something else
Bought the devboard, played with it, could bypass the whole HAL easily altough ISTR i had to use "api functions" to use USB because the driver was in a separate internal ROM... Meh. Drew the PCB, ordered it, soldered parts, the MCU would all fail within minutes shorting VDD and VSS pairs as soon as i plugged in the USB cable NXP support kept scratching their heads because the schematic and pcb looked correct to them

so i grabbed a PIC32MX and everything went on fine

which is too bad because i was trying to look around for new families but as of today i still use 99% microchip across the whole line

I wish you better luck. LPC parts are mostly boring, kinetis has some interesting offering IMHO (but interesting depends on what you have to do) and i keep courting them from time to time. The 8bitters as well, but as soon as either get FlexIO for timed GPIOs things get expensive pretty quickly

[westfw]

everyone ignored a suggested easier option to choose NXP over STM ... why?

Probably has a lot to do with all those $3-5 STM "Blue Pill" and "Black Pill" boards, and the "second sources" of some of the older ST chips (ie counterfeits and clones.)

[mikeselectricstuff]

A few comments based on 30+ years' experience of various  MCUs :

After having used various 3rd-party/homebrew setups (IDE, programing tools, debuggers) , I now just use manufacturer tools unless there is a very good reason no to.  Reasons include :
New parts will always be supported by the time they are available, as the manufacturer uses them internally
More users  = any issues more likely to get fixed.
Less hassle if you ever need to transfer the project to someone else, possibly including the manufacturer if you have an issue needing their support.

Do not use manufacturer libraries for anything less complex than USB/Networking.
It makes no sense to use libraries for trivially simple functions like I/O,UART, SPI,I2C etc. as they are very simple to use by talking to registers direct, and a manufacturer library will rarely be optimal for your requirements. You can easily spend more time learning the quirks and limitations of a library than learning the register functions

Peripherals like this are so similar between manufacturers (some use the same actual IP to implement them) that understanding how to use them is a more transferrable skill than learning a manufacturer-specific library.
If you understand what is going on at a hardware-register level you are in a far better position to figure things out when something doesn't work as expected.
Manufacturers libraries also introduce another layer of potential bugs - ISTR struggling with a NXP library function that didn't initialise a PLL as per the datasheet so it would randomly not start up correctly.

In some cases, manufacturer libraries can be terribly implemented, one I recall used iterative run-time calculation to generate clock divider values by trying every combination and choosing the closest.
They can also be nonoptimal due to having to support a wide variety of parts, including code to support functions not even present in teh device you're using

By all means use manufacturer utilities to generate initial register values, but check that the output is correct before baking values into your own code.

Read the whole section of the datasheet for any peripheral you're using. Trust me this will save you time in the long run.

..and of course  the core CPU DOES NOT MATTER 99% of the time- it's all about the peripherals

[Tation]

Start from the easy side of arm: a Cortex-M0(+) based MCU. At a first attempt avoid the low/ultra-low power variants, as sometimes their complex power management features may be confusing. Also, avoid (if you choose the STM path) usage from the very first day of the HAL (maybe you may want, in the future, to explore it). Select a board supported by some OSs and you have a nice long path of fun.

The LPCXpresso 11u68 board mentioned earlier fits all these. Cortex-M0+, 50 MHz, 256 kB Flash, 36 kB RAM, all basic peripherals (no DAC, though), DMA, supported by FreeRTOS, MBED, Zephyr...

Just select the development environment you want to use (I think this is a more complex decision than STM/no-STM. I'm a big fan of Keil uVision -albeit the editor seems, and is, outdated-) and enjoy.

[SuzyC]

Assuming someone is  using a win7 x86 PC, just what free software tool chain is to be downloaded after purchasing a STM dev board with an USB to get from a C source file to a chip ready to boot your program?
Would a few who know howto show their toolchain
Can you show where you got  toolchain components?
Show step by step from ascii source to ready to boot board as an example? (Is this a good choice??)

The likely STM boards I would purchase to start to learn with:

https://www.aliexpress.us/item/3256803272104771.html

STM32G030F6P6 Mini Development System Board Module
AKA  STM32G030 STM32 G030 MCU M0 Microcontroller Core Learning Board

Price $2.01 USD on Ali X + ship

[josip]

The likely STM boards I would purchase to start to learn with:

https://www.aliexpress.us/item/3256803272104771.html

STM32G030F6P6 Mini Development System Board Module
AKA  STM32G030 STM32 G030 MCU M0 Microcontroller Core Learning Board

Price $2.01 USD on Ali X + ship

Not this one, because it doesn't have reset pin exposed, and you should hold reset pin pressed to enable SWD master connection.

If you are looking for CM0+ with low price take RP2040 board for 4$. And another for SWD master.

My favorite is Kinetis K32L2B.

Whatever, take device with factory USB loader, so firmware can be easily updated over USB without any extra tools. On this way I started with KL27. Don't know about ST, but for RP and NXP there is prepared package for developing by Visual Studio Code.

[DavidAlfa]

The likely STM boards I would purchase to start to learn with:

https://www.aliexpress.us/item/3256803272104771.html

STM32G030F6P6 Mini Development System Board Module
AKA  STM32G030 STM32 G030 MCU M0 Microcontroller Core Learning Board

Price $2.01 USD on Ali X + ship

Not this one, because it doesn't have reset pin exposed, and you should hold reset pin pressed to enable SWD master connection.

Or just enable SWD in your app.

[SiliconWizard]

Assuming someone is  using a win7 x86 PC, just what free software tool chain is to be downloaded after purchasing a STM dev board with an USB to get from a C source file to a chip ready to boot your program?
Would a few who know howto show their toolchain
Can you show where you got  toolchain components?
Show step by step from ascii source to ready to boot board as an example? (Is this a good choice??)

All you need is the GNU toolchain, that you can get from there: https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads (easiest way if you're on Windows), and (at least to begin with) the support files from STM:
https://www.st.com/en/embedded-software/stm32cubeg0.html (I think it includes Cube, but you don't need to use that, there's also all CMSIS support files, the LL and HAL library that you can use straight without anything else.)

[westfw]

In my experience, the biggest problem faced by 8bit programmers when attempting to switch to ARM chips is getting the ARM into an initialized state similar to the simpler processors.
That can involve:

• Configuring a complex clock system capable of handling multiple internal and external clock sources, and probably DFFL and/or DPLL clock multipliers to get the "main" clock.  On a PIC, you connect a crystal and set a fuse. (The vendor libraries provide functions to do this, but they tend to be almost more complex than the clock system itself.  Grr.) (BTW, there is usually a default clock, so you might be able to get started without worrying about this, as long as you're OK with running much slower than the chips rated speed (typically 1 to 8MHz.))
• Routing and configuring the clocks for each peripheral you intend to use.  This can involve using a different clock source, or the main clock source plus a pre-scaler, or other weirdness.   8bit chips typically supply the main clock to all of the peripherals (and MIGHT have a prescaler that is part of the peripheral, rather than part of the clock system.)
• Enabling the peripherals themselves - sometimes this is separate from just enabling their clock.
• Routing peripheral functions to pins: there is likely to be some sort of pinmux controller, either as part of the GPIO registers, or off somewhere else.  If you want to use the pins for some particular function, you have the set the mux appropriately.  Sometimes the default it not even "GPIO."  On 8bit CPUs, frequently configuring the peripheral will "take over" whatever pins it requires.

After that, the next shocks are usually the use of structures mapping the control registers for a peripheral, rather than individual registers.  And then the sheer number of registers that seem to get created when you give a chip designer 512Mbytes of address space to play with (just for the on-chip peripherals, mind you.)


I don't THINK that any of these are avoided by any of the popular ARM chips (but I'm most familiar with ST and Atmel chips, rather than NXP.)


There was an interesting set of discussions here some time ago (9 years!), about the "minimum" effort one might need to start programming ST chips.  It resulted in https://github.com/WestfW/Minimal-ARM/ (which also has pointers to the discussions.)  Somehow, the idea of programming ARM in assembly language as a way of avoiding bloated toolchains didn't really catch on, but there were some interesting observations.

[nctnico]

I see a lot of people coming from ST (STM32) and telling that once you know it, it is easy. Ofcourse, but the road to getting the knowledge is either easy or difficult.  In the end everything is doable given enough time.

In the early days of ARM microcontrollers, my co-workers and I did an extensive evaluation of several ARM controllers out there and judging by how easy they where to get going coming from using microcontrollers like 8051, MSP430, H8/300, etc. The NXP LPC series (using the ARM7TDMI core) came out on top. In the past years I have also been doing some work using STM32 (mainly STM32G0) and I find myself needing to figure out things by trial and error and/or reverse engineering the HAL because either the documentation is missing essential details or just wrong. In many cases I just leave the bloated / generated HAL code in to save time. 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. Super easy. On the STM32G0, there is one result register so you are forced to use an interrupt based scheme AND keep track of whether you reached the end of the conversion in order to keep track of the channel you got the result from (in case you miss an interrupt or conversion). ST's HAL is just too bloated for things like a bootloader but trying to get the flash controller going by using the registers is cumbersome. How the pages are numbered c.q. divided isn't clear from the documentation and some bits auto-resetting (again, not documented) doesn't help either. On the contrary, NXP has a ROM API which deals with the internal flash in a very simple way without increasing code size. And these are just two examples out of many where I recall the learning curve for doing the same on NXP parts is less steep and thus it takes less time to get it going. Another big win for the NXP LPC parts is that most of the peripherals are the same across the entire range so code to control the peripherals can be re-used instead of spending time to figure out a different peripheral with the same function. Both means lower NRE costs and getting more done in less development time when using the NXP LPC series parts.

So for the OP, the best thing to do is simply get a few development boards for the various microcontrollers out there and just see what fits best.

[uer166]

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.

[SuzyC]

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.

[mikeselectricstuff]

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.

[Siwastaja]

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.

[MerlinEmbedded]

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.

[analityk]

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).