3 ms·
PicoPower - I can't tell you the specifics, as comparing power consumption is a bit difficult (you need to figure out which peripherals you need running, whats
by flyinglizard 11y ago
PicoPower - I can't tell you the specifics, as comparing power consumption is a bit difficult (you need to figure out which peripherals you need running, whats the system clock, input voltage, sleep/wakeup regime etc and calculate from there), but they do have STM32L0 series of ultra-low power based on Cortex-M0+.
As to why do I like ST:
1. They are very easy to design boards for. Each IO pin on the Cortex micros maps to up to 16 different internal functions. That gives amazing flexibility from the board design perspective.
2. They have fantastic long term migration paths. You can directly go from Cortex-M3 to Cortex-M4 to Cortex-M7, while, in many cases, retaining package compatibility.
3. They have very good design validation. Their errata sheets are quite shorter than what I remember working with other manufacturers.
4. They have a huge amount of useful IO, such as timers (I have one design using over 15 timer channels) and a quite flexible and powerful ADC architecture.
5. They probably have the widest selection of Cortex microcontrollers in the industry.
There are downsides, too; I generally find their peripherals less advanced than Atmel's (regular CAN instead of CAN-FD, USB inferior to Atmel's, I2C that's really sucky and prone to errors, slower clock and no dual precision FPU on the new F7 family). There was also some story with ST's 2MB flash parts, being not really usable - but I'm not sure what was that about.
Overall you can't go wrong with ST. The long term migration ability and board design flexibility are well worth the downsides.
Coming from an AVR, you're immediately going to get way more memory, much higher clock frequencies, ARM CMSIS libraries (fun if you have any math/DSP going on) and more industry standard tools.
- petra 11y ago>> I2C that's really sucky and prone to errors Is that fixable via software? if not , is it worth the risk ?
- flyinglizard 11y agoYes, you can bitbang your way out of that, but its not great for all applications (like when you want to do DMA to/from the I2C in the background while the processor sleeps or does something else; can't do that with GPIO bitbang). I was really surprised by that when I first encountered it; I2C is something rudimentary.
- akiselev 11y agoUnfortunately STM uses a lot of external silicon IP (all MCU designers have to) from different firms that don't really work well together or are straight up inferior as you mentioned. Their eratta sheets are shorter but I've run into a number of problems that I've worked around with help from their engineers and a year later I still couodnt find any notes on them. I'm guessing they underreport edge case silicon bugs like almost all silicon manufacturers. My last project used a STM32F437 with 100 mbit ethernet, just about saturating the connection at 80mbits while maxing out the processor to interleave the bits of all incoming data and bit banging every GPIO unused by peripherals to control 30k individually adressable LEDs at 45 fps which is just incredible for a $7-10 microcontroller. Then after a few weeks of field testing we identified half a dozen problems all resulting in nondeterministic failures of the DMA or MAC peripheral requiring a hard reset. I think the most problematic one, DMA1 or DMA2 stalling when they tick within 10-20 cycles of each other, is the only one that was added to the errata and still plagues the STM32F4x7 parts. That said if you care about part swapability, developer productivity, and need a very powerful ARM that you're not pushing to the edge, the STM32 line of chips is a great choice.
- flyinglizard 11y agoThat sounds nasty. I've had my share of problem with Atmel parts though when operating at high rates - on their Cortex-M3 and SAM9 there were problems of AHB overruns and data loss when doing fast Ethernet or SPI transfers. No hard lockups though.