stm32f100 vs. stm32f103 for power control applications..

mmcmac · ‎2013-04-27

Posted on April 27, 2013 at 21:49

Hi All,

I've rummaged through the archives but didn't really see what

I'm looking for here. We have a few PWM power control designs

based on the Atmel ATTINY861A which provides fairly complete

support for this application space. However we're limited by its

flash capacity and 8-bit architecture.

I've been looking at both the F100 and F103 STM32 devices and

was hoping someone who has dug into the functional limitations

and quirks of these devices may be able to offer some insight.

Specifically it appears the F100 may offer support of more PWM

channels compared to the F103, but I believe the F103 can support

at least three independent complimentary PWM channels with

deadtime control. And if I read correctly both devices support

hardware PWM cycle termination and A/D synchronized to PWM

cycle. However the 3X clock speed of the F103 is well worth the

price bump assuming we're not foregoing any power application

specific functionality which may be unique to the F100.

Aside from that any cautions on functionality loss and/or

restriction specific to power control applications with the lower

pin count packages (32,48) relative to 64 LQFP versions?

Thanks,

-mm

#stm32f100-stm32f103-pwm-control #motor-cntl

Asantos · ‎2013-04-29

Posted on April 29, 2013 at 16:02

I think that the best STM32 for Power Control is the STM32F30X. 4x5MSPS ADC + 2*144MHZ Motor PWM + 4xPGA + 7xCOMP. And it is a Cortex-M4 with floating point.

jj2 · ‎2013-04-29

Posted on April 29, 2013 at 17:52

Focus here on our review for potential use of F0 for BLDC motor control - one small subset of your, ''Power Control.'' This for professional (for profit) applications.

Required MCU capability:

Pins Function Ana

6 PWM ''pair'' w/deadband & hw shutdown No

3 Hall sensor in No

3/6 Analog comparator (1 or 2) Yes

3 Normal control inputs: run, direction, brake No

4 SPI (accommodate client specific add ons) No

9 ADC: speed, torque, motor V, bemf(3), i-lmt(3) Yes

1 PWM Fault-In pin No

29/32 GPIO/ADC req'd

With the use of SPI - inevitable extra ADC and GPIO ICs can be accommodated.

Analog comparators are, ''life-savers'' - available ex-MCU via tiny sot 23-5 pack.

The 48 pin QFP package ''just fits'' in several of our designs - raising the appeal of F0...

zzdz2 · ‎2013-04-29

Posted on April 29, 2013 at 21:29

Analog comparators are, ''life-savers'' - available ex-MCU via tiny sot 23-5 pack.

These are handy indeed, IMO it's the most missing thing in F1 series.

You can emulate it with ADC but it may be somewhat slow.

jj2 · ‎2013-04-29

Posted on April 29, 2013 at 23:03

''These are handy indeed, IMO it's the most missing thing in F1 series.

You can emulate it with ADC but it may be somewhat slow.''

We're on same page here. We employ these for ''cycle by cycle'' current limiting - and indeed are order of magnitude faster than ADC - and run w/out concern of SW hang. Regulatory agencies love this ''independence''as it greatly aids safety.

And - if HW properly married to SW - such current measurement/limiting can be made fully interactive - clearing automatically as the fault passes. (ideal to prevent nuisance ''trips.'')

Analog comparators are, ''life-savers'' - available ex-MCU via tiny sot 23-5 pack.

These are handy indeed, IMO it's the most missing thing in F1 series.

You can emulate it with ADC but it may be somewhat slow.

emalund · ‎2013-04-29

Posted on April 30, 2013 at 00:19

my method:

start with the fastest, must memory, most I/O member of the family (in your case f1x)

if t can do it, continue, else find another family.

then start seeing which lesser members f that family can handle your app.

it is a definite time waster not6 to verify with the biggest, baddest member of the family first.

Start high, go down

Erik

jj2 · ‎2013-04-30

Posted on April 30, 2013 at 18:07

Would have thought that something here earned some response from originator...

Now - meaning no disrespect to Erik (clearly he's helped many) wish to present, ''the rest/other side of the story...''

Suspect that the application's demands don't register high enough in your, ''biggest/baddest'' guideline! Certainly - if cadillac part cannot satisfy - chevy has almost no chance...

But wait - having worked in design/sales/legal (engineering then law school) hi-tech - have too often observed that ''desperate - resource restricted'' - someway/somehow ''find a way'' - missed (most always - not properly or ''even'' considered) by ''deeper pockets'' approach. And have observed this effect to extend into device selection - as well. So ''biggest/baddest'' often only ''best'' if effort/focus/imagination/experience retain that level. Frequently - they do not!

Anecdotal - but does demonstrate - our group recently chose an MCU due to its inclusion of analog comparator. (thought vital) And later discovered (to our horror) that 2 were needed. (now what?) Lesson learned - employ the MCU for that which it alone is best equipped - offload other functions to secondary devices - provided cost/size is w/in reason/bounds...

Time to market, competitive posture, price target, availability, development tools and on-going support (and future product development) all should receive scrutiny - and ''biggest/baddest'' may stumble under such weight. (our findings) How does the cost to ''design down'' compare against cost to, ''design up?''

Perhaps worthy of consideration - one size/method ''fits all'' - but likely is never optimal...