preamble
Why configure such an environment? I have had enough of Keil5 that simple working environment, really can not be used, debugging is very easy with the CubeMX code to produce a series of problems caused by inconsistencies in debugging - release code. CubeIDE is good, but its code to assist the function and the build system is really not to be commended, often Makefile is not synchronized with the symbol definition conflicts, or buried potential program bugs. Often the Makefile is not synchronized, resulting in symbol definition conflicts, or buried potential program bugs.
Some people also try to use Keil Assistance + VSCode + Keil division of labor to write code and burn-in, which sounds good, but debugging is not convenient, and often have to go back and forth, is really some trouble. Here we try the emerging PlatformIO to assist us in embedded development.
present (sb for a job etc)
PlatformIO
Your Gateway to Embedded Software Development Excellence — PlatformIO latest documentation
Platform is based on the VScode text editor, using the vscode powerful extension extension function, so that developers can directly call gcc, jlink, gdb, etc. in vscode development, debugging. platformIO is just an integrated development environment, its own almost does not include any substantial features. Includes any substantial features , but it integrates a lot of such as compilers , debuggers , etc., mainly including the following:
- vscode
- gcc compiler, version: arm-none-eabi-gcc (proprietary c compiler for arm kernel embedded devices)
- arm-none-eabi-gdb debugger
- jlink driver
- Scons build tool,
That is to say, PlatformIO is a working environment similar to Keil, STMCudeIDE, it is not responsible for compiling, uploading, debugging and testing, but it encapsulates our common arm-noeabi-series of tools, eliminating the need for us to learn the complexity of the configuration syntax, and unifying the configuration language of PlatformIO. PlatformIO configuration language, so we can write PlatformIO configuration language to help build our embedded programs.
STM32CubeMX
STM32CubeMX - STM32Cube initialization code generator - STMicroelectronics
STM32CubeMX is a graphical tool for 32-bit ARM Cortex STM32 microcontrollers. It allows very simple configuration of STM32 microcontrollers and microprocessors, generates initialization C-code, and also generates part of the Linux device tree for the Arm Cortex-M core or the Arm Cortex-A core in a step-by-step procedure. It is part of the STMCube ecosystem and can be integrated in the development environment (STM32CubeIDE) as a standalone application or as an Eclipse plug-in.
It can do things are very simple: that is, we will configure the embedded device from the code configuration process to the GUI configuration, point and click to press the button, you can generate a series of initialization code to assist us in completing the tedious initialization task!
Visual Studio Code
Visual Studio Code - Code Editing. Redefined
Visual Studio Code is a lightweight and powerful source code editor with support for syntax highlighting, code auto-completion (aka IntelliSense), code refactoring, view definitions, and built-in command line tools and Git version control system. Available for Windows, macOS, and Linux, it has built-in support for JavaScript, TypeScript, and and a rich ecosystem of extensions for other languages and runtimes (e.g., C++, C#, Java, Python, PHP, Go, .NET). In order not to interfere with the reader's immersive reading and learning, if you need to use the catalog please just use it on the left side.
main body (of a book)
We are going to implement a simple light-up task using STM32F103ZET6 as the target microcontroller! Let's see how we can configure the project.
Using STM32CubeMX to generate Makefiles that PlatformIO can support
Our initialization code is generated by STM32CubeMX, and here we complete these configurations:
About how to download and install STM32CubeMX is not the focus of this article, please look at the official separate Baidu!
Click on the circled area to select the target embedded device
Lock on target board (↓)
I've bookmarked commonly used boards here so I can find them quickly, if you don't have them, just search for the board's model number.
Click on the target board's column to see our familiar interface.
1. Select target pins and configure
We need to select the target pin and then complete the relevant configurations, I chose here on my development board on the PE5 pin to drive the connection on the microcontroller, the pin configuration needs to be combined with the hardware circuit for selection
Here, I set up: pull-up output, high speed mode
2. Configuring the clock tree
I chose to use an external crystal clock, configured at 72MHz
3. [Key! Debugging requires:]Selecting the debugger type
Serial Wire is the author's choice, I only have STLink on hand to use, if the looker has is the JLink debugger, please according to the
SYS configuration options in STM32-HAL library CubeMX_cubmx does not configure sys debug-CSDN blog
Make relevant choices! This step is quite critical!
4. Select the corresponding target IDE configuration code and files
See for yourself.Set up the project namecap (a poem)Folders where projects are stored, both of which will be used later in the PIO configuration! Please pay high attention!
TIPS: If you don't want to copy all the libraries, you can choose the appropriate configuration in the Code Generator section:
Below we generate the code
You can see that all the necessary underlying library files have been copied, so let's move on to VSCode + PIO.
Building our STM32 development environment with PlatformIO
Open VSCode, PlatformIO is available for download in the Plugin Market.
Watch the first click to download, make a cup of coffee, the download is very slow! (I have downloaded it here) After the installation, this will appear on your left toolbar.
Click on it:
This is PlatformIO! We can interface our STM32 generated code with PIO below. Click on New Project:
I'll go over the items that need to be filled out in there one by one:
- Project name: exactly the same as the project name you filled in for CubeMx.
- Target board: same as CubeMx model number
- Frame: this is talking about how to do the read behavior, we are using the CubeMX generated code, so the target frame we use is STM32Cube
- Location:First of all the Default Location to delete, we need to choose in just under the CubeMx selected folder, you can see that we in just the author chose in the
D:\MDK5 Project\CubeMx Trainingg\demo_under which all the code continues to be generated in theD:\MDK5 Project\CubeMx Trainingg\demo_\${ProjectName}\Below.Our directory under PIO is then selected to theD:\MDK5 Project\CubeMx Trainingg\demo_This position.This is because he also generates${ProjectName}\...folder, we do this so that the files generated by PIO and the files generated by CubeMx are in the root directory of the project, making it easier for us to write and read the files.
Click Finish to here, the first time to download friends will download the relevant tool chain, I was downloading up to half an hour, please be patient, you can go out for a walk! After waiting until the end of the tool chain configuration, generate the project is a matter of a split second.
Now the generation is over!
Let's take a look at the file below.
; PlatformIO Project Configuration File
;
; Build options: build flags, source filter
; Upload options: custom upload port, speed and extra flags
; Library options: dependencies, extra library storages
; Advanced options: extra scripting
;
; Please visit documentation for the other options and examples
; /page/
[env:genericSTM32F103ZE]
platform = ststm32
board = genericSTM32F103ZE
framework = stm32cube
This is the template that PlatformIO generates for us by default, but there is no way to compile our project with this alone, we need to modify it ourselves.
After a brief exploration, the author has integrated the following configuration:
Using the author's configuration
PlatformIO Project Configuration File
;
; Build options: build flags, source filter
; Upload options: custom upload port, speed and extra flags
; Library options: dependencies, extra library storages
; Advanced options: extra scripting
; Advanced options: extra scripting ;
; Please visit documentation for the other options and examples
; /page/
The ; src_dir tells us where the big source files of our project are located, and it is a match for the platformio module
; /en/latest/projectconf/sections/platformio/options/directory/src_dir.html
[platformio]
src_dir = . /Core/
;Target board: STM32F103ZE
[env:genericSTM32F103ZE]
platform = ststm32
board = genericSTM32F103ZE
framework = stm32cube
; -Idir is the directory of include files, which follows the GCC syntax.
build_flag is essentially a compilation parameter for arm-noeabi-gcc, added directly, so it follows the GCC syntax directly
build_flags =
-ICore/Inc
; select the link file, our STM32 after power on to execute a startup script
board_build.ldscript = . /STM32F103ZETx_FLASH.ld
; Here is the configuration of the upload tool
The default upload protocol used by PlatformIO is stlink, and the default debug protocol is still stlink, this is the reason why I didn't write it out.
; If the debugger you have is JLink, then you need to display the specified: [see your own comments].
; upload_protocol=jlink
; debug_tool=jlink
If you only have USB < - > TTL on hand, then it is
; upload_protocol=serial
; It is worth noting that some boards do not support certain protocols, which is related to the open source libraries used by PlatformIO, go to
; /en/latest/boards/#boards
Search for your board to see what protocols are supported for uploading and debugging.
There is another copy that is a widely spread configuration:
PlatformIO Project Configuration File
;
; Build options: build flags, source filter
; Upload options: custom upload port, speed and extra flags
; Library options: dependencies, extra library storages
; Advanced options: extra scripting
; Advanced options: extra scripting ;
; Please visit documentation for the other options and examples
; /page/
Comments in the configuration file begin with a semicolon.
[platformio]
; Move the compilation directory of the source code to the project directory, otherwise it defaults to src
src_dir = . /
[env:genericSTM32F103ZE] ; move the source code compilation directory to the project directory, otherwise it defaults to src.
platform = ststm32
board = genericSTM32F103ZE
; framework = stm32cube (don't use framework anymore)
Compile configuration -D is the macro definition, -Idir is the include file directory, readers can change according to their own project structure.
Here's a quick comment: this approach can be very cumbersome! You have to specify all the include directories in turn!
If there are already supported frameworks, please prioritize the use of platformIO's supported frameworks!
build_flags =
-D STM32F103xE ; Predefined macros, which you can understand by adding #define STM32F103xE to the beginning of everything!
-ICore/Inc ; Includes the path to the source files.
-IDrivers/CMSIS/Include
-IDrivers/CMSIS/Device/ST/STM32F1xx/Include
-IDrivers/STM32F1xx_HAL_Driver/Inc ; Contains the path to the source file -IDrivers/CMSIS/Include
-IDrivers/STM32F1xx_HAL_Driver/Inc/Legacy
;Select the path where the compiled files are located, this contains the source file path, boot file, driver library and rtos path. If +<*> is the path of all the files, -<.git/> is to ignore the files under the .git path.
build_src_filter = +<Core/Src> +<startup_stm32f103xe.s> +<Drivers/> +<Middlewares/> ;Select the link file.
;Select the link file
board_build.ldscript = . /STM32F103ZETx_FLASH.ld
Let's just light the lamp directly below, under Core/Src/:
// I chose the pull-up mode, the light to pull down the GPIO level
HAL_GPIO_WritePin(LED1_GPIO_Port, LED1_Pin, GPIO_PIN_RESET);; HAL_GPIO_WritePin(LED0_GPIO_Port, LED0_Pin, GPIO_PIN_RESET)
HAL_GPIO_WritePin(LED0_GPIO_Port, LED0_Pin, GPIO_PIN_RESET).
We compile and run it below.You can either Ctrl + Shift + P to enter PlatformIO:BuildTo start building, you can also click on the toolbar below VSCode:
Start with the little house icons, in that order:
- PlatformIO Main Page
- construct (sth abstract)
- upload
- clear up
- Testing (unit testing)
- Serial Monitor
- endpoint
- sports event
- Port settings for uploading (just leave them untouched by default)
The rest are plug-ins for other languages written by the author, so please disregard them.
The author's demonstration below builds the project by clicking on the√horn (wind instrument)
Processing genericSTM32F103ZE (platform: ststm32; board: genericSTM32F103ZE; framework: stm32cube)
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: /page/boards/ststm32/
PLATFORM: ST STM32 (17.4.0) > STM32F103ZE (64k RAM. 512k Flash)
HARDWARE: STM32F103ZET6 72MHz, 64KB RAM, 512KB Flash
DEBUG: Current (blackmagic) External (blackmagic, cmsis-dap, jlink, stlink)
PACKAGES:
- framework-stm32cubef1 @ 1.8.4
- tool-ldscripts-ststm32 @ 0.2.0
- toolchain-gccarmnoneeabi @ 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> /configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 29 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Compiling .pio\build\genericSTM32F103ZE\FrameworkHALDriver\Src\stm32f1xx_hal.o
...
Compiling .pio\build\genericSTM32F103ZE\FrameworkCMSISDevice\gcc\startup_stm32f103xe.o
Compiling .pio\build\genericSTM32F103ZE\FrameworkCMSISDevice\system_stm32f1xx.o
Archiving .pio\build\genericSTM32F103ZE\
Indexing .pio\build\genericSTM32F103ZE\
Linking .pio\build\genericSTM32F103ZE\
Checking size .pio\build\genericSTM32F103ZE\
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM: [ ] 0.1% (used 44 bytes from 65536 bytes)
Flash: [ ] 0.5% (used 2724 bytes from 524288 bytes)
Building .pio\build\genericSTM32F103ZE\
================================================================= [SUCCESS] Took 4.93 seconds =================================================================
appeared[SUCCESS] characters, it means that our project builds smoothly, otherwise, please check your own project configuration problems in turn. A common one is redefinition, please make sure you don't repeatedly include source files that cause symbol redefinition!
Below we click->Upload the project to the board!
Please make sure you have a debugger connected (mine is STLink) and the board is powered up before uploading!
Processing genericSTM32F103ZE (platform: ststm32; board: genericSTM32F103ZE; framework: stm32cube)
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: /page/boards/ststm32/
PLATFORM: ST STM32 (17.4.0) > STM32F103ZE (64k RAM. 512k Flash)
HARDWARE: STM32F103ZET6 72MHz, 64KB RAM, 512KB Flash
DEBUG: Current (blackmagic) External (blackmagic, cmsis-dap, jlink, stlink)
PACKAGES:
- framework-stm32cubef1 @ 1.8.4
- tool-dfuutil @ 1.11.0
- tool-dfuutil-arduino @ 1.11.0
- tool-ldscripts-ststm32 @ 0.2.0
- tool-openocd @ 3.1200.0 (12.0)
- tool-stm32duino @ 1.0.2
- toolchain-gccarmnoneeabi @ 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> /configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 29 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Checking size .pio\build\genericSTM32F103ZE\
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM: [ ] 0.1% (used 44 bytes from 65536 bytes)
Flash: [ ] 0.5% (used 2724 bytes from 524288 bytes)
Configuring upload protocol...
AVAILABLE: blackmagic, cmsis-dap, dfu, jlink, serial, stlink
CURRENT: upload_protocol = stlink
Uploading .pio\build\genericSTM32F103ZE\
xPack Open On-Chip Debugger 0.12.0-01004-g9ea7f3d64-dirty (2023-01-30-15:04)
Licensed under GNU GPL v2
For bug reports, read
/doc/doxygen/
debug_level: 1
hla_swd
[] halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x08000bf8 msp: 0x20010000
** Programming Started **
Warn : Adding extra erase range, 0x08000c90 .. 0x08000fff
** Programming Finished **
** Verify Started **
** Verified OK **
** Resetting Target **
shutdown command invoked
================================================================= [SUCCESS] Took 2.75 seconds =================================================================
As expected, the little light comes on and here we end our tutorial!
Some issues that may arise in uploading
- The board's not powered up.
- STLink is not plugged in properly! Or STLink is abnormal, causing OpenOCD can not be initialized, please check the port!
- Problems with uploading programs using the USB to TTL interface
Thanks to the SourceForge guys for the answer, I then immediately realized that I had done something really stupid, I had forgotten to change the board to bootloader burn mode, which caused the board to not accept usb burns at all.
stm32flash / Tickets / #134 STM32L462 "Failed to init device" problem ()
Please refer to your own manual about BOOT pin configuration!
So, I need to change the BOOT0 pin to 3.3V up, upload the program, restore the BOOT pin all the way to ground to run the program, and sure enough:
Processing genericSTM32F103ZE (platform: ststm32; board: genericSTM32F103ZE; framework: stm32cube)
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: /page/boards/ststm32/
PLATFORM: ST STM32 (17.4.0) > STM32F103ZE (64k RAM. 512k Flash)
HARDWARE: STM32F103ZET6 72MHz, 64KB RAM, 512KB Flash
DEBUG: Current (blackmagic) External (blackmagic, cmsis-dap, jlink, stlink)
PACKAGES:
- framework-stm32cubef1 @ 1.8.4
- tool-dfuutil @ 1.11.0
- tool-dfuutil-arduino @ 1.11.0
- tool-ldscripts-ststm32 @ 0.2.0
- tool-openocd @ 3.1200.0 (12.0)
- tool-stm32duino @ 1.0.2
- toolchain-gccarmnoneeabi @ 1.70201.0 (7.2.1)
LDF: Library Dependency Finder -> /configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 29 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Checking size .pio\build\genericSTM32F103ZE\
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM: [ ] 0.1% (used 44 bytes from 65536 bytes)
Flash: [ ] 0.5% (used 2716 bytes from 524288 bytes)
Configuring upload protocol...
AVAILABLE: blackmagic, cmsis-dap, dfu, jlink, serial, stlink
CURRENT: upload_protocol = serial
Looking for upload port...
Auto-detected: COM8
Uploading .pio\build\genericSTM32F103ZE\
stm32flash 0.4
/
Using Parser : Raw BINARY
Interface serial_w32: 115200 8E1
Version : 0x22
Option 1 : 0x00
Option 2 : 0x00
Device ID : 0x0414 (High-density)
- RAM : 64KiB (512b reserved by bootloader)
- Flash : 512KiB (sector size: 2x2048)
- Option RAM : 16b
- System RAM : 2KiB
Write to memory
Erasing memory
Wrote address 0x08000100 (7.98%)
Wrote address 0x08000200 (15.96%)
...
Wrote address 0x08000b00 (87.78%)
Wrote address 0x08000c00 (95.76%)
Wrote address 0x08000c88 (100.00%) Done.
Starting execution at address 0x08000000... done.
adjust components during testing
Stop here for those who only have serial port burn-in.
Debugging is extremely easy, we just need to follow the classic clicks:
After making sure your board and debugger are powered up, you can happily debug!