Table of contents
- 1 What is a suitable integrated development environment for ARM MCU (STM32) beginners to study?
- 2 Firmware library
- 3 Development Tools for STM32 MCUs
- 4 Building the STM32CubeIDE
- 5 Create a project that incorporates the Firmware library SPL
- 6 Include path
- 7 Compile-Link-Build
- 8 Transfer
- 9 Self and Cross Environments
What is a suitable integrated development environment for ARM MCU (STM32) beginners to study?
After choosing MCU to start learning about MCUs, the next challenge is about MCU development environment.
- What do I need to prepare to create a program?
- What should I do with MCU and peripheral hardware (interface) on which the created program will run?
- How can I use the tool to transfer the created program to the MCU?
I think that's all there is to it specifically.
When I first started embedded systems, I targeted the STM32 MCU and had quite a bit of trouble gathering information on specific tools for development.
The development environment for the STM32 MCUs is so popular worldwide. Therefore, it was difficult to narrow down which development environment was most suitable for me, not because there were no choices but rather because there were too many choices.
Even now, information on development environments, including useful tools, has increased, making it increasingly difficult for beginners to know which one to start with. I would like to introduce some of the tools that I have found to be the best ones to use for the time being, while reviewing the points of choice I have made.
I has also built an STM32 development environment based on Eclipse, a free comprehensive development environment platform, in order to build a development environment with no usage restrictions. Once stable and flexible, it was easy to use and full of a sense of self-satisfaction, but when the microcomputer specifications were changed, it was quite troublesome and time-consuming to rebuild the project and specify the compiler.
If building a handmade development environment is your hobby, it may be a good idea, but if you want to prioritize your work or study, you should spend your valuable time on acquiring skills and avoid building your own development environment.
A Firmware library called the Standard Peripheral Library (SPL) has been available for the STM32 series for some time. This library is well written, and there are many articles on the Internet and in books that explain how to use it, so you can obtain sufficient information on how to use it. I recommend this library for learning microcontrollers because it is hardware-oriented and concrete.
In contrast, the Firmware libraries in the latest development environment tools have been redesigned to support the latest MCUs (libraries called HAL and LL as opposed to SPL), and therefore should be used for new development of new MCUs in the future.
Also, HAL code is abstracted and should be used after understanding it in SPL. If you use HAL and LL after you have mastered the basics of MCUs with SPL, you will be able to easily transition to HAL and LL. Please sit back and work hard to solidify your foundation.
The common feature of Mbed, a development environment for Arduino and ARM MCUs that transcends the boundaries between manufacturers, is the abstraction of the hardware interface part to enable easy MCU development. The HAL library combined with the STM32's automatic code generation function is a similar environment, and while it facilitates development, it hides the interface part, so I do not think it is suitable for people who want to learn the basics of manufacturing, especially microcontrollers, to use from the beginning.
It is suitable for engineers with a certain level of knowledge and experience to easily and advantageously develop prototypes, for hobby-oriented electronics work that requires only operation even if the contents are not well understood, and for student development sites. If you use MCU in your work, you cannot apply it without the basics, so I encourage you to use SPL, which is close to hardware, for your libraries.
Once you are somewhat familiar with the STM32 microcontroller through SPL, I think it is a good idea to start using STM32CubeIDE the way it is supposed to be used (HAL library and automatic code generation). If you have a good foundation in SPL, it is easy to port to HAL and other platforms.
Development Tools for STM32 MCUs
The best IDE for STM32 is(was) TrueSTUDIO, the official IDE of STMicro, which is Eclipse-based and very easy to use. It used to be a development environment with no functional limitations, and everything from the compiler to the debugger is all-in-one, making it easy to achieve everything from program creation to program transfer.
As of this writing, STM32CubeIDE, which integrates the TrueSTUDIO IDE and the STM32CubeMX auto-generation tool, is the mainstream genuine ST Micro IDE. At the same time, TrueSTUDIO has been non-encouragement for new development.
Under these circumstances, we think the best choice is to use this STM32CubeIDE to familiarize yourself with it for future use. However, it does not support the Standard Peripheral Library (SPL), so we will use a manually configured one.
Thus, development environments are updated or fully remodeled as technology evolves. In order to adopt the latest MCUs and start a new development project, it is necessary to have the latest development environment and it is important to acquire the skills to deal with it.
The purpose of this site is to help beginners in embedded technology learn the basics of using MCUs by using the STM32, a 32-bit MCU with an ARM core, as a teaching aid. Then, I will use the STM32CubeIDE integrated development environment with the firmware library SPL for the target MCU.
STM32CubeIDE also includes the latest tools such as automatic code generation. However, since the code generated is from the HAL library, it would be very useful to use this tool in a development environment where the firmware library SPL can be used and the basic skills of the STM32 have been mastered.
It is difficult to master all the features out of the box, and you will be swamped by tools. It is best to use the latest tools only when there is enough information available on the Internet to make it easy to use them. Save the fun for later.
Among the several methods available for writing program transfers to the microcontroller, the SWD method ST-Link/V2 is used. Details are explained in "Development Environment" and "Implementation. ST-Link/V2 is included in NUCLEO-F103RB, which is used as a teaching material board in this site.
Building the STM32CubeIDE
Target MCU：ARM Cortex-M3 STM32F103RB(NUCLEO-F103RB)
Here we build a specification that incorporates SPL and FreeRTOS as a development environment for using the educational material (Nucleo-STM32F103RB) on this site. This is probably the most nimble development environment specification for the STM32CubeIDE.
It takes some initial effort, but once the project is built and works successfully, it can be converted from one application to another.
Although not used in this site, STM32CubeIDE also has an automatic code generation function, so you can try it after you become somewhat familiar with it.
The Internet provides sufficient information on downloading and installing STM32CubeIDE, which is used as a development environment for STM32 microcontrollers, so we will not go into details.
In the mid-installation process, there is a ST-Link related component check box that must be checked. The SEGGER-Jlink driver is not used and may be unchecked.
Create a project that incorporates the Firmware library SPL
After the source file in C code is completed, build is performed to compile, link, and create an executable file.
Click on the menu "Project" - "Build Project" to create the executable file.
Compile is the process of converting a source file written in C code into an object code file. The converted file has a .o extension and is stored in the "Debug" folder in the project.
If the build is successful without any errors, a "Binaries" folder will be created in the project tree and there should be a file with the extension elf. At the same time, a binary executable file with the extension bin is also created. Now all that is left is to transfer the executable file to the microcontroller using the debugger ST-Link.
MCU will function only after the executable file created by the build is transferred (written) to the flash memory of the microcontroller. The ST-LINK device is used as the transfer tool.
SWD method of the ARM communication standard is used to exchange data with the microcontroller side; SWD is a method of writing data with two signals (SWCLK and SWDIO).
ST-LINK(V2) tool for transfer is USB on the PC side, and two signal lines of SWD and GND on the microcontroller side.
ST-LINK V1 does not work with STM32CubeIDE, so V2 or higher is required.
The above has been explained from the construction of the development environment for the STM32 microcontroller to program transfer. Now, please try to actually operate the STM32 microcontroller and experience it through a certain amount of trial and error until the transfer writing completes smoothly and normally.
Although it is unlikely that any program, including a program, will succeed in transferring data the first time, there is always a cause for any problem, and being able to find the cause and solve it on your own is one of the skills you need to develop.
I will not explain the specifics of STM32CubeIDE operations (compiler, build, and transfer methods) here, but there is a wealth of information available on the Internet on this subject. Since STM32CubeIDE is based on eclipse, information related to eclipse may be useful.
This section describes terms commonly used in the embedded development environment. These are not essential terms, but you may hear them often, so please take a moment to familiarize yourself with them.
Self and Cross Environments
Self-environment is an environment where the development environment and execution environment are the same, for example, application development using Visual C# on a PC. In contrast, a cross-environment is an environment where the development environment and execution environment are separate, and applications are developed on a separate PC for embedded devices that do not have their own development environment. Embedded devices use a variety of CPUs and OSs, so development is performed in a cross-environment.
"Why I recommend STM32Nucleo instead of Arduino for beginners in MCU learning" explains the advantageous points about the learning method using the development environment employed on this site.