ARM Cortex Mx vs the rest of the gang

Hi

So, considering going the Cortex Mx route for project with new microcontrollers at our firm.

Has anyone a feeling/information about the development speed of the ARM Cortex Mx series vs the rest of the industry?

Meaning, that potentially the same core strategy for the ARM, licensing to toher manufactors mean that they may have faster development speed that others (Microchip, Renesas, whoever not using ARM)

Cheers

Klaus

Reply to
Klaus Kragelund
Loading thread data ...

What I meant to say was that maybe ARM Cortex has potentially faster releases of new devices and a more rapid platform for launching new devices

Cheers

Klaus

Reply to
klaus.kragelund

releases of new devices and a more rapid platform for launching new devices

In my opinion, most work for a new uC must be done with the peripherals. The Cortex M core is the same with different manufactureres, but the peripherals are not...

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de 

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt 
 Click to see the full signature
Reply to
Uwe Bonnes

Klaus Kragelund wrote on 5/30/2017 8:11 AM:

I'm not sure how useful such a comparison would be other than between the ARM CM and a few of the lesser popularity processors like the Blackfin for example. Other lines of embedded processors seen to be moving right along and keep up with the rest of the industry just fine.

One thing to keep in mind is that while there are many makers of ARM processors, there is only one company doing significant development that is used by the many makers of ARM chip, ARM! So I don't see where they are any more prolific than anyone else.

Look at the MSP430. It targets a broad segment of the market and offers many, many options with more added continuously. I'm not sure anyone offers more variety than Microchip does with the various PIC offerings.

--

Rick C
Reply to
rickman

Yup. You could probably toss any core in the middle, and the work would still be to talk to the stuff attached to it.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

I think there is some loss of understanding of the question. ARM and every other embedded CPU company is constantly working to improve their CPUs to provide the maximum performance available from present technology as best suits the applications of their customers. This is not the same as designing new SoCs which vary in the memory size or peripherals on chip. There is a TON of work that goes into optimizing CPU designs which is a

*MUCH* bigger effort than designing some peripherals. Often the same peripherals used on the old family are used on the new family. The only real task is the interconnection.

You are very much trivializing the effort that goes into optimizing a CPU architecture. That is why ARM has such a wide range of CPU performance traded off against CPU size and power consumption. They have taken the time and effort to provide good solutions at many points.

--

Rick C
Reply to
rickman

I believe you are talking about the total effort for /designing/ the chip, while Tim was talking about the effort in /using/ the chip. It is not at all clear (to me, anyway) what the OP was talking about.

Reply to
David Brown

Exactly my point, except CPU, not "chip". Tim's comment is tangential to the OPs question.

--

Rick C
Reply to
rickman

Yes, that's what Tim was talking about. Tim buys chips. Tim does not build chips. So as long as Tim is not reading about chip designers in Malaysia getting beaten with sticks because their pipelining techniques don't line up with orthodox Islam, Tim doesn't care about the details.

peripherals core .-------------. .--------------. | | | | | this part | | here | | needs my |=========| be | | attention | | dragons | | | | | '-------------' '--------------'

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

I dunno. It sounded like Kraus wants to buy chips, not build cores.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

That's right. You don't know.

--

Rick C
Reply to
rickman

Chips with ancient cores aren't very interesting except to CPU archeologists.

--

Rick C
Reply to
rickman

If I understand the OP correctly, he is "considering going the Cortex-M rou te" presumably weighing his options against some other embedded CPU family.

If this is the question here, then Cortex-M is a very compelling choice sou rced by more silicon vendors than any other CPU in the industry. They all c ompete for our sockets, so the unit prices are very competitive, developmen t boards are dirt cheap (possibly subsidized?), and vendors provide the who le "ecosystems" of software to differentiate their particular Cortex-M MCUs .

Also, investment in Cortex-M development tools and training will most likel y pay off better than in any other CPU, now and in the foreseeable future.

In summary, I don't see a compelling reason to choose any other CPU at the moment. This does not mean that Cortex-M is the "best" CPU from the technic al point of view. For example, the FPU integration in the Cortex-M4F/M7 is horrible. But this is not the issue here. The issue is whether any other CP U family can offer more benefits overall.

Miro Samek

formatting link

Reply to
StateMachineCOM

oute" presumably weighing his options against some other embedded CPU famil y.

ourced by more silicon vendors than any other CPU in the industry. They all compete for our sockets, so the unit prices are very competitive, developm ent boards are dirt cheap (possibly subsidized?), and vendors provide the w hole "ecosystems" of software to differentiate their particular Cortex-M MC Us.

ely pay off better than in any other CPU, now and in the foreseeable future .

e moment. This does not mean that Cortex-M is the "best" CPU from the techn ical point of view. For example, the FPU integration in the Cortex-M4F/M7 i s horrible. But this is not the issue here. The issue is whether any other CPU family can offer more benefits overall.

You are spot on, I was just not so clear in the original post

I am looking for arguments pro/con for Cortex M0 versus Renesas RX130

Which device is the clever choice, primarily crystal ball prediction of off ered cost and features

Cheers

Klaus

Reply to
Klaus Kragelund

critto:

4F/M7 is horrible.

can you explain a little bit more about that?

Thanks Bye Jack

Reply to
Jack

I said that "... the FPU integration in the Cortex-M4F/M7 is horrible", bec ause it adds tons of overhead and a lot of headache for the system-level so ftware.

The problem is that the ARM Vector Floating-Point (VFP) coprocessor comes w ith a big context of 32 32-bit registers (S0-S31). These registers need to be saved and restored as part of every context switch, just like the CPU re gisters. ARM has come up with some hardware optimizations called "lazy stac king and context switching" (see ARM AppNote 298 at

formatting link
ntext_switching.pdf ). But as you will see in the AppNote, the scheme is qu ite involved and still requires much more stack RAM than a context switch w ithout the VFP. The overhead of the ARM VFP in a multitasking system is so big, in fact, that often it outweighs the benefits of having hardware FPU i n the first place. Often, a better solution would be to use the FPU in one task only, and forbid to use it anywhere else. In this case, preserving the FPU context would be unnecessary. (But it is difficult to reliably forbid using FPU in other parts of the same code, so it opens the door for race co nditions around the FPU if the rule is violated.)

Anyway, does it have to be that hard? Apparently not. For example the Renes as RX CPU comes also with single precision FPU, which is much better integr ated with the CPU and does not have its own register context. Compared to t he ARM VFP it is a pleasure to work with.

Miro Samek state-machine.com

Reply to
StateMachineCOM

They have to be saved during every context switch if the OS is broken. What stops it from saving the FPU context only for tasks which use the FPU? It is a single bit of information in the task descriptor. Then what stops the programmer from declaring the FPU is in use or not within a task? Normally what is done for this purpose is

- enable FPU for tha task, saving the state the previous FPU_in_use bit state,

- do the FPU work,

- restore the previous state of the FPU_in_use bit. Obviously for tasks which use the FPU intensively this needs not be done, one just leaves the FPU_in_use on.

I once had a look at that only to confirm my suspicion that it is just piling problems over existing problems. Things like this are done by software, or rather software is written such that there is no need for that sort of thing.

Not having a separate FPU register set is a disadvantage, not an advantage (now if the FPU is a useless 32 bit one having it at all is a disadvantage but this is another matter :-). Nothing prevents software from using what it wants and from saving only what has to be saved; often having an entire FPU and saving its entire context in addition to that of the integer unit makes things more efficient, sometimes a lot more efficient (e.g. implementing a FIR on a plain FPU where data dependencies do not allow you to do it at a speed more than speed/(pipeline length), you just need many registers). The e500 cores from freescale were never popular with me exactly because they had the integer and FP register sets in one, just 32 registers in total. Not a good idea on a load/store machine.

Dimiter

====================================================== Dimiter Popoff, TGI

formatting link
======================================================
formatting link

Reply to
Dimiter_Popoff

itto:

ecause it adds tons of overhead and a lot of headache for the system-level software.

with a big context of 32 32-bit registers (S0-S31). These registers need t o be saved and restored as part of every context switch, just like the CPU registers. ARM has come up with some hardware optimizations called "lazy st acking and context switching" (see ARM AppNote 298 at

formatting link
context_switching.pdf ). But as you will see in the AppNote, the scheme is quite involved and still requires much more stack RAM than a context switch without the VFP. The overhead of the ARM VFP in a multitasking system is s o big, in fact, that often it outweighs the benefits of having hardware FPU in the first place. Often, a better solution would be to use the FPU in on e task only, and forbid to use it anywhere else. In this case, preserving t he FPU context would be unnecessary. (But it is difficult to reliably forbi d using FPU in other parts of the same code, so it opens the door for race conditions around the FPU if the rule is violated.)

esas RX CPU comes also with single precision FPU, which is much better inte grated with the CPU and does not have its own register context. Compared to the ARM VFP it is a pleasure to work with.

Thanks for the explanation.

Bye Jack

Reply to
Jack

Exactly.

Exactly. As memory is now the bottleneck in most designs, any program state (e.g., floating point values) that have to be saved OUTSIDE the CPU (even in normal operation, ignoring context switches) take a hit in terms of performance. Esp when you're dealing with "big" data types (64, 80, 128b).

[Guttag clearly missed the boat on that call wrt the 99K. Cute/clever idea but he failed to see the growing disparity in the CPU/memory "impedance mismatch". But, context switches were a piece of cake! :>]

Ideally, register-rich processors would implement a set of internal flags that would be set each time a register was loaded. And, a "save state" opcode that acted similar to the 09's PUSH "vector" saving only those registers that have been "altered". Then, letting the programmer clear this "flag register" as it reloaded the preserved state for the new task.

[An even more flexible/conditional scheme would allow traps for each register but the overhead of servicing the trap FOR EACH REGISTER would far outweigh the cost of unconditionally restoring ALL state]
Reply to
Don Y

Hi Don,

I am not so sure how useful this would be, basically software knows which registers have been used and which not, it is up to it to save just what needs to be saved and restore it when needed only. It could be some help but not enough to justify the extra silicon & complexity I believe.

Dimiter

Reply to
Dimiter_Popoff

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.