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)

[danmcb]

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

Well, if the thing is a battery charger (the battery being permanently connected), and the supply is a well-behaved 24V SMPS itself, and assuming you put in proper protection for hot-plugging and so on - where will those spikes come  from? I know that unexpected things can always happen in the real-world, but there is always a balance between keeping a circuit safe and paranoia.

I did a lot of simulations and so on, the biggest issues that suggested were ringing on startup, and variations in load and current. Particularly the charger needs *some* load to startup properly, but you don't want that to be the battery. So I decided on isolation FETs and a switchable resistive load that can be in circuit for long enough to get the charger up to the correct voltage. Maybe there are better ways of doing this,  but this is the best I could come up with at the moment. Open to better ideas of course.

I think h/w protection for over-voltage makes sense, for the rest, the uC should be able to deal with it.

[MAntunes]

Hi guys!
This year in two courses of my University Degree we started using microcontrollers and the professor chose the PIC24FV16KM202: http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=DM240013-2.
I think that they are quite easy to program with MPLAB X and it has loads of peripherals that are very user friendly. Of couse it also has its flaws. I've not mess with I2C or SPI yet.

Do you think that  it is worth to switch to an ARM Cortex-M (STM, NXP, TI)? For what I've seen thet seem more confusing to program, but maybe that comes with my habit to the PIC24F.

I mostly do motor control and sensor interface with them.

[Rerouter]

If your working on a project and your running out of reasources before feature creep sets in, its probably time to learn atleast a new more powerful flavour of what your used to, and grow from there.

e.g. try implementing a colour touchscreen on a atmel 328p, and you really cannot do anything for quite some time while it draws the screen, compare that to an arm which can DMA the screen from a memory in a much more reasonable time, with minimal input from the micro.

[brucehoult]

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.

Yup. The 8051 and PIC8 are fine if all you're doing is replacing something that you *could* do with a bunch of gates, latches, shift registers etc -- hardware.

They are not at all good if you want to write *software*, especially using modern practices. Or even C.

The humble old ARM7TDMI is a fine target for C and C++ with full 32 bit variables and big address space. The AVR8 is pretty good too, if you don't need too much RAM and you're mostly using 8 or 16 bit variables.

[rstofer]

Hi guys!
This year in two courses of my University Degree we started using microcontrollers and the professor chose the PIC24FV16KM202: http://www.microchip.com/DevelopmentTools/ProductDetails.aspx?PartNO=DM240013-2.
I think that they are quite easy to program with MPLAB X and it has loads of peripherals that are very user friendly. Of couse it also has its flaws. I've not mess with I2C or SPI yet.

It's when the device starts communicating with external peripherals that things get interesting.  Asynchronous events (in the case of slave SPI) take a little more work to program.  Typically it's a matter of grabbing the data during an interrupt and putting it in a queue.  Newer ARM devices will have a DMA channel with queue capabilities.

Do you think that  it is worth to switch to an ARM Cortex-M (STM, NXP, TI)? For what I've seen thet seem more confusing to program, but maybe that comes with my habit to the PIC24F.

I mostly do motor control and sensor interface with them.

The ARM Cortex M4s, for example, are FAST!  The STM32F407VG will run at 168 MHz, has 1MB of flash and 256 kB of RAM plus a WIDE range of peripherals.  Yet it's a cheap device at $12 qty 1 and $8 at qty 1000.  No, it's not a jellybean part like some of the PICs and AVRs but it is one heck of a uC.

I'm slowly coming up to speed with the STM32F4-Discovery board using ST's infrastructure (CubeMX).  In some ways this increases the learning curve, in others ways, it gets results early.  I'm still thinking about it.  My 32k limit with the limited IAR toolchain is getting eaten up fast with all the code generated by CubeMX.  I also have the Eclipse based toolchain when I run out of code space.

I like the mbed LPC1768 variant with the mbed online toolchain and libraries.  The libraries provide just enough hand-holding without becoming obtrusive.  I like the idea that I can just call up a library for Ethernet, write a bit of code for the top level and have a network connected uC with an hour's work.  Maybe less now that I know how to do it.

If you decide to play with the STM32, buy the book:
https://leanpub.com/mastering-stm32

The author gets you started from the very bottom, installing the free Eclipse based toolchain.  Just follow along and everything should work out well.

[MAntunes]

Thanks a lot!
This could be a nice project for next summer.
I was looking at the small Nucleo boards like the L432KC (low power) or the F303K8.. As they are cheap and look very capable!
That book seems to be very nice.

[ali_asadzadeh]

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.

Thanks for sharing the info

[westfw]

Do you think that  it is worth to switch to an ARM Cortex-M (STM, NXP, TI)?

One doesn't "switch" - one ADDS a new chip to their knowledge base.  That's always a good thing, IMO, assuming you have the time to do so.

A problem with ARM chips is that each vendor has their own peripherals, and a LOT of microcontroller programming is dealing with the peripherals, rather than with the CPU itself (especially so as you get into the more modern architectures.)  So if you spend a bunch of time figuring out the Atmel SAM3X (CM3) USART peripheral, that will be next to useless when you have to program a TI Tiva USART, or even an Atmel SAMD SERCOM.   Timers, USB, Ethernet, A2D are even more diverse...

You should definitely look at some 32bit microcontroller, anyway.  The way they throw address space at problems is sort-of mind bogglingly different from microcontrollers with a more limited address spaces, and is "interesting."   "bit banding: 16Mb of the address space is reserved for accessing 2Mb of memory/peripherals in an atomically bitwise fashion."   "Fast peripheral bus:  The XXX peripheral is available on the AHB bus at address 0xHHHHHHHH, and also on the FPB at address 0xABCD000, which is faster."

[danadak]

PSOC.






For me what stands out is -

1) Routability
2) Fast 12 bit SAR A/D and slow 20 bit DelSig
3) DFB (Digital Filter Block) that is dual channel, handle FIR or IIR filters, or DFB
can be used as a GP fast processor block, similar to RISC block
4) MSI logic elements GUI based and/or the UDB Verilog capability. Eg. the FPGA
like capability
5) Onboard Vref
6) IDAC, VDAC, OpAmps (up to 4), comparator, mixer, switch cap, analog mux....
7) LCD,  COM, UART, I2C, I2S, One Wire, SPI, Parallel, LIN, CAN, BLE, USB
9) Custom components capability, create with schematic capture or Verilog
10) DMA to offload processes like filters, COM, Display
11) ARM M0 (PSOC 4) or M3 (PSOC  5LP) or 8051 core(PSOC 3)
12) Extensive clock generation capabilities
13) All components supported by extensive prewritten APIs

15) PSOC 6 dual ARM core imminent.

https://www.element14.com/community/thread/23736/l/100-projects-in-100-days?displayFullThread=true

http://www.cypress.com/documentation/code-examples/psoc-345-code-examples

Great video library

Attached component list.  A component is an on chip HW resource.

Free GUI design tool with schematic capture, "Creator". Components have rich API library attached
to each component. Compilers free as well.

PSOC 4 is low end of family, consider 5LP parts as well. PSOC 4 also has arduino footprint boards (pioneer) as well

https://www.elektormagazine.com/labs/robot-build-with-cypress-psoc

http://www.cypress.com/products/32-bit-arm-cortex-m-psoc


Regards, Dana.

[Bruce Abbott]

The 8051 and PIC8 don't work efficient with pointers

Pointers are an abomination that should not exist in a high level language.

The 8051 and PIC8 are fine if all you're doing is replacing something that you *could* do with a bunch of gates, latches, shift registers etc -- hardware.

Yep. That is what micro controllers were invented to do.

They are not at all good if you want to write *software*, especially using modern practices. Or even C.

Yet probably over 90% of the 'software' written for them is in C, and people seem to be happy enough with the results despite it being 'not at all good'.  Where they fall down is in limited memory (particularly RAM) and slow CPU speed, which limits their ability to run 'software' (ie. bloated 'modern' code that consists of layers of crap that tries to make it 'architecture-independent').

[nctnico]

The 8051 and PIC8 don't work efficient with pointers

Pointers are an abomination that should not exist in a high level language.

That still doesn't mean they aren't used under the hood. You can program without pointers in C++ but they will be used under the hood extensively.

[julian1]

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.

...

Can the STM32 do PWM with sufficient flexibility for deadtime | shoot-through handling?

I am interested in a similar project. But I look at the STM32 PWM register setup examples and they appear quite complicated - albeit I've only played with basic blinky examples with a discovery board. If I wanted to also have inverted outputs - for high and low side mosfets, then I think that would require two timers and need synchronization. That becomes more complicated when there's a fedback loop controlling the PWM for both timers.

I keep think thinking that would be much simpler with an fpga, with the PWM generation defined in software (Verilog).

It would be interesting to know - if anyone has better insight or a different experience.

[hans]

There are also "special purpose" MCUs like some of the C2000 or DSPIC series that are specifically intended for motor control, digital switching power control, and safety certified applications that presumably have some architectural and firmware / library / toolchain features intended to ease concern about such uses that could cause system hardware failure / other problem due to a firmware bug or lack of control.

These architectures are much simpler to analyze w.r.t WCET, which is required for schedulability analysis. Safety critical systems require the paper work to proof a system is reliable by design, specifying that all deadlines are always met (for example Liu&Layland bound or response time analysis).

If you compare e.g. dsPIC to a cortex m0+, then you'll find that the cortex m0+ is overloaded with features that complicates formal analysis, like multi-stage pipelines, FLASH accelerators, DMA, nested interrupts, etc.

I've no doubt a quick cortex m4 has the capability to do motor control, but if it is hard to certify for safety/critical operation due to architecture it's probably skipped. Basically similar story as the FPGA's.

[julian1]

Basically similar story as the FPGA's.

Is that true when the vendor toolchain will provide a timing analysis and max-clock speed that the fpga can be run with correct signal propagation?

[hans]

You can perform post-simulation after routing, which should behave very close to the real device. For example create a testbench that verifies the structural design against the post-simulation design. Both should behave identically, at e.g. the rising edge of clock.

Timing analysis in the world of FPGA's is about setup/hold times. This is pretty much an automated process, requiring human intervention when set constraints cannot be met.
Timing analysis like I mentioned on MCU's is about multitasking, where you want a schedulability analysis of all tasks that are hard real-time, but perhaps also do overload analysis etc.

There are still opportunities to make lots of mistakes in FPGA's, like create a latch, or incorrectly translate designs between behavioural and structural models. But alot of these errors can be caught in functional simulation without even requiring synthesis.