Cortex-M4, would you start to evaluate it?

I would evaluate it if I had, or expected to have, projects that require that level of performance.

It sounds like Cortex-M3 (maybe even M0/M1?) is adequate for your requirements, and it's quite enough for you to get "up to speed" on that - so why over-burden yourself with stuff you don't (yet) need?

Once you've got used to M3, the "step-up" to M4 - should you ever need it - should be relatively easy.

"I am trying to introduce the Fujitsu 16FX to our company"

Why would you want to get tied-in to a proprietary, single-source architecture?

Why would you want to get tied-in to a proprietary, single-source architecture?

I think these days it's not so difficult to decouple the source code from the choice of the CPU core. In my experience, the transition from ARM7TDMI to ColdFire and then to Cortex-M3 was not painful at all. Keep in mind that ColdFire is big endian. Transition between 16-bit and 32-bit CPU could be more tricky, but with some care writing portable code for them shouldn't be too difficult either.

Why would you want to get tied-in to a proprietary, single-source architecture?

Wasn't the 8031 single sourced by Intel when it first came out?

I'd better have words with them and tell them how crazy they were to get tied into that single sourced architecture those 30+ years ago.

If only they'd have held off until ARM was available, my task of supporting their still live projects would have been so much easier!

Discovery kit is only around USD 27, unbelievable cheap to me.
and, if you are not an amateur totally irrelevant.
if nayone in my employ based the choice of chip on gthe cost of the devboard, they would not last long.

Erik

if nayone in my employ based the choice of chip on gthe cost of the devboard, they would not last long.

And if anyone in my employ produced so many typos, they would not last long.

Erik, please get your keyboard fixed, improve your typing skills or get your nails cut.

Thanks for all the replies.

The price of Stellaris Cortex-M3 attracts us, USD 1.5/each; but we will not use it. What we need/like are: (I don't have any knowledge about hardware.)
Power supply voltage | Max VSS + 6.0V | Min VSS - 0.3V
but Stellaris Cortex-M3: Max 3.6V | Min 3.0V
Not so sure about that, if this difference is a big issue to us, or if it is only because, people don't like change.

Fujitsu 16FX is an Automotive MCU. Most Cortex-M3 is not. TI has some Automotive Cortex-Mx MCU, but they are quite expensive. Some of our products have to use Automotive MCU. Since we already use the Fujitsu 16LX, it is reasonable to introduce Fujitsu 16FX. In our company, people don't like change; introducing Fujitsu 16FX as an upgrade to Fujitsu 16LX, is relatively easier.

Base on my previous experience in my previous company. Developing an ARM7 LPC23xx device took me about one year; it took another one year for the company to deploy my LPC23xx device. After two years, LPC1768 appeared and became a mature solution. So, it is quite possible that the same thing would happen, if I choose Cortex-M3 at this moment. Choosing Cortex-M4 is supposed to give me some more buffer time.

About the price of dev-board, it is quite likely that, I have to pay for it personally. This company does NOT purchase dev-board; dev-board is an unnecessary thing to this company.

About the 16-bit and 32-bit CPU portability, it is indeed a big challenge to me, like the integral promotion and right-shift (>>) / left-shift (<<) etc. I am quite sure that, my C programming skill is not good enough to deal with writing portable code. (I know it is not difficult to you guys.) I believe I know a little about portability and modularization; however, most people in this company believe C language automagically provides portability and modularization.

Almost certainly - that was the way it was back then.

If I could tell in advance which technologies/products are going to live long & prosper, and which will die a death - then I'd be a very rich man!

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.

Is that relatively easy to migrate a product from manufacturer-X's Cortex-M0 to manufacturer-X's Cortex-M3?

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.

Is that relatively easy to migrate a product from manufacturer-X's Cortex-M0 to manufacturer-X's Cortex-M3?

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