STM32 alternatives

[Bud]

Well, principles do not magically transform into specific applications. A day will come when you need to implement them on a particular technological platform, and to do that you have to learn the platform.

[NorthGuy]

Well, principles do not magically transform into specific applications. A day will come when you need to implement them on a particular technological platform, and to do that you have to learn the platform.

Not magically, but they make it easy to move into any platform, even for a short period such as a duration of a project.

If, instead, you tie yourself to a specific platform, it'll be very hard to move on. There are many people who bought bunch of PIC16F84 15 years ago, it was their "goto" chip, they were very happy with it, but now it's very hard for them to move on, even to newer PIC16s which are not really dissimilar. ataradov does the same with his SAM D3 chips and risks falling into a similar position 15 years from now.

[Yansi]

I would definitely stick with ARMs unless your applications have very high volumes where PICs or other MCUs may make sense. Or you are space-limited, and want small 6- or 8-pin package.

With mainstream ARMs 14-pins SOIC or TSSOP would be the minimum package size. I don't think anyone makes smaller parts.

Low pin count PICs are very handy for simple tasks such as initializing a PLL or reading a quadrature encoder.

Use STM8 micro for that. Cheap, and very good peripberal set VERY similar to what you find on STM32 family. For anyone knowing how to STM32, this is an obvious choice.

[rhodges]

Use STM8 micro for that. Cheap, and very good peripberal set VERY similar to what you find on STM32 family.

I like STM8. Anyone who is getting started, I invite to look at my public libraries for various devices:

https://github.com/unfrozen/stm8_libs/wiki
http://www.hodges.org/rh/stm8/index.html

These are built with the open source SDCC (Small Device C Compiler).

[ataradov]

Try http://www.microchipdirect.com - it's most likely cheaper than DigiKey, especially in quantities.

I work for Microchip, so I'm aware of MicrochipDirect.  I buy 100-200 pcs at a time, and it is not cheaper in my case. Especially when you factor in shipping.

With DigiKey I add MCUs to other orders, I rarely have to buy them purposefully.

The key to buying with DigiKey is to wait for low prices. Sometimes they need to clear their inventory, and the prices go down by a lot (I assume down to their purchasing price). A couple months ago they were cleaning out old Atmel inventory and a whole bunch of SAM D devices were discounted like 50%. I've got a lot of DAM D21s in TQFP32 package for less than 50 cents.

[james_s]

I still like the 8 bit AVRs, I find them much simpler to use than ARM so where they are adequate you could look into that line, the PIC is another popular one, now that Microchip has acquired Atmel both lines come from the same source. Since C is so standardized these days it's relatively easy to move from one platform to another, at least across similar classes of stuff. I'd say play around with the software toolchain for several different microcontroller families and pick one that you like. It can be quite educational porting code from one platform to another, you can end up more proficient with both. You might play around with some of the very tiny low pin count 8 bitters and see what you can do with one, they can be deceptively powerful.

[fchk]

Most people think of an ancient 8 bit architecture when hearing PIC. They simply don't know that PIC is so much more. There is PIC24/dsPIC, which is a bit like AVR but 16 bit databus and with much more capable peripherials and much faster, and there is PIC32, which is 32 bit MIPS. It is basically the same instruction set and architecture that was used in expensive DEC Unix workstations in the early 90's, just shrunk to the size of a 4mm*4mm QFN package and with twice the speed. (the DECstation 3000 only ran at 20 or 25 MHz, but you get 50MHz at least - top of the line is about 200-300MHz).

The peripherials are very similar across the architectures, so just use parametric search for the right combination of peripherials. Both PIC24 and PIC32/MIPS are very C friendly.

[westfw]

The key to buying with DigiKey is to wait for low prices.

I didn't know that digikey did that (though I've taken advantage of Newark's "closeouts")Does Digikey have a landing page for their "deals", or a search term?

[ataradov]

Does Digikey have a landing page for their "deals", or a search term?

I don't think so. They just drop the prices when they need to flush the inventory. Those D21 in various packages were sitting at low prices for almost a week before all were gone.

This is the exact parts I've got https://www.digikey.com/product-detail/en/microchip-technology/ATSAMD21E15A-AUT/1611-ATSAMD21E15A-AUTCT-ND/6832769 . They are listed as obsolete and a price is $1.85. Well, I've got a 100 of them at 40.5 cents.

All "A" versions were declared obsolete.

[emece67]

.

[thieringpeti]

HI!

I've never used PIC's, but AVR's and STM32's. I think PIC's were a bit outdated architecture, so I don't recommend learning it without a noticable reason. For 8-bit applications, I recommend AVR's or 8051-based MCU families, like the Silicon Labs C8051Fxxx family.
STM32 is a very universal family. It can be easily programmed with lots of compliers, both open source and commercial. If you want to try something different, choose a widely available ARM MCU, like NXP's LPC family 32-bit ARM MCU's. These are very similar to STM32's, and many of the development software also supports them.
And keep in mind, these MCU's can be extremely cheap. Only the chinese internal-market parts (e.g. Padauk 3-cents MCU) can be cheaper than a low-end AVR, PIC or STM32.

[Howardlong]

I’m not sure of the viability of the 3c microcontrollers, unless you’re making super high volume and super low cost designs, or for a passing academic interest. OTP is a big reason to avoid for low to medium volume. I haven’t done any OTP stuff for about fifteen years, in fact I don’t think I know where my eeprom eraser is anymore for those expensive ceramic windowed versions of older OTP devices.

I’m also not sure that you should discount PIC16 just because it’s perceived to be an old architecture. I’d hardly say that the 8051 you’re recommending is new on the block!

Since most people nowadays write predominently in C and not assembly language, much of the underlying nonsense like bank switching is not on the programmer’s radar over 99% of the time. There have been many tweeks to the archtecture over time to improve things particularly for high level language implementation and debugging.

In the end the choice of device is down to many factors, including its features and performance, and availability of skills on the device itself and the toolchains. For example, I haven’t done Silabs 8051 for about 12 years, so it’d be low on my list. I have recently done plenty of NXP and TI M0 and M4F though, some AVR 8 and 32 bit, as well as having a pretty deep experience of the entire PIC range. Undoubtedly that biases my choices.

[nctnico]

I think I phrased poorly. Perhaps it would be better to ask if it would be valuable to add another line to my toolkit. I see that there are some very cheap pic microcontrollers in very small packages that the STM32 lines don't come in. Is it worth learning pic for that reason or are there other arm Lin's that would be a better choice

IMHO TI's MSP430 line is good to have. I use them every now and then if I need something really low power.
If you want to stick with ARM then the LPC1000 series from NXP is interesting as well. Compared to ST's ARMs the microcontrollers from NXP's LPC series use the same peripherals. This means you can re-use low level code from one project to another.

[Karel]

IMHO TI's MSP430 line is good to have. I use them every now and then if I need something really low power.

How do they compare to the STM32l451xx models?
STM claims that they consume 84uA/MHz.
The STM32l452xx models can be used with an external smps and consume 36uA/MHz.

Edit: The above mentioned currents are measured with peripheral clocks disabled.
Worst case, if you enable all clocks for all peripherals, another 100uA/MHz is added. In practice it will be approx. 50uA/MHz.

[Kalin]

Lot's of good info here. It seems like the consensus is to only use the older 8-bitters if you need the low cost or tiny package size. Thanks for everyone who pointed out the 16 bit options, something I had never really looked into. I have an msp430 dev board around somewhere but was never able to get it to work. The TI IDE was pretty confusing and I have to admit I gave up after only a few minutes of trying since I got the board pretty cheap. I think I was trying to use Energia or something but never tried their CCS IDE.

[Peabody]

Lot's of good info here. It seems like the consensus is to only use the older 8-bitters if you need the low cost or tiny package size. Thanks for everyone who pointed out the 16 bit options, something I had never really looked into. I have an msp430 dev board around somewhere but was never able to get it to work. The TI IDE was pretty confusing and I have to admit I gave up after only a few minutes of trying since I got the board pretty cheap. I think I was trying to use Energia or something but never tried their CCS IDE.

I like the MSP430s a lot.  I think 16 bits is the Goldilocks size for microcontrollers, particularly if you ever code in assembler, which I do fairly often.  And they are von Neumann architecture, which is convenient.  While they were at the beginning of the really-low-power movement, I think the others have pretty much caught up.  As for IDEs, CCS is just far too grand for what I do.  I mainly just use a command line assembler.  But I just used Energia for the first time, and it's pretty nifty.  It's an almost direct port of the Arduino IDE for MSP430 and other TI parts.  Seems to work well, and like Arduino, it's basically just GCC.  The main downside of TI stuff is the cost.  They are relatively expensive for what you get.

They also have MSP432, which is low-power ARM, but I've never tried any of those.

[james_s]

I think people often focus too much on something being "old" and therefor inferior. Pencils are old, wheels and levers are old, sometimes they're still a good tool for the job. If you have a simple task that is easily done by an 8 bit microcontroller it doesn't matter how old the architecture is, it's still viable if the part is affordable. For reasons that may not be entirely rational, it bothers me to throw a ton of silicon at a very simple problem even when the monetary cost is not all that much higher. The more complex the part, the more opportunity there is for bugs to creep in. It would be silly to use a 32 bit ARM if all you wanted to do is blink an LED.

[nctnico]

IMHO TI's MSP430 line is good to have. I use them every now and then if I need something really low power.

How do they compare to the STM32l451xx models?
STM claims that they consume 84uA/MHz.
The STM32l452xx models can be used with an external smps and consume 36uA/MHz.

Edit: The above mentioned currents are measured with peripheral clocks disabled.
Worst case, if you enable all clocks for all peripherals, another 100uA/MHz is added. In practice it will be approx. 50uA/MHz.

The MSP430 can run from a watch crystal and get into single digit uA territory while doing something meaningful. What shouldn't be overlooked is time from wake-up to doing something meaningful.

[james_s]

I sat down to play with a cheap MSP430 board I got and after spending a couple hours trying to get the bloated, sluggish IDE and plugins installed, seeing cryptic errors that said to check a log but failing to mention which of numerous logs to check, I gave up, uninstalled everything, set it on the shelf and went back to the AVR.

With any programmable device, try out the software used to develop for it because that is where many seem to fall short and often you are fairly stuck with whatever toolchain is provided.

[nctnico]

I always used MSP-GCC for MSP430. Olimex has a cheap programmer for MSP430 if you have a device which doesn't have the serial bootloader.

[Yansi]

Most people think of an ancient 8 bit architecture when hearing PIC. They simply don't know that PIC is so much more. There is PIC24/dsPIC, which is a bit like AVR but 16 bit databus and with much more capable peripherials and much faster, and there is PIC32, which is 32 bit MIPS. It is basically the same instruction set and architecture that was used in expensive DEC Unix workstations in the early 90's, just shrunk to the size of a 4mm*4mm QFN package and with twice the speed. (the DECstation 3000 only ran at 20 or 25 MHz, but you get 50MHz at least - top of the line is about 200-300MHz).

The peripherials are very similar across the architectures, so just use parametric search for the right combination of peripherials. Both PIC24 and PIC32/MIPS are very C friendly.

16bits MCUs - no thanks really. That was a step in a wrong direction. It is a kind of catdog.

Nowdays, there is not much reason to consider anything less than 32bits, except when really pushing every cent spent or dealing with ultra simple tasks. 32bit MCUs are not expensive. The price is really similar, some times even 32bits may come cheaper to do a task, due to technology improvements over the outdated junk some 8bits are filled with (yes, I am talking to you, microchip).

[ogden]

Nowdays, there is not much reason to consider anything less than 32bits, except when really pushing every cent spent or dealing with ultra simple tasks. 32bit MCUs are not expensive. The price is really similar, some times even 32bits may come cheaper to do a task, due to technology improvements over the outdated junk some 8bits are filled with (yes, I am talking to you, microchip).

I totally agree here. One exception would be already mentioned mass-production where every BOM cent counts. Other exception is market that may require product which is targeted at specific audience/microcontoller. As an example - shields for Arduino.

If someone who already knows stm32 is asking me what's next, I would suggest Cypress Psoc 5 LP. I suggest to not only read leaflet, but get CY8CKIT-059 and play with it's digital and especially analog blocks/peripherals. This is not just another ARM uC, this is way more than that.

[techman-001]

I sat down to play with a cheap MSP430 board I got and after spending a couple hours trying to get the bloated, sluggish IDE and plugins installed, seeing cryptic errors that said to check a log but failing to mention which of numerous logs to check, I gave up, uninstalled everything, set it on the shelf and went back to the AVR.

With any programmable device, try out the software used to develop for it because that is where many seem to fall short and often you are fairly stuck with whatever toolchain is provided.

Agreed, but how about a GPL'd fast tethered Forth for that MSP430 ? All you need is a Tiva Connected Launchpad, which also programs the MSP430 via JTAG ...

http://hightechdoc.net/mecrisp-across/_build/html/index.html

[NorthGuy]

Nowdays, there is not much reason to consider anything less than 32bits, except when really pushing every cent spent or dealing with ultra simple tasks. 32bit MCUs are not expensive. The price is really similar, some times even 32bits may come cheaper to do a task, due to technology improvements over the outdated junk some 8bits are filled with (yes, I am talking to you, microchip).

I don't think the number of bits is an important selection criteria - rather you select the MCU by the set of periphery (and its speed), number of pins, shape, perhaps power consumption, etc. Even for the people who use assembler, the number of bits isn't that important - rather they would seek a specific architecture. For people who write in C, the number of bits doesn't make any difference whatsoever. Even if it did, the majority of C writers try to be platform independent, so they write to the standard (such as C99) and try to avoid thinking of MCU peculiarities. Moreover, the majority of C/C++ writers don't even have enough skills to evaluate how a particular CPU architecture would affect their code.

[ataradov]

I don't think the number of bits is an important selection criteria - rather you select the MCU by the set of periphery (and its speed), number of pins, shape, perhaps power consumption, etc.

It just so happens that you get more and better of everything with 32-bit MCUs. So looking first at 32-bit devices is a good selection strategy.

And just not having to think whether to use uint8_t or uint16_t for your loop variable is very nice. Even with C/C++ if you care about performance of your code, you have to think about underlying device.