Not long ago I
started playing with STM32CubeMX and Eclipse to do some experiments
with the STM32 ARM Cortex M3 processors.
Setting up the
toolchain, the IDE etc was a bit complex, so I decided to create a
youtube video about it, thinking it might be useful for others going
through the same thing.
The reason why I did
things that way was that with my Eclipse/ARM setup I was planning to
use also other (non ST) devices, so it made sense not to use the ST
specific version of the tools, which was also bound to the Mars
eclipse version while I normally use Neon now.
I was wrong.
I mean yes, the
intent made sense, but honestly all the additional hassle to avoid
installing a new Eclipse instance was not worth it.
A couple of days ago I was
lucky enough to participate to an extremely interesting Workshop at
the ST Headquarters in Geneva (Switzerland).
They explained how
to setup the tools,provided a few tips on how to best use them and provided
extremely valuable information.
The workshop was engaging, well paced and indeed informative, kudos to ST
for it ad thanks again for the invitation!
The workshop will be
held in various cities in the next days (at the time I am writing), I
strongly encourage you to participate if you are interested (it is free).
This is the link for
Europe, you might need to search around their website if you are
interested in other regions, there might be something available, not
sure
http://www.st.com/content/st_com/en/about/events/events.html/stm32-ecosystem-emea.html
Now I need to
capture in a new video the “standard/correct way” of doing
things, I do it mainly because it is a sort of collection of minutes
for myself, but then again, others might benefit from it.
ST uses a
proprietary very low cost interface to allow you program and debug
its chips, this interface is called ST-Link, which is basically an
alternative to a standard JTAG (I normally use Jlink from Segger).
All the official
boards include this interface and this allows you to plug in an usb
cable and do all the programming/debugging thanks to a Windows
driver.
No need for
additional hardware.
However, should you
have a non official ST board -that has no usb debugging- with one of
their STM32 chips on it, chances are that it exposes the pins needed
for the ST-Link interface, which you can grab for few bucks (less
that 3$ shipped on ebay).
While a full blown
JTAG device such as the Jlink might provide some more
functionality/speed I have to admit that the cheap ST-Link will
probably get the job done for everybody.
There is an
(optional) utility you can use to upload the binary file on the STM32
flash, using ST-Link, this is called ST-Link utility.
I am saying
“optional” because usually your programming IDE will be able to
do that too, interfacing directly with the ST-Link driver.
When it comes to the
IDE,while there are many different valid options, ST proposes a free
solution based on Eclipse (Mars 2 at the moment).
If you followed my
previous video, you saw that you need to install three main
components with you IDE :
1) The IDE / Code
Editor itself
2) The ARM toolchain
(compiler, builder, linker, make…)
3) The Debugger
interface
The good news part
is that if you choose to go with the ST standard IDE (System
Workbench – SW4) this is all taken care of, since ST packaged an eclipse environment that contains all the needed components.
I strongly recommend
this approach, makes things WAY easier.
System Workbench
comes with the Ac6 STM32 MCU GCC toolchain.
I like Eclipse, I
admit it might be a bit “scary” at the beginning, but it is well
worth spending a little bit of time to learn it since it can be used
in so many different solutions (Coding any language / platform, ETL,
Data Mining…).
With System
Workbench (SW4) you can create your projects, but creating a Cortex
M Project requires a few steps which include adding the relevant
libraries / header files for your specific devices (CMSIS and
additional stuff).
Like most IDEs, SW4
takes care of that, it will simply ask you which device or board you
are targeting.
But it does more
than that, it will automatically allow you to chose which additional
libraries to include or even which middleware (such as freertos).
… but you will
probably not even use those features.
Why? Don’t get me
wrong, they provide tremendous help, but the reason why you may not
want to use them is that you can do the same in an even better and
easier way!
Imagine you were
able to add all the libraries, middlewares, set up the correct stack
and heap map etc, what would be your next step in the project?
These MCUs have an
incredible number of peripherals, you will probably use a few of
those in your project, so the first step is usually to set up the
clock(s) and then enable and configure the multiplexer for the
different pins and the peripherals you need to use.
While it obviously
depends on the complexity of your project, this usually requires
quite a bit of work, what if you could skip most of that?
Actually you can,
let me introduce you to STM32CubeMX.
You are not obliged
to use it, but I cannot imagine a reason why you would not.
For starters:It’s
free and it nicely exchanges information with your IDE (SW4 is
obviously supported, but so are Kyle and IAR).
What the cube does,
is to help you set up your project by doing pretty much the same
thing I said you would skip in the project creation in the IDE, PLUS
it guides you in setting up your peripherals and the clocks.
Once you are
finished, it generates a project dor your IDE with all the
configuration set correctly for you and with a code skeleton that
configures initializes the peripherals you selected.
Usually you decide
upfront which peripherals you need to use and how they should be used
and add your code later, but CubeMX allows you to change your mind.
In fact when it
regenerates the skeleton code, it uses some specific comment tags to
preserve code that you eventually added.
You need to be
careful then, on where you write your code, in the skeleton files
Cube will add lines like these
/*
USER CODE BEGIN 0 */
/*
USER CODE END 0 */
That means that if
you need to add your code, it should be placed between those two
lines, there are many different sections, in different places, where
you can place your code.
As long as you
respect this rule, you can go back to CubeMX, change whatever you
need to change there and regenerate the code, the code you added will
be kept in the new skeleton.
That DID NOT work in
my previous setup (Users Eclipse with ARM GNU Toolchain manually
setup, instead of using SW4), but maybe it was just me messing up
things.
It definitely works
smoothly using SW4.
The final component
is STMStudio.
You can use it to
debug your applcation, this is nto the only option obviosuly, since
the IDE already includes a pretty good debugger, but STMStudio gives
you a nice and simple way of monitoring variables (with graphical
output eventually, sometimes it is useful).
Indeed there are
many ways of customizing this ecosystem, but I found that,
particularly if you are not an expert, it really helps in sticking to
the standards: SW4, STM32CubeMx, ST-link and STMStudio seem to work
very well together.
Here the links to
download them :
ST-Link Drivers -
http://www.st.com/content/st_com/en/products/embedded-software/development-tool-software/stsw-link009.html
ST-Link Utility -
http://www.st.com/content/st_com/en/products/embedded-software/development-tool-software/stsw-link004.html
STM32CubeMX -
http://www.st.com/en/development-tools/stm32cubemx.html
System Workbench -
http://www.st.com/en/development-tools/sw4stm32.html
Happy coding!
The new video is here
2 comments:
Thank you for the post. Helped me alot to make up my mind, on how I might want to start with the ARM/STM32 world in the future.
I am coming from the low level uC world (hard realtime in assembly, building the hardware by myself) and I was now looking on how to start with ARM Cortex M7 for other possible projects with ethernet connection.
Since the ARM-Chips are quite complex (hardware&software) I would need an evaluation board, using AVRStudio in the past would have been my choice, but the AtmelXplain boards appear not so usefull/universal like the ST-Nucleos.
Problem with Nucleos is, that you dont have such a nice "ready to go" IDE/RAD like AVRStudio and the infos out there are all a little bit overwhelming/confusing. Thanks to your post situation looks better.
Thanks again :)
Glad you found it useful. As a matter of fact the STM32 Ecosystem is quite straightforward and the libraries are not bad either. Since you like to control yourself the hardware, you have a good option with the STM32, as you can mix HAL and LL. Actually ST is working to integrate better the two so that in the future all HAL library code will be built on top of LL. It will be generally safe to mix the two in a project.
Post a Comment