原创 【转帖】【STM32团队】STM32 vs AVR mega benchmarks and such

2008-4-14 21:48 5187 11 11 分类: 工程师职场

 





ThomasScherrer
Member

From: Denmark
Registered: 2007-10-29
Posts: 61
E-mail  Website


STM32 vs AVR mega benchmarks and such



I have been looking on the new cool ARM7 Cortex from ST for awhile,
now got my latest dev board up and running.
----------------
Benchmark test1:
I have a nice 3rd order lowpass filter with floating point calculations,

float filter(float s)
{
  Z[3]=Z[2];
  Z[2]=Z[1];
  Z[1]=Z[0]; // the rolling buffer
  Z[0]= s - (D[1]*Z[1] + D[2]*Z[2] + D[3]*Z[3]);
  return Z[0]*N[0] + Z[1]*N[1] + Z[2]*N[2] + Z[3]*N[3];
}

here are the filter constants used:
float N[]={1.67e-02, 5.01e-02, 5.01e-02, 1.67e-02};
float D[]={1, -1.798, 1.221, -.2898};
float Z[4]={200.001,200.001,200.001,200.001};

This code is made and tested for AVR,
but this exactly same C code compile and run just fine on the STM32 !

AVR at 8 MHz time = 2200uS (244uS at 72MHz caluculated) GCC compiler for AVR
STM32 at 72MHz time = 12-14uS (126uS at 8MHz caluculated) KEIL compiler
STM32 at 72MHz time = 16-41uS (with GCC compiler)
STM32 at 72MHz time = 12-15uS (with IAR compiler)

the STR32 is 157-183 times faster.
but the clock is also 9 times faster.
so at SAME clock the STR32 is 17-20 times faster than AVR.

uptimizer changed from none to max speed: 14uS to 12uS

if you call the filter routine with zero it is known to be a bit faster, but I called it with
a variable number and saw almost same result all the time.

--------------------------------------------------

Benchmark test2:
Pin toggle, the STM32 can toogle a pin with 20.8MHz on port b,
the port B bridge setup to 50MHz, and 72MHz core.
so if you set a bit hi and then lo, the pulse will be only 24nS wide !! KEIL compiler

Pin toggle, the STM32 can toogle a pin with 7.3MHz on port b,
the port B bridge setup to 50MHz, and 72MHz core.
so if you set a bit hi and then lo, the pulse will be 68nS wide GCC compiler

Pin toggle, the STM32 can toogle a pin with 19.2MHz on port b,
the port B bridge setup to 50MHz, and 72MHz core.
so if you set a bit hi and then lo, the pulse will be only 26nS-109nS wide !! IAR compiler, time depends on uptimize

An AVR MEGA type, can toogle a pin at halve its core frequency,
pin 10MHz, core 20MHz.
so if you set a bit hi and then lo, the pulse will be only 125nS wide at 8MHz (50nS wide, at 20MHz clock)
so an 20MHz clocked AVR will outperform STM32 only with GCC compiler in bit banging applications
-----------------------------------------------------

code size test floats:

STM32 this filter and init of the floats needed: (KEIL compiler microvision)
O0: 1108 bytes
O3: 1068 bytes
--
STM32 this filter and init of the floats needed: (GCC compiler)
NO: 896 bytes
O3:  896 bytes
MAX: 896 bytes
funny the uptimizer levels dont change a thing in size or speed of this filter.
GCC wins on smallest code, looses on speed
--
STM32 this filter and init of the floats needed: (IAR compiler)
None: 1000 bytes
medium: 926 bytes
High : 918 bytes
several optimizer options exist, rather complex.
--
AVR this filter and init of the floats needed: (GCC compiler here)
O0: 2046 bytes
O3: 2248 bytes
-S: 1838 bytes
(all optimized results where tested to function, the filter call takes same time to execute)
it is a known fact that is IAR compiler can make code size much smaller for normal AVR programs.
I have seen 50% code size with IAR, and the program still worked, on another project.
--------------------------------------------------
code size test chars and integers:
needs to be done
--------------------------------------------------

Price:
ok it is crasy cheap with STM32 !! you get so much internal features
and so much code space for so much less compared to avr 128kb vs 128kb !!

-----------------

ADC:
The AVR have 10 bit internal ADC and normally we see 1 LSB jitter with no extra software filter added.
On the STR32 dev board from KEIL I have here I see 4-5 LSB jitter,
ok it is 12bit resolution os I say it is the same internal digital noise,
the STM32 can run at 1MS !! so it can handle plenty of oversampling and digital noise filters = much better resolution and still much faster ADC result.
I made a normal running avarage like this on the STM32:
adcfiltered=((adcfiltered*0.9)+(newadc*0.1)); // this gives 12 bits useable resolution 0-4000
this is a 10 cycle filter, now I have the full 12 bits resolution with under 1 LSB jitter.
I have proved by lab test if the runing avarage is changed a bit, so it accumulate the noise,
and the output is therefore a calculated higher value = more bits resolution due to the noise,
this gives a much lower speed, but ok it can handle 1 MEGA samples/pr sec at 12bit this converter !
adc13bits = ((adc13bits*0.99)+((float)ADC_ConvertedValue*0.02) ); // this gives 13 bits useable resolution 0-8000
adc14bits = ((adc14bits*0.99)+((float)ADC_ConvertedValue*0.03) ); // this gives 14 bits useable resolution 0-12000
-------------------

Upgradeablility:
The STM32 exist in 48 - 64 - 100 pin LQFP pakages,
easy to hand solder and works fine on even 2 layer boards
also they exist from 32-64-128kb flash, the cheapest is 1.8$ and the biggest 3.6$
they exist in pin compatible slow and cheaper versions also.
they will release 256kb and 512kb soon.
__________________


Last edited by ThomasScherrer (2008-01-15 18:10:31)





Thomas Scherrer Denmark webx.dk



Offline




# 2   2008-01-04 22:33:47 STM32 vs AVR mega benchmarks and such





ThomasScherrer
Member

From: Denmark
Registered: 2007-10-29
Posts: 61
E-mail  Website


Re: STM32 vs AVR mega benchmarks and such



latest news :
this gives you 16 bit resolution !!!
adc16bits = ((adc16bits*0.999)+((float)ADC_ConvertedValue*0.016));     // 16 bit
it is still nice and lineary, no shit try it !
ok I had to add one more potentiometer 10k and 1Meg resistor to the first pot to really prove I have a useable 16 bit resolution.


Last edited by ThomasScherrer (2008-01-04 22:43:42)





Thomas Scherrer Denmark webx.dk



Offline




# 3   2008-01-05 00:53:17 STM32 vs AVR mega benchmarks and such





Stewee
Member

From: Dorset/England
Registered: 2007-10-11
Posts: 40
E-mail


Re: STM32 vs AVR mega benchmarks and such



Thankyou for sharing your findings and your filter. Very useful and interesting.




ThomasScherrer wrote:


adc13bits = ((adc13bits*0.99)+((float)ADC_ConvertedValue*0.02) ); // this gives 13 bits useable resolution 0-8000
adc14bits = ((adc14bits*0.99)+((float)ADC_ConvertedValue*0.03) ); // this gives 14 bits useable resolution 0-12000
__________________


If every reading was identical, then
Surely if you take 99% of something and add 2% you get 101%?
Not an extra bit resolution.


Last edited by Stewee (2008-01-05 01:23:42)




Offline




# 4   2008-01-05 03:59:02 STM32 vs AVR mega benchmarks and such





ThomasScherrer
Member

From: Denmark
Registered: 2007-10-29
Posts: 61
E-mail  Website


Re: STM32 vs AVR mega benchmarks and such



no no stewee the whole idea of oversampling only works IF the input is not stable,
as I said in this case the ADC generate actually 4-5 LSB of internal noise, that is actually perfect,
with oversampling and aditive filtering you will infact be able to see input signals that is 16 times under one LSB
of the original 12 bit adc !! equals a 16 bit resolution with a full scale analog voltage making a result that go from 0 to 65535, and you can actually use every count as a final result, I have tried it today so I know this works !





Thomas Scherrer Denmark webx.dk



Offline




# 5   2008-01-05 14:49:49 STM32 vs AVR mega benchmarks and such





Mark Harris
New member

Registered: 2007-11-13
Posts: 1
E-mail


Re: STM32 vs AVR mega benchmarks and such



Very impressive Thomas!




Offline




# 6   2008-01-05 22:11:36 STM32 vs AVR mega benchmarks and such





Francis
Moderator

From: France-Grenoble
Registered: 2007-07-09
Posts: 173
E-mail


Re: STM32 vs AVR mega benchmarks and such



I believe that it worls only if the noise is white, i.e. purely random. In the case of a microcontroller the noise comes from Vcc, the CPU consumption (interrupt,...), and the other peripherals (IOs, USB, etc...). Therefore, the result would depend a lot on the activity of the close environment.
Anyway, it's sure that filtering will improve the result.




Offline




# 7   2008-01-05 22:39:52 STM32 vs AVR mega benchmarks and such





ThomasScherrer
Member

From: Denmark
Registered: 2007-10-29
Posts: 61
E-mail  Website


Re: STM32 vs AVR mega benchmarks and such



exactly Francis, I have made extensively testing on this issue, and too me the noise is random.





Thomas Scherrer Denmark webx.dk



Offline




# 8   2008-01-07 06:11:41 STM32 vs AVR mega benchmarks and such





Stewee
Member

From: Dorset/England
Registered: 2007-10-11
Posts: 40
E-mail


Re: STM32 vs AVR mega benchmarks and such



;-) Nobody is saying oversampling is homeopathy, or that you are wrong, indeed it is 'VERY' helpful. Let me clarify:

My concern is that we 'ONLY' need to AVERAGE  MORE noisy samples to get MORE resolution - NOT use coefficients that add up to more than 1.   e.g. .99 and .02   .

The more samples you average the more bits of resolution you can assume - if the noise is white. Every 64 samples averaged can give one more bit of resolution so the expression for 16bit resolution would be;
average = average * 255/256  +   sample * 1/256;  (pretty much what you had. Thanks.)

If the coefficients do not add up to 1, your tests will still give better resolution, as you found, if their RATIO is about right, but an offset will grow in the final measurement over a VERY long time.

I am concerned readers under pressure might cut and paste your excellent benchmark expressions into long running applications that could suffer from an offset problem. That is all.

---

Other interesting notes;

Wiki Oversampling; http://en.wikipedia.org/wiki/Oversampling

The step response for the pseudo average is different to a true rolling average.
It takes longer for the pseudo average to arrive at the new reading after a step change in the signal measured.
The step response for a true rolling average is a straight incline.
The step response for the pseudo rolling average is a curve that starts shallow, steepest midway, ends shallow.


Last edited by Stewee (2008-01-07 06:14:15)




Offline




# 9   2008-01-07 06:23:47 STM32 vs AVR mega benchmarks and such





ThomasScherrer
Member

From: Denmark
Registered: 2007-10-29
Posts: 61
E-mail  Website


Re: STM32 vs AVR mega benchmarks and such



You are right ! that is why I have combined first avaraging and then 3rd order low pass,
to give me a fast reacting and nice noise free result :-)

from 12 to 16 bits ADC resolution I see only 16 times over sampling needed,
but if you also want to stable the noise 64 to 128 times is more likely to be used.

it is also right I have a few calculations errors, the:
((adc16bits*0.999)+((float)ADC_ConvertedValue*0.016));     // 16 bit
this gives not exactly 16 times the ADC value, but more like 15.782
but it is a constant error, so i am still happy.





Thomas Scherrer Denmark webx.dk



Offline




# 10   2008-01-18 18:08:48 STM32 vs AVR mega benchmarks and such





ikdor
New member

From: Netherlands
Registered: 2007-08-17
Posts: 3
E-mail


Re: STM32 vs AVR mega benchmarks and such



Thomas,

When going from 12 to 16 bits you will need 256x oversampling like Stewee said above.
Also when making a program, it's much faster to use shifts of integers instead of using floats. The 256x oversampling is exactly a shift of one byte.  Better to try something like this:
Sum = Sum - Sum>>8 + AdcValue;
Value16bit = Sum  >> 4;

Small problem (depending on your application) is that this will creep slowly toward the right value. For a fast response you will need to use a 256 value buffer instead of an IIR filter like the one above.

Igor




Offline




# 11   2008-01-18 19:08:43 STM32 vs AVR mega benchmarks and such





Francis
Moderator

From: France-Grenoble
Registered: 2007-07-09
Posts: 173
E-mail


Re: STM32 vs AVR mega benchmarks and such



I believe some parenthesis are missing:   Sum = Sum - ( Sum>>8 ) + AdcValue;




Offline


文章评论0条评论)

登录后参与讨论
我要评论
0
11
关闭 站长推荐上一条 /2 下一条