The STM32 line of microcontrollers – usually seen in the form of an ST Discovery dev board – are amazingly powerful and very popular micros seen in projects with some very hefty processing and memory requirements. Now, ST has released a great way to try out the STM32 line with the Nucleo board.
There are two really great features about these new Nucleo boards. First, they’re mbed compatable, making them a great way to get started in the ARM development world. Secondly, they have Arduino pin headers right on the board, giving you access to all your shields right out of the box.
Right now, there are four varieties of the Nucleo board based on the STM32F030, -F103, -F152, and -F401 microcontrollers. The STM32F401 is the high-powered variant, An ARM Cortex-M4 microcontroller running at 84 MHz, 512kB of Flash, and enough I/O for just about any project.
If you’d like to get your hands on one of the STM32 Nucleo boards, you can order a voucher to pick one up at Embedded World in Germany next week. Otherwise, you’re stuck ordering from Mouser or Farnell. Bonus: the high-end F401-based board is only $10 USD.
32-bit microcontrollers are slower than 8-bit AVRs so they clock them with higher frequencies. I’ll stick with my good old Arduino.
Once you deal with quantities larger than 8 bits, the 16 and 32 bit processors have a huge edge. Granted, there are still lots of applications where that’s not the case and an 8 bit is more than appropriate.
In what alternative reality is an ARM is slower than an 8-bit AVR when running at the same frequency?
It’s because he says so. Don’t you believe him?
Well if you multiply the speed of the Arduino by gagea’s IQ this factor in his learning curve handy cap, carry the one and round upwards, then for him Arduino may be faster.
Imagine if you will a world where the Cortex bus connecting the STM32 core to its GPIOs has a 2 clock cycle delay. In this world, much like our own, AVR bit banging is twice as fast at the same clock frequency. Only the M0+ cores have a faster bus allowing single-cycle pin access.
how fast you can toggle a pin is a very very narrow definition of faster, and since an STM32F4 uses abut 1/4 the power per MHz you could toggle that pin twice as fast as an AVR using the same power
You can sort of treat it as a pipeline as the pending I/O cycles are affected the same way, so you can start toggling other I/O before the changes get propagated to the actual pins.
The AVR has an output delay of 1 cycle. Figure 14-4 It has up to 1 cycle of input delay. Fig 14-3. for ATmega 328.
Don’t forget that the chips can be clocked very much higher frequency than the AVR and can do fancy bit masking on its GPIO . If you are not plain bitbanging, the peripherals are much more powerful and faster than the AVR and you can use DMA for peripherals and GPIO.
Take a reel of InGaAs amplifiers and you can ‘toggle a pin’ at maybe 50 to 100 GHz. Magnitude faster than any microcomputers to date!
in the arduino world, hue
Is that the same world people use the Arduino digitalRead()!?
Until *everybody* in the world start accessing I/O directly and uses all kinds of tricks such as unrolling their bitbanging loops or recoding stuff in assembly (see V-USB), this is not something that is critical to the average users.
There are side-by-side speed comparisons of these vs Arduino. Blows Arduino away. Far, far, away.
I’ve never used the ST’s STM32. Can anyone comment on the level of support in GCC for the processor?
Seem’s pretty good, i got up and running on an STM32F4 without much hassle using the gcc-arm-embedded toolchain (had good support for the floating point unit which was nice). libopencm3 is worth checking out as well, it’s a really nice firmware library for the STM32 range of micro-controllers.
If you have already used ARM you’ll get up and running quickly. If not, you’ll be stuck in the datasheet for a bit (even getting gpio set up is more involved that the 8-bit micros I was used to).
But either way the gnu toolchains work very well with this family of chips.
@Mike Szczys If you use the libopencm3 firmware libraries there’s some good quality example code available here: https://github.com/libopencm3/libopencm3-examples
It was my first time doing ARM stuff and I managed to avoid digging through datasheets pretty much entirely just by playing with and re-purposing those examples. I also hear that ST’s firmware libraries leave a lot to be desired.
ST Libraries are written cleanly, very useable and without errors. Best of all, they sare free. I use them in production code without any problem. Please indicate where you find that they leave a lot to be desired.
Support is great with gcc-arm-embedded toolchain. There is also a great eclipse plugin that integrates with OpenOCD, which works great with the cheap st-link programmer. The micros themselves do require a bit more boilerplate code / register setup before getting up and running (compared to an avr), but it’s definitely worth it for more complex projects!
https://launchpad.net/gcc-arm-embedded
http://sourceforge.net/projects/gnuarmeclipse/
There’s a reasonably good (I hope; I wrote it) introduction to using GCC and Eclipse to program STM32 parts here: http://thehackerworkshop.com/?p=391. An update for the F4 series of parts is here: http://thehackerworkshop.com/?p=1056
http://www.emblocks.org/web/ Has lots of support for the ST parts and bet they will add support for these boards real quick they did for the 429 Disco board.
I give up on em:blocks, I was going to extend some features in it but forum reply to others requests put me off (and others…):
Re: How to build Em::Blocks from source Postby EmBlocks Feb 14, 2014
…That’s why the focus isn’t on building and that’s why you are on your own by building the tools. I can’t/wont support all those questions about building errors etc also…
and:
“All the open parts are available at the SVN and a “how to build” can be found at the codeblocks wiki. The pre-build SDK and plugin development “toolkit” should be available in the future. ” (I will not even go into the GPL violations here…)
I understand that this is a ‘Windows’ only fork of Code:Blocks for bare-metal gcc-arm, but the single dev on the project is not interested in outside contribs and thus dealing with bugs/features/etc… will leave most embedded beginners lost.
As others in this thread posted, go grab Eclipse and add the embedded plugins. Great community support, period. Most of the Arm licensors are using Eclipse plugins (Look at FreeScale’s great Process Expert as an example).
That said, I am not a huge Eclipse fan, and do not use it for NON-embedded C/C++, but, again, the ARM based integrators, vendors and community make it very livable.
If you are looking for another Windows only Code:Blocks fork and just happen to ONLY use Segger’s J-Link/J-Trace for your debugger, emIDE might just an a good option.
I don’t think that this is a real issue. CooCox is, despite it’s name ‘open’ as closed as Fort Knox and is still the de facto free tool for ARM. EmIDE is only accepting Jlink because it’s from Segger and you can use code::blocks with a commercial embedded debugger plugin which you have to pay.
The question is if something works right, I don’t know how good it is compared to others but what I do know is, that it is very active. I did several bug reports and a feature request, all very fast solved.
It definitely works for me.
Compatible, with an I not a A.
Also, an A not a A.
http://joyreactor.com/post/742383
indeed
The freescale freedom is a particular favourite of mine for this purpose, mbed compatible, arduino compatible, built in accelerometer, buttons, rgb led, cap sense pad. 5v compatible i/o, comes without the headers soldered, has little sticky feet and is cheap as chips!
It’s pretty misleading to call a board “Arduino Compatible” when there’s no software to support actually running Arduino sketches & libraries. Even if the 4 sockets that fit the form-factor of Arduino shields matter, this board lacks the 6 pin header that modern Arduino shields use to get the SPI signals, so it can’t work with popular shields like Ethernet.
I’m sure it has lots of great features, and the $10 price is amazing (or a loss-leader promotion). I’d expect ST to the Arduino-like features, and indeed they carefully say “leveraging … Arduino ecosystems to accelerate software and hardware development”. I would hope Hack-a-Day’s editors would know better than to call a board without any Arduino software support “Arduino Compatible”.
You make a valid point. But if you’re working with this you’re probably going to be skilled enough to port libraries for it.
This is probably a “Linux is a kernel and an OS” type of thing: Arduino is a hardware platform and an IDE/software library.
Indeed, I’ve seen products marketed as Arduino-compatible when they’ve had only hardware or software compatibility, but not both. I think the best nomenclature so far is “Arduino compatible” for software and “Shield compatible” for hardware/form factor compatibility.
Even if you consider pure hw compatibility you will encounter several issues.
I tried to use simple DFrobot prototype shield where buttons are connected to the analog input (to save digital inputs). The DFrobot board is powered from 5V so the analog input is driven by voltage up to about 4V (so you cannot connect this board to the nucleo because the input voltage of STM32 A/D cannot exceed the Vcc). It requires to change the button-resistor ladder Vcc to 3.3V). So PCB soldering is required.
Another example: the AtMega328 has different multi-function pins than STM32 so to have I2C or ADC na specific pins as in original arduino you need to solder / remove some bridges on PCB to route the STM32 pin to specific arduino connector).
Just use LeafLabs libmaple (has ports for STM32F1,F2,F3,F4) with gcc-arm-embedded and there you have basic Arduino compatibility on the software side, too.
http://leaflabs.com/docs/libmaple.html
*”Arduino form-factor compatible”
This board has 4 SPIs which they are completely independent, none of Arduino board has this feature, even Due.
These SPIs run up to 48Mhz.
It tolerate 4 volts which Arduino Due doesn’t
I tested Arduino Shield WiFi from Adafruit with ST Nucleo F401RE works great
Not sure in 2014, but in 2017 they are programmable via Arduino IDE just like any other Arduino board. I’d say that was pretty software compatible.
This chip makes my dick rock hard.
Will make yours soft once you see those awful libs from ST.
Put your pants back on, there is no need to use the ST libraries. There are alternatives.
Also check out https://github.com/andysworkshop/stm32plus
The ST-provided firmware library is a bit tedious. On these chips you have to individually configure every single pin (by initializing a C struct and passing to the firmware library), and remember to enable the peripheral clocks, before they can be used. By comparison the simpler AVR requires much less setup code. However the STM32 line is powerful and well priced; I like that a lot of the parts have a built in DAC.
Ha, I referenced the same pin config issues above. Glad I’m not the only one who found that process a bit of a trial!
You can configure multiple pins at once but I agree it’s a little tedious.
What’s really sad is that they don’t have a separate voltage reference pin below the 100 pin packages although the low pin count ones have a DAC and ADC.
If you use ST CubeMX, which is a graphical MCU configuration editor, you can create a GPIO init file that has everything in it. Plug the file in your build set-up and you’re ready to go.
You don’t have to use the firmware library at all. You can save yourself some time and code by manipulating the registers directly from your code. Every micro requires you to set each pin as an input, output, etc, so that’s no different than any other micro. What is different is the STM32 parts have more options (input/output/alternate function, pullup/pulldown/nopull, pushpull/open drain, skew rate) than many other micros.
Do you mean slew rate instead of skew rate? :)
I didn’t finish reading the article or the comments,
I went to Mouser and ordered a couple.
If you want to program STM32 Microcontrollers and are willing to get used to a special C++ style you should checkout the xpcc library: https://fosdem.org/2014/schedule/event/the_xpcc_microcontroller_framework/
There are some examples for the stm32f3 and stm32f4 discoveryboard:
https://github.com/roboterclubaachen/xpcc/tree/develop/examples
Thanks for sharing this. It looks very exciting.
Any idea if code written for the STM32F407VGT6 Discovery Kit is pin compatible with the new STM32F401 based Nucleo board?
I don’t have either, but I’ve seen some projects that use the STM32F4 Discovery Board with M$ .NET Micro Framework (Cortex M4) and I’ve been thinking of getting one to try. It’d be nice if the Nucleo board could also be used for that too!
I’m still a fan of ARMstrap boards (which is basically a BlackMagic probe coupled with a STM32F4 ARM chip). They work better on Mac, Linux and Windows and their licensing allows you to actually *use* and *sell* your final product.
Why isn’t there a 5V logic level ARM IC that’s both cheaper, more powerful and with better software support than a humble Atmega?
They all seem to suffer from lack of at least one of those factors.
Erm, how about because as IC process technology gets smaller logic levels have to be reduced. The latest chips are running 1.2V logic. 5V logic is archaic and even 3.3V is starting to fade. It’s the same reason that it’s getting progressively harder to source through hole mount ICs as surface mount is taking over.
As for libraries, as even Arduino have decided that the ARM chip is the way forward (the current Due and forthcoming Tre are based on them) so much Arduino code will run on them already.
It Tre really based on an ARM chip? I mean for the Arduino programmable side which you actually program with the Arduino IDE, not the Linux part. The last info I saw on their website said it had a AVR 32u4 (same as Leonardo) for the Arduino side.
Did they change that? Long-term, it’d be awesome if they made the transition to the same chip as Due.
Hmm, looks like you are right about the microcontroller half, they are still using the 32u4 for inexplicable reasons (they could have least used an ATMEGA2560, instead making something with underpowered IO like the YUN)
The yun does the same as the tre and offloads to an AtMega, sure you dont mean the Galileo?
No, the YUN like the Tre uses the ATMEGA for pin/GPIO IO (I’m not talking about network IO). The 32u4 is lightweight in pins, RAM and ROM.
32u4 has a programmable amplifier on the ADC pins – which makes it more useful than the Uno variants. IMHO
Small geometries means they can make more chips per wafer (cheaper) or pack more transistors into same area, get more speed out of circuit and lower power (more powerful). The trade off for these advantages is that the voltages the transistors can handle is getting lower for smaller geometry. This had been going on for longer than some of the people here, so ditch your 5V stuff already.
For the software support, that’s a marketing/support question…
I wish we could hack Atmel Studio to work with other vendor’s ARM chips. :(
Visual Studio wont do? It supports C projects with custom makefiles which could invoke one of the various arm toolchains if you wish.
I am using Atmel Studio for a new revision of my old design, but the hardware wasn’t as fast as my old non-AVR rev. so that I have to go back. Been spoiled by AS6 that Programmer’s Editor I used to be using before seems lacking now. So I added the custom makefile as a different “solution” to my AS project. It actually work very nicely. The lack of debugger/simulation isn’t an issue as I didn’t have that previously.
What I am hoping is that all the hard work that Atmel put into making Visual Studio to work could be extended to other ARM chips to have the debugger working too. Legal issues aside, someone would need to hack in those XML files and back end etc.
For 5V compatible ARM chip, you can check Freescale Kinetis MKE02 chips and associated FRDM-KE02Z board (http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=FRDM-KE02Z).
NXP (the old Philips) make a range of LPCxxxx chips which are 3.3V ARM microcontrollers with 5V-tolerant input pins. They’re programmed via a built-in serial bootloader. The LPC1114 is even available in 28-pin DIP.
I have the 1114 in 28 pin DIP, did not realise it was 5v IO tolerant although its not like me treating it as non 5v tolerant is going to harm it :P Awesome little chip.
Most STM32 GPIO pins are 5V tolerant, except for pins connected to analog peripherals.
As expected from ST, a great board for the price. Shame about the Arduino-compatible form factor though. I have neither an allegiance to Arduino nor an aversion to jumper wires, so the form factor only means to me that the board is about twice as large as necessary.
Can anyone tell me how this is different from discovery boards? I’m drooling over STM32 for a couple of weeks already and this nucleo business just throws me out – should I get a giscovery board or one of nucleos?
If you are new and you want to get started right away, the Discovery boards have more software available and there are more tutorials, blogs, articles, etc. about them. The Nucleo boards will probably be as well supported someday, but not yet.
but both of them have the same selection of MCUs? As far as I can tell, Discoveries have more bells and whistles while Nucleo is just a micro on a board and a separable debugger.
It looks like you can snap off the debugger, but there doesn’t appear to be any way to program it after you’ve done this. There’s no power connector either.
What’s unusual here is that ST has installed the LSE crystal for the Nucleo boards, which they do not do in the Discovery boards. Alas without a battery holder we won’t be able to take full advantage of it.
These Nucleo boards appear to be just about completely devoid of external peripherals (unlike the Discovery boards) so their development environment would probably work well with other boards, too.
mbed.org is currently DOWN, now I remember why I prefer the compiler on my computer.
;-) I had fun with mbed for a couple of days as it is a neat cloud concept… but also ran into ‘online availability’ issues with their site.
Once was the connection I was on as it was bouncing on/off and caused their ‘ide’ to get confused, and than I had complete timeouts/hangs on their site two days in a row…Did an “Export” on my project for my ‘off-line’ toolchain and did not look back… :-(
Dear HaD. I would like to inform you of a revolutionary new software product – it’s called a “spelling checker” – it is a fairly new technology – I would estimate no more than, say, 6 decades old…
If you try it you might find it very “compatible” with your work process.
Just don’t trust that spelling checker too much. It’s unlikely to find anything wrong in sentences like “The dog did not jumped on it’s tail because its whey to short four that”. It’s safer to use your own brain.
LOL – Obviously using “their” brain didn’t work in this instance – also even the best brain occasionally makes a typo – BTW none of my errors are ever spelling mistakes – they are always “typos” ;-) Let’s just say the brain and a spelling checker are a pretty good combination if you are trying to publish professional looking articles.
I do agree that spelling checkers are useful. They ought to catch things like ‘awfull’, ‘aweful’ and ‘compatable’. These should not appear in an article, let alone a headline.
Perhaps by analogy with passionate / compassionate, ‘compattable’ might be acceptable coinage. (-:
My wife’s aunt is a proofreader for the executives of a major corporation…
Let’s just say her skills are NEEDED with that group of people. B^)
With all the talk of libraries/toolchains/IDEs above I’m surprised not to see more mention of mbed, which supports these boards. It’s great for rapidly knocking something together, with a load of cool libs. For those wanting a one-line “configure this pin and drive/wiggle/read/sample it”, mbed will scratch that itch.
Be aware – the USB interface’s debug channel and virtual COM port channel on these boards are intermittent in operation. The debug channel periodically loses communications with the host PC with a USB communications error and the virtual COM port does not always deliver all of its data to the PC host. The missing data is not lost, just delayed until the next data is sent from the board to the PC host. I’ve never had any problems like this on the various T.I. LaunchPad or Arduino boards I’ve used!
Has anyone been able to get the Nucleo’s to work with .Net Micro Framework? I can’t seem to get Windows to install the drivers once I flash the bootloader.