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?
I am a big fan of those chips (CMx).
But if you are in an industry that requires extensive code certification (automotive for example) and work with a large code base, you may think hard before plunging into a new chip. The cost of migrating your code to and maintaining your code on a new chip can be extensive. We for example dropped all 8-bit support for our code (unless the customers pay for it) because of that.
Hi Ashley Madison,
Thanks for reminding me this.
It is indeed a big issue to developers. However, as far as I know, our code has never been certificated.
I remember that, you are also a PIC MCU fan. Would you please provide some advices about when to use PIC, when to use Cortex-Mx?
Do you think that, theoretically, Cortex-Mx can be used as a common platform with multiple sources of supply, so that the developers don't need to deal with many different architectures/tool-chains, using Cortex-M0 as 8/16-bit solution, using Cortex-M3 as 32-bit solution, using Cortex-M4 as 32-bit with FPU/DSP solution, all requirements are met.
Is that relatively easy to migrate a product from manufacturer-X's Cortex-M0 to manufacturer-X's Cortex-M3?
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.
I'm not sure about that, as I primarily work with NXP chips. I can tell you that migrating from a LPC2478 to a LPC1788 or LPC1114 is very easy indeed.
You should do it once. That will teach how to write your code in a portable manner. Subsequent migrations should be trivial.
I think the migration is more likely to be easier when you stick with the same manufacturer - but there is no guarantee.
A manufacturer might choose to have common (or closely-related) peripherals between different product ranges - or they might not!
Some manufacturers even have different peripherals between, say, their low-end Cortex-M3s and high-end Cortex-M3...
NXP tends to be very nice - they try to have very similar behaviour, bit definitions and constant names between the peripherials of their different chips.
And with ARM-class processors, the code can be written in a way that keeps down the number of peripherial-specific lines of code. It's not needed to have a full driver layer, but the business logic and the device manipulation code don't need to be all mixed up.
NXP even made the LPC2478 and its replacement, the LPC1788 - pin compatible.
And 1768 is pin compatible with 2368. Lots of drop-in compatibility in their current line of microcontrollers.
Many Thanks to Ashley Madison and everyone involved.
You can try TI's M4 (LM4f232) in the stelleris series this can meet to your all requirements. They also have an evaluation board for this.