Sorry for my limited knowledge and limited English skill.
Quite a few companies are trying to sell their Cortex-M3 MCU to our company. Texas Instruments' technical sales engineer visited our office, to promote the Stellaris Cortex-M3. Several local distributors also contacted us for promoting other Cortex-M3 MCU, like STM32.
In the past few days, I noticed that, ST is promoting their STM32F4 series. And the price of STM32F4-Discovery kit is only around USD 27, unbelievable cheap to me. So I did some quick study about it. Several Simplified Chinese articles talked about the success of STM32 MCU, and the intense competition of the Cortex-M4 market. They also concluded that, the age of Cortex-M4 is coming.
I am trying to introduce the Fujitsu 16FX to our company, which is good in price and features. (don't want to deal with outdate MCUs anymore.) But Cortex-Mx is more general, and has a lot of resource to use. I heard that Cortex-M4 is 10% expensive than Cortex-M3, but with powerful DSP and FPU.
I almost don't know anything about DSP/FPU and any Assembly language. My quick study of Cortex-M4 shows that, the FPU performance of STM32F4 is slower than expected, and compilers do not support the FPU well, so, to utilize the FPU, users need to use Assembly language. Besides, if users use floating point in the Interrupt Service Routine, some extra efforts has to be done to deal with the Context Switching, this slowdown the interrupt performance, add extra complexity.
How do you think about Cortex-M4, and would you start to evaluate it?
My involvement with PIC is very limited, especially since we do not do much on that platform.
I think the benefits of a common core are over-sold. For those chips, unless you have a richly funded project (military or aerospace for example), you are going to code in a high level language (C for example). In those cases, the core makes minimum difference to the programmer.
The biggest threats to porting code from one chip to another is, in order of degrees:
1) poor programming style: if your code isn't written with portability in mind, you will have a hard time; or if the code base is poorly structured, you will have a tough time migrating it.
2) peripherals: each vendor has its own peripherals glued to the same core. They all work differently.
The 1st problem can be dealt with better training and better quality control; The 2nd problem can be dealt with lots of investment (of programmers' time) and better training.
So I would say that to migrate from one vendor's CMx chip to another vendor's CMx chip is no different than migrating from one vendor's X chip to another vendor's Y chip.
Peripherials aren't just a question of training. Some peripherials can do things others can not. So it's very important to read through the datasheets and figure out if the specific chip really have the required hardware capabilities.
"I would say that to migrate from one vendor's CMx chip to another vendor's CMx chip is no different than migrating from one vendor's X chip to another vendor's Y chip"
I disagree that it's no different - but take your point that the benefits can be overstated.