mirror of
https://github.com/FreeRTOS/FreeRTOS-Kernel.git
synced 2025-10-17 02:07:48 -04:00
3a5a8e14fc
* CORTEX_MPS2_QEMU_IAR_GCC now has VSCode tasks and launch configurations to build, run, and debug in one button. This should work on all platforms (Linux, MacOS, Windows).
* Posix_GCC Demo now has VSCode task and launch configs to build, run, debug in one button for Linux/MacOS ("lldb Launch").
It also has configuration for Windows through Ubuntu ("gdb launch"), and this will also work for Linux if the user wants to use gdb instead of lldb.
* Integrated terminal settings for Ubuntu and MSYS2 ways to run Posix Demo on Windows.
This allows Posix port demo to be built on either WSL/Ubuntu or MSYS2 on Windows.
These are absolute paths so if the user has installed Ubuntu or MSYS2 elsewhere they will need to change them.
* Improved pattern matching in Run QEMU task. Replaced usage of deprecated ${workspaceRoot} with ${workspaceFolder}.
* Split MSYS2 and Ubuntu WSL configurations
MSYS2 works better with external console, and Ubuntu WSL works with internal console. This is reflected by having two different configurations.
* Delete RTOSDemo.map
Cleanup. (This is file is built but never deleted when make-ing)
* Delete null.d
* Cleanup extranneous vscode workspace
* Documentation for VSCode launch configs
Documentation for how to run this demo on VSCode using launch configs.
* Added documentation for VSCode launch configs
Added documentation for running demo through VSCode using launch configurations.
* Removed unneeded .log files and c_cpp_properties.json in CORTEX_MPS2_QEMU_IAR_GCC/.vscode/
* Deleted unnecessary .log files from POSIX_GCC/.vscode
* Set build task problem matcher to "gcc", deault problem matcher from VSCode.
* Removed unneeded "sh -c -l" command from the default build task in CORTEX_MPS2_QEMU_IAR_GCC.
* "Build QEMU" task problem matcher finds the correct paths to problem files.
* Moved steps to "Prerequisites" section.
* Update Readme.md
Fixed markdown typo.
* Moved items to prerequisites for Posix_GCC demo.
Co-authored-by: Fan <gilbefan@f84d899204e1.ant.amazon.com>
|
||
|---|---|---|
| .. | ||
| .vscode | ||
| .gitignore | ||
| code_coverage_additions.c | ||
| console.c | ||
| console.h | ||
| FreeRTOS-simulator-for-Linux.url | ||
| FreeRTOSConfig.h | ||
| main.c | ||
| main_blinky.c | ||
| main_full.c | ||
| Makefile | ||
| Readme.md | ||
| run-time-stats-utils.c | ||
| trcConfig.h | ||
| trcSnapshotConfig.h | ||
Running with VSCode
Prerequisites
- Install C/C++ extension in VSCode.
- For MacOS or Linux:
- Install gcc.
- Install GNU make utility.
- Install lldb.
- For Windows with Ubuntu WSL:
- Install WSL.
- Install Remote Development Extension Pack.
- For Windows with MSYS2:
- Install MSYS2.
- Install gcc with
pacman -S gcc.
- For all platforms, ensure the required binaries are in PATH with
gcc --version,make --version, and eitherlldb --versionorgdb --version.
On MacOS or Linux
- Open VSCode to the folder FreeRTOS/Demo/Posix_GCC.
- On the VSCode left side panel, select “Run and Debug”. Then select the “Launch lldb” and press the play button to begin debugging.
On Windows using Ubuntu WSL
- Navigate to
FreeRTOS/Demo/Posix_GCCin Ubuntu WSL and usecode .to open the folder in VSCode.- If
codeis not a recognized command, open VSCode and pressCTRL+SHIFT+P. Search for "Shell Command: Install ‘code’ command in Path".
- If
- On the VSCode left side panel, select the “Run and Debug” button. Then select the “Launch GDB Ubuntu WSL” and press the play button. This will build, run, and attach a debugger to the demo program.
- If the demo was previously built by MSYS2, make sure to
make cleanbefore building on Ubuntu WSL.
- If the demo was previously built by MSYS2, make sure to
On Windows using MSYS2
- Open VSCode to the folder
FreeRTOS/Demo/Posix_GCC. - In
.vscode/settings.json, ensure thepathvariable underMSYS2is set to thebash.exeunder your msys64 installation directory. The path should resemble${path to msys2 installation}\\msys64\\usr\\bin\\bash.exe. - On the VSCode left side panel, select the “Run and Debug” button. Then select the “Launch GDB MSYS2” and press the play button to begin debugging.
- If the demo was previously built by Ubuntu WSL, make sure to
make cleanbefore building on MSYS2.
- If the demo was previously built by Ubuntu WSL, make sure to
Profiling your application
Introduction (from the official gprof doc)
Profiling allows you to learn where your program spent its time and which functions called which other functions while it was executing. This information can show you which pieces of your program are slower than you expected, and might be candidates for rewriting to make your program execute faster. It can also tell you which functions are being called more or less often than you expected. This may help you spot bugs that had otherwise been unnoticed.
Requirements
gprof
Version as tested: GNU gprof (GNU Binutils) 2.36
make
Version as tested: GNU Make 3.82
gcc
Version as tested: gcc (GCC) 11.0.0
Generating Profiles
$ make PROFILE=1
Run your application
$ ./build/posix_demo
Since FreeRTOS and its application never come to an end and typically run forever. The user has to kill the application with Ctrl_C when they feel satisfied that the application achieved its intented task. Killing the application will force the profiling file gmon.out to be generated automatically. In order to make sense of this file, the user has to convert the file with:
$ make profile
After running the previous command, two (2) profiling files prof_call_graph.txt and prof_flat.txt will be generated and placed in the build directory.
- prof_call_graph.txt: The call graph shows which functions called which others, and how much time each function used when its subroutine calls are included.
- prof_flat.txt: The flat profile shows how much time was spent executing directly in each function. In order to understand the outputs generated, the best way is to read the official documentation of gprof here
Run your application with Sanitizers
Introduction
- AddressSanitizer, a fast memory error detector. Memory access instructions are instrumented to detect out-of-bounds and use-after-free bugs
- LeakSanitizer, a memory leak detector. This option only matters for linking of executables and the executable is linked against a library that overrides malloc and other allocator functions
Requirements
gcc
Version as tested: gcc (GCC) 11.0.0
Building and Running the Application
$ make SANITIZE_ADDRESS=1
or
$ make SANITIZE_LEAK=1
Then run your program normally.
$ ./build/posix_demo
If an error is detected by the sanitizer, a report showing the error will be printed to stdout.