is it worth the hassle of learning a new uC platfrom

[danmcb]

hey guys,

I've used PIC's ever since they first came out, back in the 80s - back then they were giving away compiler and simulator programs  (DOS based) and I've used them a fair bit when I have needed a microcontroller solution. They have their good sides and not so good, but for me they've always been "good enough".

But recently I got interested in an ARM STM32 for design I am working on, and decided it was worth picking up a cheap dev board and dipping a toe in. The spur was really some advanced features they have for PWM control (which I learnt of here) and the fact that someone I know and respect uses them a lot on his products.

Of course there is a learning curve to a new toolchain/platform. I am wondering if one family has that significant benefits over another. (Of course, from an employment aspect it's always good to have more arrows.)

Not interested in any kind of holy war about uC families, but interested in informed opinions from people in a position to make educated observations (i.e. with experience of both, and perhaps other, families.)

Thanks!

[rstofer]

I have used the PIC 16Fs quite a bit and they are a nightmare for C compilers and writing assembly code, worrying about the memory architecture, is a huge PITA.  OTOH, when you need some little bit of uC to make something go, PICs can do the job.

Next up, of course, are the AVRs.  The architecture is much cleaner and C compilers abound.  This can also be expanded to include the Arduinos which is nothing more than an ATmega328P with a supplied library.  The board can be used without the library code and yet retain the bootloader - a handy feature.

In my view, the next up is the mbed and, in particular, the original board with the LPC1768.  I like the online toolchain and I use the provided networking library.  The chip is FAST, has a bunch of memory and it's easy to build the stamp form-factor board into a project.  I like ARM chips and have spent quite a bit of time with the LPC2106 and LPC2148 (more or less entry level in terms of peripherals).

These days we're moving up to the ARM Cortex M4, I suppose, and the ST product line dominates (for no particular reason) and the STM32F4xx is pretty slick.  What I have a problem with is the supplied code.  It is just too clever by half and difficult to avoid.  All I really want is a simple .h file that defines the peripheral addresses and leaves me alone.  But, no, I'm almost forced to use CubeMX to lay out the hardware and create the code files.  You wind up using a truly bloated infrastructure just to get started.  I'm trying to like the boards (actually the libraries, but it's difficult.  The learning curve is not only high and steep, it seems to be obscured.  I'm not a happy camper...

So, I ordered one of the TI Stellaris Launchpad boards and it should be coming in any day now.  We'll see...

In any event, the current chip selection will be ARM in one flavor or another.  Wander over to mbed.org and see what works with their infrastructure.  They have the original board, of course, but there are a number of other boards including some of the ST products - particularly the Nucleo line.

ETA:  Yes, it is definitely worth moving away from the PIC 16Fs.  Almost anything is easier to work with.

[JPortici]

It's always worth learning new families.
Just to stay with microchip, dspics are always underrated. really, with dspics you can give the middle finger to many ARM chips (- cortex M0 of course -), the peripherals are mostly amazing

Now i'm learning PIC32MZ, just to find out i'm liking it way less than i tought i would... but still, way more pleasant than all my experiences with STM32 (peripherals are the same as dspics, which are almost the same as new pic16/18 so setting it up is easy peasy)

then i dabbled with some flavours of Cortex M chips.. stm, nxp, atmel, silabs. they all suck to some degree compared to a good old pic, in terms of ease of understanding of datasheets and peripheral libraries.. some more, some less. But every one has its uniqueness that means that i can design a better product if i need to.

PSoC and TI controllers are on the todo list but i have yet to find a use for them.. but yes, to answer your question it's always worth to learn something new. you open yourself to new paths meaning you can do a better job and grow. you also make yourself more valuable

EDIT: Re:arm i avoid STM if i can, the documentation is just a mess for my point of view. If you discard the peripheral library and do direct register access you can get into peripherals not working because documentation is unclear. They also come in too big packages with too little memory options. pic32 can have a huuuuuuge amount of memory.
I had much better/rewardubg/relaxed experiences with NXP (which has code examples in the datasheet! also better memory selection and very interesting parts.. check out the dual core LPCs) and ATMEL (designing a product with ATSAM C21, Peripherals are too simple, but it's just too pleasant to use. the peripheral library is also so easy and intuitive to use, bravo ATMEL!)

[jnz]

No. Don't ever learn anything new. - Life Lesson




Yes, specifically, and in my experience, it was WELL WORTH dumping PIC 8bit for ARM 32bit. I'm paying less per chip. The peripheral control is through the roof higher. I find them no harder to program for at all. The tools and community support is much higher. The number of options that moving to ARM has opened up makes me pissed off I stuck with PIC for so long. Microchip has some good parts, but I can't imagine why I'd waste a single second with their micros anymore, even the PIC32, compared to ARM all it gets me is vendor lock-in.

I just wish I had moved over in 2009/2010.

EDIT: I suppose there are small exceptions... Like EXTREMELY SMALL micros, PIC I think still has a market, and some cheap motor control stuff. But general mirco, it's clear regardless of personal feelings - The industry chose ARM.

[danmcb]

excellent feedback people. Many thanks.  Keep 'em coming ;-)

[Sal Ammoniac]

I make it a point to learn at least one or two new platforms every year. Not so much for work, but just the intellectual enjoyment I get. Last year I learned the TI and Freescale ARM Cortex-M parts. This year it's the Infineon XMC series and the ARM Cortex-A series. The Renesas RX600 and the Infineon TriCore also look interesting.

[nctnico]

IMHO moving away from the 8 bit PICs (and the other ones as well) is a good idea. TI's MSP430 is a nice architecture. Personnally I'm always using ARMs from NXP's LPC series. The advantage is that NXP re-uses many peripherals so it is easier to jump from one microcontroller to the other based on the requirements of the project. I don't think I'm using a particular LPC ARM controller in more than two products. I wouldn't fixate on price too much unless you are going to design a really high volume product. Going for the cheapest chip usually means wasting time on crappy peripherals and no forward/backward compatibility in the peripherals.

[ali_asadzadeh]

The Future is Cortex M, you should sooner learn them,you have about 4000 different MCU's from different vendors, now compare your options with PIC    The top players in this filed are ST(about 1000 devices) , NXP (600 devices) ,Cypress(450 Devices), Nuvoton(400 devices) and silicon labs(400 devices) ,Texas instrument (350 Devices)... and so on, and do not forget you have RF enabled ones like Nordic semi too

[danmcb]

well, as I have already a cheapo STM32 dev board, and have setup the tools, I'll press on with this. An old colleague of mine uses them and likes them. Sucks that register level stuff is sometimes badly documented as someone said (never had an issue with this on PICs, actually I find their chip-level documentation really good) - but will use the cube approach anyway (also at the advice of my old mate).

For the rest - well, I must say I've not had much hassle with PIC's. I've never had issues withe the stack architecture, using MC's own compiler and tools. My apps have typically not been *that* complex though. I probably *could* find a dsPic or similar that would do what I want for this project, but - well, it's good to learn something new, indeed.

[brucehoult]

The Future is Cortex M, you should sooner learn them,you have about 4000 different MCU's from different vendors, now compare your options with PIC    The top players in this filed are ST(about 1000 devices) , NXP (600 devices) ,Cypress(450 Devices), Nuvoton(400 devices) and silicon labs(400 devices) ,Texas instrument (350 Devices)... and so on, and do not forget you have RF enabled ones like Nordic semi too

There's no doubt that ARM and Cortex M/A is the present, and the near future ... but I think it's worth keeping an eye on RISC-V as it's getting quite a bit of support from big names as it moves out of academia into industry.

- free and open license-free instruction set, similar in spirit to an improved MIPS. Inherently supports 32, 64, or 128 bit implementations. All standard instructions are 32 bits long, with optional standard Thumb2-like extension with 16 bit instructions duplicating the most common 32 bit instructions (gives ~30% code size reduction). Instruction set is designed for customization with plenty of room for vendors to add 16 bit, 32 bit, or longer instructions.

- supported by gcc, binutils, glibc, newlib, linux kernel, qemu

- Berkeley university has released three free and open core designs, roughly at Cortex M0+ (Z-scale), Cortex A5/A53 (Rocket), and Cortex A15/A72 (BOOM) complexity/performance levels. In fact they are all implemented as core generators, rather than fixed cores, with many aspects configurable (and they all share much of the same definition code).

- anyone can use Berkeley's cores or core generators, customized or not, or design their own from-scratch cores. This is in contrast to ARM, where Apple, Samsung, Qualcomm and a handfull of others have paid big big bucks to ARM to be allowed to design their own cores, but everyone else has to use off-the-shelf cores that ARM designed.

- roughly 40 companies are known to be working on CPUs and SoCs using RISC-V.

- SiFive, a startup founded by Berkeley people who designed RISC-V, have a 32-bit no MMU no FP microcontroller SoC that runs anywhere between 16 and 320 MHz in production. At the moment you can only buy it on their "HiFive1" Arduino-compatable development board. Later this year they expect to have a linux-capable quad core 1.6 GHz SoC and dev board. Their main business plan is to design and fab custom SoCs. They say they can add your peripherals, special function units, custom instructions, and get you the first wafer of sample chips for typically under US$100k.

There's no doubt that ARM does a very good job, their standard cores are good and the license fees are not huge. Thee are, as you say, thousands of MCUs available using them. It's a different matter if you want to customize the CPU core or build your own. And their 64 bit offering is incompatible with 32 bit and has much bigger code size (no Thumb equivalent).

But worth keeping an eye on RISC-V.

[Kjelt]

Learn Arm32 is getting up to par with todays developments in uC.
The difference between ST, NXP, TI and others are the perihperals, they are what makes them unique, you like the one you might hate the other, just have a look around what fits you.
The biggest selling point of ST for businesses is probably not important for you, price. Besides that ST offers per device package a lot of different amounts of ROM and RAM. So if youre code outgrows your device in ROM and you don't want to redo the pcb then ST is your best best. That said if you pick the biggest chip available from NXP your set as well.

[AndyC_772]

ETA:  Yes, it is definitely worth moving away from the PIC 16Fs.  Almost anything is easier to work with.

Wow, that's the first time I've heard anyone say that. I use 8-bit PICs when I specifically want something that's quick and easy to use, not the other way round.

More often than not, I also use PICs when I need a device that operates at 5V and 125C+, which are common requirements in my particular line of business, but probably not relevant in most other applications. Show me a similarly robust Cortex-M0 and I'll bite your arm off (pun intended).

Learning a new MCU architecture, and the tools that support it, takes time and effort. If you're doing this stuff for fun, and you enjoy it, then there's no reason not to switch families from time to time.

If you're up against a deadline and have customers expecting product, then it's slightly different. Sticking with a device family that you know you can get up and running quickly, and where you can be reasonably sure there won't be quirks that make the prototypes flaky and unreliable, may well be a good idea in practice.

For example, I use Altera FPGAs exclusively. I know how to configure them, what their quirks are, the things they can do easily, and the limitations which apply. I can be 99.9% confident that any new PCB I design using one will boot up OK, and that I'll get it working in a reasonable time. I know the synthesis tool, the simulator, and the internal peripherals which are useful to me.

I could switch to Xilinx, or maybe Lattice, but I'd need a compelling reason to spend the time. Are they half the price? Do they have a wider range of package types? Is there some awesome feature I never knew I needed? Maybe. But so far, I've yet to come across an application that justifies the cost and risk involved in switching.

[nctnico]

ETA:  Yes, it is definitely worth moving away from the PIC 16Fs.  Almost anything is easier to work with.

Wow, that's the first time I've heard anyone say that. I use 8-bit PICs when I specifically want something that's quick and easy to use, not the other way round.

Rstofer wrote this in the context when using the C language. Archaic architectures like the 8 bit PICs and 8051 become a major pain in the ass quickly because they have several seperate memories. And there is also the issue with limited processing power on these 8 bit devices.

[Kjelt]

Learning a new MCU architecture, and the tools that support it, takes time and effort.
If you're doing this stuff for fun, and you enjoy it, then there's no reason not to switch families from time to time.

For example, I use Altera FPGAs exclusively.................... I could switch to Xilinx, or maybe Lattice, but I'd need a compelling reason to spend the time.

Yup the 8bitters microcontrollers have and keep having their application. If it is a relatively simple project, not too fast (<100kHz) not too many simultaneous actions etc, they have their right for existence.
That said, the world is changing, no way an 8 bitter can be a real IoT device with ethernet connectivity without a much more expensive copro doing that task.

So to keep in your FPGA example domain, there are Altera cplds for $2 that have their market and there are Altera FPGAs for $1000 (maybe even more i did not keep up) that have their market.

In embedded uCs there are roughly three seperate markets:
8 bits 
32 bits  ARM Cortex Mx based where the M0 is entry level, M3+4 are medium and M7 and up are highest level (and cost)
singleboardcomputers : like the raspberri pi, beaglebone and sorts

Now the new ARM M0 devices become ultra low power, high performance (relative to 8 bits older designs) and equal cost as 8 bitters, they are slowly but firmly pushing the 8 bitters off the table.
I would not be surprised if in 10 years time no silicon manufacturer will produce 8 bitters anymore , but that is a bit wild speculation.

[jolshefsky]

I thought I'd refresh my memory about the OP:

But recently I got interested in an ARM STM32 for design I am working on, and decided it was worth picking up a cheap dev board and dipping a toe in. The spur was really some advanced features they have for PWM control (which I learnt of here) and the fact that someone I know and respect uses them a lot on his products.

It's not clear if the project can even be accomplished on an 8-bit microcontroller since the OP's looking at the STM32 line.

PIC was my first choice as well, and fairly arbitrarily selected (it happened to be an offering from the early years of SparkFun.) I've found the documentation to be thorough and correct at nearly 100% of the time (I'm still having some trouble with EEPROM programming on a PIC12F683*). From what I've seen in other people's comments, these are the best datasheets around. I could spend some time poking at other architectures, but in the 8-bit world, I gather it's a pretty lateral move and no big advantage to any one company. From what I've seen, MicroChip has consistently maintained their PIC lines, so that is one other advantage—that the chip you're developing won't suddenly become unavailable in 5 years.

Outside of 8-bit, though, all bets are off, and I'd definitely move away from PIC to get better development tools (e.g. the thoroughly tested compilers and libraries.) Once you're moved into the world of memory management and multiple threads (even before you'd need things like Internet connectivity), you need those better tools. I would wager that is the single most important factor when you need that level of computing power. In other words, if you don't need a lot of computing power, you can start your design with things like power requirements and form factor, but once you leave the simple computing world, the development tools become the dominant design constraint.



(* I get the whole secret handshake approach and that seems to work, it's either a very weird bug in my code or there's something very weird going on that causes 0x02 to get written, seemingly at random, sometimes.)

[danmcb]

I thought I'd refresh my memory about the OP:

But recently I got interested in an ARM STM32 for design I am working on, and decided it was worth picking up a cheap dev board and dipping a toe in. The spur was really some advanced features they have for PWM control (which I learnt of here) and the fact that someone I know and respect uses them a lot on his products.

It's not clear if the project can even be accomplished on an 8-bit microcontroller since the OP's looking at the STM32 line.

It probably *could* but getting a bit towards the stress point. I made a proto buck regulator with a combination of stripboard and and old PIC dev USB board which has an 8 bit PIC on it. Worked fine, there is a PWM output with deadband control that I could use to create a synchronous rectifier. I didn't get as far as monitoring op voltage/current and doing the feedback side, but i think it should have been OK. The issue thoigh was resolution - the PWM o/p was a bit lacking in bits. Then (thanks to another thread here) I decided to do bulk charging on the Li-ion pack, but incorporate cell level monitoring - to be able to do directly measure each cell with enough accuracy, you start to need 12 or 16 bit ADC's, and the PIC has 10 ... etc. OK, the signs are it is time to move on.

Right now I am getting set up with the STM32F334 Discovery board, and getting used to the free TrueStudio env, which seems fine. For a while I was building cde which loaded but raised HW errors as soon as I tried to debug, but that seems to have stopped now (not sure what caused it). Now learning how to define and build a simple Cube project for this board, with the Atollic tutorials. It's another world. I must say I am not that crazy about having the h/w code buried in 3 or 4 abstraction layers, but I can see that once you get used to it, you can be very productive.

many thanks to all for the general help, prodding and so on.

[JPortici]

have you checked out microchip's app notes on SMPS using -recent- 8 bit pics?

[danmcb]

no I haven't seen them. do you have a link? thanks.

[Kjelt]

There are now 8 bit uC that have extremely fast TimCompare peripherals actually more hardware statemachines (almost as fast as hardware) esp made for power applications.
Example take a look at the STM8Lux the IDE and Cosmic compiler are now free (paid for by ST) .


http://www.st.com/en/power-management/digital-power-control-drivers.html?querycriteria=productId=SC640

The innovative SMED (state machine, event-driven) digital technology and the integrated microcontroller make STLUXTM easily programmable and versatile. It can be configured with application-specific algorithms to optimize the overall system efficiency, enabling high-performance and cost-effective lighting design.

SMED is a hardware state machine triggered by internal or external events. In power-supply applications, for example, a SMED can close the regulation loop and automatically switch off the circuit when it detects an overcurrent or a short circuit, so protecting the circuit. Since SMEDs are embedded, they guarantee an event reaction time shorter than that provided by standard interrupt-driven microprocessors.

[JPortici]

no I haven't seen them. do you have a link? thanks.

for example:
http://ww1.microchip.com/downloads/en/AppNotes/00002122A.pdf
http://ww1.microchip.com/downloads/en/AppNotes/00002039A.pdf
http://ww1.microchip.com/downloads/en/AppNotes/00001978A.pdf
http://ww1.microchip.com/downloads/en/AppNotes/90003103A.pdf
http://ww1.microchip.com/downloads/en/AppNotes/90003104A.pdf

the PIC16F17xx series:
http://ww1.microchip.com/downloads/en/AppNotes/01468A.pdf

[Kjelt]

The problem with uC driving digital SMPS is that they need an ultrafast mechanism (faster than interrupts) to respond to spikes, shortcircuits etc.
You do need a hardware statemachine for that OR handle the error situations in additional hardware (extra cost).

[nctnico]

IMHO you should always do SMPS protection in hardware just in case the microcontroller decides to get a life of it's own.

[technix]

You can try learn 7 architectures at the same time. For example 8051 + AVR8 + PIC8 + PIC16 + PIC32 + ARM Cortex-M + ARM7TDMI. Very quickly you are going to find patterns, getting very good at writing architecture-independent portable C code, appreciate stdint.h and start accumulate your own middleware.

[nctnico]

You can try learn 7 architectures at the same time. For example 8051 + AVR8 + PIC8 + PIC16 + PIC32 + ARM Cortex-M + ARM7TDMI. Very quickly you are going to find patterns, getting very good at writing architecture-independent portable C code, appreciate stdint.h and start accumulate your own middleware.

With the architectures you have listed that is impossible. The 8051 and PIC8 don't work efficient with pointers so you need to adopt an entirely different (poorly maintainable) coding style to get some performance.

[technix]

You can try learn 7 architectures at the same time. For example 8051 + AVR8 + PIC8 + PIC16 + PIC32 + ARM Cortex-M + ARM7TDMI. Very quickly you are going to find patterns, getting very good at writing architecture-independent portable C code, appreciate stdint.h and start accumulate your own middleware.

With the architectures you have listed that is impossible. The 8051 and PIC8 don't work efficient with pointers so you need to adopt an entirely different (poorly maintainable) coding style to get some performance.

I honestly don't use those a lot. My projects calls for AVR or ARM Cortex-M most of the time. (Although there are some niche for PIC16F1455, a USB-capable MCU available in DIP-14 package)