> I have one of the ST Discovery boards with the
STM32F407 on it. Getting my
> Linux development system talking to it via stlink was easy.
>
> I'm presently using an LPC2148. Executable is now close to 256K, but
I'm
> pushing the limits time wise. The Cortex M3 at the same clock rate is
> overall quite a bit slower.
Really ?
> I hope to get a break soon so I can evaluate
> the M4, STM32F4xx as a possible upgrade.
>
> I have a pretty simple task multiplexer and by toggling a bit around
> context switches, as I change the preempt clock, I can 'scope'
how many
> switches per second can be done with the tasks not doing anything.
I'll
> post some result when I get the time to run the tests.
I look forward to seeing the results of your tests.
ARM7 vs ARM9 versus Cortex... LPC2939, obsolesence, etc.
Started by ●January 28, 2012
Reply by ●January 30, 20122012-01-30
Reply by ●January 30, 20122012-01-30
It looks like NXP wants to ball and chain developers with their mbed program.
Naa, not really, NXP wants to sell chips, not mbed tools. There must be other reasons. I make a wild guess, you never worked for a company selling micros!? I did for the last 20 years
> And, I'll add that your advice was grossly overvalued at 2 cents.
Point taken ; Guess my advice was too offensive, not intended that way; my apologies.
Bob
Naa, not really, NXP wants to sell chips, not mbed tools. There must be other reasons. I make a wild guess, you never worked for a company selling micros!? I did for the last 20 years
> And, I'll add that your advice was grossly overvalued at 2 cents.
Point taken ; Guess my advice was too offensive, not intended that way; my apologies.
Bob
Reply by ●January 30, 20122012-01-30
I don't want to get between David and Bob in their argument, but there
is
nothing I hate more than having to use proprietary development tools.
Give me gcc and gdb and I'm a happy camper. Learn it once, use it
everywhere.
If I could get one thing from chip manufacturers, it would be to support
the porting of gcc for their controller.
Once I have gcc and gdb, I can use Eclipse. And I use Eclipse for
everything. One IDE. Learn it once, use it everywhere. Its portable and
it works for a wide variety of applications.
I was saddened to learn recently that the gcc team, as of gcc 4.6, has put
the HC11/HC12 community on notice that unless they do a substantial clean
up of their code in gcc, it will be eliminated from future versions. If I
was Freescale, I'd have a hired person working on that ASAP. But maybe
Freescale doesn't care about the HC11 anymore or gcc for it either for that
matter. I find this saddening.
Anyone have any comments on the relative speed of ARM7 (LPC2148),
ARM9(LPC2939) and Cortex M3 devices ? STM32F2x or STM32F4 ?
Thanks
nothing I hate more than having to use proprietary development tools.
Give me gcc and gdb and I'm a happy camper. Learn it once, use it
everywhere.
If I could get one thing from chip manufacturers, it would be to support
the porting of gcc for their controller.
Once I have gcc and gdb, I can use Eclipse. And I use Eclipse for
everything. One IDE. Learn it once, use it everywhere. Its portable and
it works for a wide variety of applications.
I was saddened to learn recently that the gcc team, as of gcc 4.6, has put
the HC11/HC12 community on notice that unless they do a substantial clean
up of their code in gcc, it will be eliminated from future versions. If I
was Freescale, I'd have a hired person working on that ASAP. But maybe
Freescale doesn't care about the HC11 anymore or gcc for it either for that
matter. I find this saddening.
Anyone have any comments on the relative speed of ARM7 (LPC2148),
ARM9(LPC2939) and Cortex M3 devices ? STM32F2x or STM32F4 ?
Thanks
Reply by ●January 30, 20122012-01-30
> They obviously understand that supporting open
source tools
> is good business. It looks like NXP wants to ball and chain developers
> with their mbed program.
The mbed system is an ARM product not an NXP product (although the mbed does use NXP MCU's). NXP are also promoting the LPCXpresso system which is based on CodeRed's IDE which uses the gcc compiler.
Chris Burrows
CFB Software
Astrobe: ARM Oberon Development System
http://www.astrobe.com
> is good business. It looks like NXP wants to ball and chain developers
> with their mbed program.
The mbed system is an ARM product not an NXP product (although the mbed does use NXP MCU's). NXP are also promoting the LPCXpresso system which is based on CodeRed's IDE which uses the gcc compiler.
Chris Burrows
CFB Software
Astrobe: ARM Oberon Development System
http://www.astrobe.com
Reply by ●January 30, 20122012-01-30
> Anyone have any comments on the relative speed of
ARM7 (LPC2148),
> ARM9(LPC2939) and Cortex M3 devices ? STM32F2x or STM32F4 ?
Check this out but I do not cross my finger:
http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_cores
> ARM9(LPC2939) and Cortex M3 devices ? STM32F2x or STM32F4 ?
Check this out but I do not cross my finger:
http://en.wikipedia.org/wiki/List_of_ARM_microprocessor_cores
Reply by ●January 30, 20122012-01-30
DaveS said
> I'm presently using an LPC2148. Executable is now close
> to 256K, but I'm pushing the limits time wise. The Cortex
> M3 at the same clock rate is overall quite a bit slower.
Those figures don't match our numbers, which indicate that
Cortex-M3 can be 20% better than ARM7 on a clock by clock basis.
See
http://www.mpeforth.com/arena/xbench32.fth
Cortex-M3 and M4 performance is critically dependent on the
memory architecture and the bus settings.
Our figures for an STM32F407 Discovery board (A silicon)
indicate that it has a very good memory implementation. NXP have
competition at last.
Stephen
--
Stephen Pelc, s...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
> I'm presently using an LPC2148. Executable is now close
> to 256K, but I'm pushing the limits time wise. The Cortex
> M3 at the same clock rate is overall quite a bit slower.
Those figures don't match our numbers, which indicate that
Cortex-M3 can be 20% better than ARM7 on a clock by clock basis.
See
http://www.mpeforth.com/arena/xbench32.fth
Cortex-M3 and M4 performance is critically dependent on the
memory architecture and the bus settings.
Our figures for an STM32F407 Discovery board (A silicon)
indicate that it has a very good memory implementation. NXP have
competition at last.
Stephen
--
Stephen Pelc, s...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
Reply by ●January 30, 20122012-01-30
I figured this out.
First, the STM32F405 is a Cortex M4 processor. It runs at 168MHz for a
speed of 210 DMIPS. And it has a floating point processor. I kept
thinking it was an M3 processor.
The STM32F205 is a 120 MHz Cortex M3 device delivering 150 DMIPS.
From the Wiki page, the LPC2939 which uses the ARM968E-S, will be in the
same ballpark, if not a bit slower than the M4, probably about the same
speed as the M3. The Jazelle version does 220 MIPS and the 968E-S will be
slower than it.
Speed aside, I like 2 other things about the STM line. 1) STLink has an
available gdb library 2) I think the CAN subsystem in the STM devices is
more versatile in that it can save up to 12 CAN messages in memory before
CPU intervention is required to prevent losing them.
So, unfortunately, unless someone tells me something bad about these STM
devices, I think we will be going with an STM product.
Thanks for all the help.
First, the STM32F405 is a Cortex M4 processor. It runs at 168MHz for a
speed of 210 DMIPS. And it has a floating point processor. I kept
thinking it was an M3 processor.
The STM32F205 is a 120 MHz Cortex M3 device delivering 150 DMIPS.
From the Wiki page, the LPC2939 which uses the ARM968E-S, will be in the
same ballpark, if not a bit slower than the M4, probably about the same
speed as the M3. The Jazelle version does 220 MIPS and the 968E-S will be
slower than it.
Speed aside, I like 2 other things about the STM line. 1) STLink has an
available gdb library 2) I think the CAN subsystem in the STM devices is
more versatile in that it can save up to 12 CAN messages in memory before
CPU intervention is required to prevent losing them.
So, unfortunately, unless someone tells me something bad about these STM
devices, I think we will be going with an STM product.
Thanks for all the help.
Reply by ●January 30, 20122012-01-30
> > I'm presently using an LPC2148.
Executable is now close to 256K, but
> > I'm pushing the limits time wise. The Cortex
> > M3 at the same clock rate is overall quite a bit slower.
>
> Those figures don't match our numbers, which indicate that
> Cortex-M3 can be 20% better than ARM7 on a clock by clock basis.
> See
> http://www.mpeforth.com/arena/xbench32.fth
> Cortex-M3 and M4 performance is critically dependent on the memory
> architecture and the bus settings.
>
> Our figures for an STM32F407 Discovery board (A silicon) indicate that it has
> a very good memory implementation. NXP have competition at last.
The STM32F4 line with the ART is top of the Cortex-M pile for performance
for the moment. Freescale have done some more chest-banging for the Kinetis
(possibly because they now have Geoff Lees there) indicating they'll have
the fastest Cortex-M device in the middle of the year. Yawn.
There are, of course, certified benchmark scored for many Cortex-M cores,
e.g. STM32F4
<http://www.eembc.org/benchmark/reports/benchreport.php?benchmark_seq89&s
uite=CORE>
The F4 achieves about 2.8 CoreMarks/MHz, the 2939 is 1.18 for comparison.
The benchmark suite is open and that means you can run a copy on your own
target CPU/compiler combination.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
> > I'm pushing the limits time wise. The Cortex
> > M3 at the same clock rate is overall quite a bit slower.
>
> Those figures don't match our numbers, which indicate that
> Cortex-M3 can be 20% better than ARM7 on a clock by clock basis.
> See
> http://www.mpeforth.com/arena/xbench32.fth
> Cortex-M3 and M4 performance is critically dependent on the memory
> architecture and the bus settings.
>
> Our figures for an STM32F407 Discovery board (A silicon) indicate that it has
> a very good memory implementation. NXP have competition at last.
The STM32F4 line with the ART is top of the Cortex-M pile for performance
for the moment. Freescale have done some more chest-banging for the Kinetis
(possibly because they now have Geoff Lees there) indicating they'll have
the fastest Cortex-M device in the middle of the year. Yawn.
There are, of course, certified benchmark scored for many Cortex-M cores,
e.g. STM32F4
<http://www.eembc.org/benchmark/reports/benchreport.php?benchmark_seq89&s
uite=CORE>
The F4 achieves about 2.8 CoreMarks/MHz, the 2939 is 1.18 for comparison.
The benchmark suite is open and that means you can run a copy on your own
target CPU/compiler combination.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
SolderCore running Defender... http://www.vimeo.com/25709426
Reply by ●January 30, 20122012-01-30
> Anyone have any comments on the relative speed of
ARM7 (LPC2148),
> ARM9(LPC2939) and Cortex M3 devices ? STM32F2x or STM32F4 ?
I have done numerous ARM7 designs and now in the middle of an M3 design.
The M3 is faster running virtually the same code, and the IRQ processing appears much faster.
The M3 also has more powerful instructions that execute in less clocks.
I am very surprised that some keep trying to compare MCUs by pin toggle rates.
That has virtually nothing to do with MIPS, which is internal instruction processing.
Entirely different aspects of speed.
A 100MHz MCU running single cycle instructions means each instruction is 10nSec.
To send data to a pin means a very different bus transaction and pin drivers involved.
That takes a lot more time, and the pin drivers cannot even handle those rates.
But that has nothing to do with MIPS or instruction processing speed.
Chris.
> ARM9(LPC2939) and Cortex M3 devices ? STM32F2x or STM32F4 ?
I have done numerous ARM7 designs and now in the middle of an M3 design.
The M3 is faster running virtually the same code, and the IRQ processing appears much faster.
The M3 also has more powerful instructions that execute in less clocks.
I am very surprised that some keep trying to compare MCUs by pin toggle rates.
That has virtually nothing to do with MIPS, which is internal instruction processing.
Entirely different aspects of speed.
A 100MHz MCU running single cycle instructions means each instruction is 10nSec.
To send data to a pin means a very different bus transaction and pin drivers involved.
That takes a lot more time, and the pin drivers cannot even handle those rates.
But that has nothing to do with MIPS or instruction processing speed.
Chris.
Reply by ●January 30, 20122012-01-30
