neulab/tldr huggingface dataset:
TI LaunchPad MSP-EXP430FR2311LP has on-board debug probe and IS READY for debugging. You don't need to use/buy external debug probe.
TI LaunchPad MSP-EXP430FR2433LP Contents • TI LaunchPad MSP-EXP430FR2433LP
┌────────────────┬──────────────┐ │Microcontroller │ MSP430FR2433 │ ├────────────────┼──────────────┤ │Frequency       │ 8MHz         │ ├────────────────┼──────────────┤ │Flash           │ 15KB         │ ├────────────────┼──────────────┤ │RAM             │ 4KB          │ ├────────────────┼──────────────┤ │Vendor          │ TI           │ └────────────────┴──────────────┘
Configuration Please use lpmsp430fr2433 ID for projectconf_env_board option in projectconf:
[env:lpmsp430fr2433] platform = timsp430 board = lpmsp430fr2433
You can override default TI LaunchPad MSP-EXP430FR2433LP settings per build environment using board_*** option, where *** is a JSON object path from board manifest lpmsp430fr2433.json. For example, board_build.mcu, board_build.f_cpu, etc.
; change microcontroller board_build.mcu = msp430fr2433
TI LaunchPad MSP-EXP430FR2433LP has on-board debug probe and IS READY for debugging. You don't need to use/buy external debug probe.
TI LaunchPad MSP-EXP430FR4133LP Contents • TI LaunchPad MSP-EXP430FR4133LP
┌────────────────┬──────────────┐ │Microcontroller │ MSP430FR4133 │ ├────────────────┼──────────────┤ │Frequency       │ 8MHz         │ ├────────────────┼──────────────┤ │Flash           │ 15KB         │ ├────────────────┼──────────────┤ │RAM             │ 2KB          │ ├────────────────┼──────────────┤ │Vendor          │ TI           │ └────────────────┴──────────────┘
Configuration Please use lpmsp430fr4133 ID for projectconf_env_board option in projectconf:
[env:lpmsp430fr4133] platform = timsp430 board = lpmsp430fr4133
You can override default TI LaunchPad MSP-EXP430FR4133LP settings per build environment using board_*** option, where *** is a JSON object path from board manifest lpmsp430fr4133.json. For example, board_build.mcu, board_build.f_cpu, etc.
; change microcontroller board_build.mcu = msp430fr4133
TI LaunchPad MSP-EXP430FR4133LP has on-board debug probe and IS READY for debugging. You don't need to use/buy external debug probe.
TI LaunchPad MSP-EXP430FR5969LP Contents • TI LaunchPad MSP-EXP430FR5969LP
┌────────────────┬──────────────┐ │Microcontroller │ MSP430FR5969 │ ├────────────────┼──────────────┤ │Frequency       │ 8MHz         │ ├────────────────┼──────────────┤ │Flash           │ 47KB         │ ├────────────────┼──────────────┤ │RAM             │ 2KB          │ ├────────────────┼──────────────┤ │Vendor          │ TI           │ └────────────────┴──────────────┘
Configuration Please use lpmsp430fr5969 ID for projectconf_env_board option in projectconf:
[env:lpmsp430fr5969] platform = timsp430 board = lpmsp430fr5969
You can override default TI LaunchPad MSP-EXP430FR5969LP settings per build environment using board_*** option, where *** is a JSON object path from board manifest lpmsp430fr5969.json. For example, board_build.mcu, board_build.f_cpu, etc.
; change microcontroller board_build.mcu = msp430fr5969
TI LaunchPad MSP-EXP430FR5969LP has on-board debug probe and IS READY for debugging. You don't need to use/buy external debug probe.
TI LaunchPad MSP-EXP430FR5994LP Contents • TI LaunchPad MSP-EXP430FR5994LP
┌────────────────┬──────────────┐ │Microcontroller │ MSP430FR5994 │ ├────────────────┼──────────────┤ │Frequency       │ 16MHz        │ ├────────────────┼──────────────┤ │Flash           │ 256KB        │ ├────────────────┼──────────────┤ │RAM             │ 4KB          │ ├────────────────┼──────────────┤ │Vendor          │ TI           │ └────────────────┴──────────────┘
Configuration Please use lpmsp430fr5994 ID for projectconf_env_board option in projectconf:
[env:lpmsp430fr5994] platform = timsp430 board = lpmsp430fr5994
You can override default TI LaunchPad MSP-EXP430FR5994LP settings per build environment using board_*** option, where *** is a JSON object path from board manifest lpmsp430fr5994.json. For example, board_build.mcu, board_build.f_cpu, etc.
; change microcontroller board_build.mcu = msp430fr5994
TI LaunchPad MSP-EXP430FR5994LP has on-board debug probe and IS READY for debugging. You don't need to use/buy external debug probe.
TI LaunchPad MSP-EXP430FR6989LP Contents • TI LaunchPad MSP-EXP430FR6989LP
┌────────────────┬──────────────┐ │Microcontroller │ MSP430FR6989 │ ├────────────────┼──────────────┤ │Frequency       │ 8MHz         │ ├────────────────┼──────────────┤ │Flash           │ 47KB         │ ├────────────────┼──────────────┤ │RAM             │ 2KB          │ ├────────────────┼──────────────┤ │Vendor          │ TI           │ └────────────────┴──────────────┘
Configuration Please use lpmsp430fr6989 ID for projectconf_env_board option in projectconf:
[env:lpmsp430fr6989] platform = timsp430 board = lpmsp430fr6989
You can override default TI LaunchPad MSP-EXP430FR6989LP settings per build environment using board_*** option, where *** is a JSON object path from board manifest lpmsp430fr6989.json. For example, board_build.mcu, board_build.f_cpu, etc.
; change microcontroller board_build.mcu = msp430fr6989
TI LaunchPad MSP-EXP430FR6989LP has on-board debug probe and IS READY for debugging. You don't need to use/buy external debug probe.
TI LaunchPad MSP-EXP430G2 w/ MSP430G2231 Contents • TI LaunchPad MSP-EXP430G2 w/ MSP430G2231
┌────────────────┬─────────────┐ │Microcontroller │ MSP430G2231 │ ├────────────────┼─────────────┤ │Frequency       │ 1MHz        │ ├────────────────┼─────────────┤ │Flash           │ 2KB         │ ├────────────────┼─────────────┤ │RAM             │ 256B        │ ├────────────────┼─────────────┤ │Vendor          │ TI          │ └────────────────┴─────────────┘
Configuration Please use lpmsp430g2231 ID for projectconf_env_board option in projectconf:
[env:lpmsp430g2231] platform = timsp430 board = lpmsp430g2231
You can override default TI LaunchPad MSP-EXP430G2 w/ MSP430G2231 settings per build environment using board_*** option, where *** is a JSON object path from board manifest lpmsp430g2231.json. For example, board_build.mcu, board_build.f_cpu, etc.
; change microcontroller board_build.mcu = msp430g2231
; change MCU frequency board_build.f_cpu = 1000000L
TI LaunchPad MSP-EXP430G2 w/ MSP430G2231 has on-board debug probe and IS READY for debugging. You don't need to use/buy external debug probe.
TI LaunchPad MSP-EXP430G2 w/ MSP430G2452 Contents • TI LaunchPad MSP-EXP430G2 w/ MSP430G2452
┌────────────────┬─────────────┐ │Microcontroller │ MSP430G2452 │ ├────────────────┼─────────────┤ │Frequency       │ 16MHz       │ ├────────────────┼─────────────┤ │Flash           │ 8KB         │ ├────────────────┼─────────────┤ │RAM             │ 256B        │ ├────────────────┼─────────────┤ │Vendor          │ TI          │ └────────────────┴─────────────┘
Configuration Please use lpmsp430g2452 ID for projectconf_env_board option in projectconf:
[env:lpmsp430g2452] platform = timsp430 board = lpmsp430g2452
You can override default TI LaunchPad MSP-EXP430G2 w/ MSP430G2452 settings per build environment using board_*** option, where *** is a JSON object path from board manifest lpmsp430g2452.json. For example, board_build.mcu, board_build.f_cpu, etc.
; change microcontroller board_build.mcu = msp430g2452
TI LaunchPad MSP-EXP430G2 w/ MSP430G2452 has on-board debug probe and IS READY for debugging. You don't need to use/buy external debug probe.
TI LaunchPad MSP-EXP430G2553LP Contents • TI LaunchPad MSP-EXP430G2553LP
┌────────────────┬─────────────┐ │Microcontroller │ MSP430G2553 │ ├────────────────┼─────────────┤ │Frequency       │ 16MHz       │ ├────────────────┼─────────────┤ │Flash           │ 16KB        │ ├────────────────┼─────────────┤ │RAM             │ 512B        │ ├────────────────┼─────────────┤ │Vendor          │ TI          │ └────────────────┴─────────────┘
Configuration Please use lpmsp430g2553 ID for projectconf_env_board option in projectconf:
[env:lpmsp430g2553] platform = timsp430 board = lpmsp430g2553
You can override default TI LaunchPad MSP-EXP430G2553LP settings per build environment using board_*** option, where *** is a JSON object path from board manifest lpmsp430g2553.json. For example, board_build.mcu, board_build.f_cpu, etc.
; change microcontroller board_build.mcu = msp430g2553
TI LaunchPad MSP-EXP430G2553LP has on-board debug probe and IS READY for debugging. You don't need to use/buy external debug probe.
TI TIVA TI LaunchPad (Stellaris) w/ lm4f120 (80MHz) Contents • TI LaunchPad (Stellaris) w/ lm4f120 (80MHz)
Hardware Platform platform_titiva: Texas Instruments TM4C12x MCUs offer the industrys most popular ARM Cortex-M4 core with scalable memory and package options, unparalleled connectivity peripherals, advanced application functions, industry-leading analog integration, and extensive software solutions.
┌────────────────┬───────────────┐ │Microcontroller │ LPLM4F120H5QR │ ├────────────────┼───────────────┤ │Frequency       │ 80MHz         │ ├────────────────┼───────────────┤ │Flash           │ 256KB         │ ├────────────────┼───────────────┤ │RAM             │ 32KB          │ ├────────────────┼───────────────┤ │Vendor          │ TI            │ └────────────────┴───────────────┘
Configuration Please use lplm4f120h5qr ID for projectconf_env_board option in projectconf:
[env:lplm4f120h5qr] platform = titiva board = lplm4f120h5qr
You can override default TI LaunchPad (Stellaris) w/ lm4f120 (80MHz) settings per build environment using board_*** option, where *** is a JSON object path from board manifest lplm4f120h5qr.json. For example, board_build.mcu, board_build.f_cpu, etc.
; change microcontroller board_build.mcu = lplm4f120h5qr
TI LaunchPad (Stellaris) w/ lm4f120 (80MHz) has on-board debug probe and IS READY for debugging. You don't need to use/buy external debug probe.
┌───────────────────────┬──────────┬─────────┐ │Compatible Tools       │ On-board │ Default │ ├───────────────────────┼──────────┼─────────┤ │debugging_tool_ti-icdi │ Yes      │ Yes     │ └───────────────────────┴──────────┴─────────┘
TI LaunchPad (Tiva C) w/ tm4c123 (80MHz) Contents • TI LaunchPad (Tiva C) w/ tm4c123 (80MHz)
┌────────────────┬────────────────┐ │Microcontroller │ LPTM4C1230C3PM │ ├────────────────┼────────────────┤ │Frequency       │ 80MHz          │ ├────────────────┼────────────────┤ │Flash           │ 256KB          │ ├────────────────┼────────────────┤ │RAM             │ 32KB           │ ├────────────────┼────────────────┤ │Vendor          │ TI             │ └────────────────┴────────────────┘
Configuration Please use lptm4c1230c3pm ID for projectconf_env_board option in projectconf:
[env:lptm4c1230c3pm] platform = titiva board = lptm4c1230c3pm
You can override default TI LaunchPad (Tiva C) w/ tm4c123 (80MHz) settings per build environment using board_*** option, where *** is a JSON object path from board manifest lptm4c1230c3pm.json. For example, board_build.mcu, board_build.f_cpu, etc.
; change microcontroller board_build.mcu = lptm4c1230c3pm
TI LaunchPad (Tiva C) w/ tm4c123 (80MHz) has on-board debug probe and IS READY for debugging. You don't need to use/buy external debug probe.
TI LaunchPad (Tiva C) w/ tm4c129 (120MHz) Contents • TI LaunchPad (Tiva C) w/ tm4c129 (120MHz)
┌────────────────┬─────────────────┐ │Microcontroller │ LPTM4C1294NCPDT │ ├────────────────┼─────────────────┤ │Frequency       │ 120MHz          │ ├────────────────┼─────────────────┤ │Flash           │ 1MB             │ ├────────────────┼─────────────────┤ │RAM             │ 256KB           │ ├────────────────┼─────────────────┤ │Vendor          │ TI              │ └────────────────┴─────────────────┘
Configuration Please use lptm4c1294ncpdt ID for projectconf_env_board option in projectconf:
[env:lptm4c1294ncpdt] platform = titiva board = lptm4c1294ncpdt
You can override default TI LaunchPad (Tiva C) w/ tm4c129 (120MHz) settings per build environment using board_*** option, where *** is a JSON object path from board manifest lptm4c1294ncpdt.json. For example, board_build.mcu, board_build.f_cpu, etc.
; change microcontroller board_build.mcu = lptm4c1294ncpdt
TI LaunchPad (Tiva C) w/ tm4c129 (120MHz) has on-board debug probe and IS READY for debugging. You don't need to use/buy external debug probe.
WIZNet W7500 WIZwiki-W7500 Contents • WIZwiki-W7500
Hardware Platform platform_wiznet7500: The IOP (Internet Offload Processor) W7500 is the one-chip solution which integrates an ARM Cortex-M0, 128KB Flash and hardwired TCP/IP core for various embedded application platform especially requiring Internet of things
┌────────────────┬────────────┐ │Microcontroller │ WIZNET7500 │ ├────────────────┼────────────┤ │Frequency       │ 48MHz      │ ├────────────────┼────────────┤ │Flash           │ 128KB      │ ├────────────────┼────────────┤ │RAM             │ 48KB       │ ├────────────────┼────────────┤ │Vendor          │ WIZNet     │ └────────────────┴────────────┘
Configuration Please use wizwiki_w7500 ID for projectconf_env_board option in projectconf:
[env:wizwiki_w7500] platform = wiznet7500 board = wizwiki_w7500
You can override default WIZwiki-W7500 settings per build environment using board_*** option, where *** is a JSON object path from board manifest wizwiki_w7500.json. For example, board_build.mcu, board_build.f_cpu, etc.
; change microcontroller board_build.mcu = wiznet7500
Uploading WIZwiki-W7500 supports the next uploading protocols:
WIZwiki-W7500 has on-board debug probe and IS READY for debugging. You don't need to use/buy external debug probe.
WIZwiki-W7500ECO Contents • WIZwiki-W7500ECO
┌────────────────┬───────────────┐ │Microcontroller │ WIZNET7500ECO │ ├────────────────┼───────────────┤ │Frequency       │ 48MHz         │ ├────────────────┼───────────────┤ │Flash           │ 128KB         │ ├────────────────┼───────────────┤ │RAM             │ 48KB          │ ├────────────────┼───────────────┤ │Vendor          │ WIZNet        │ └────────────────┴───────────────┘
Configuration Please use wizwiki_w7500eco ID for projectconf_env_board option in projectconf:
[env:wizwiki_w7500eco] platform = wiznet7500 board = wizwiki_w7500eco
You can override default WIZwiki-W7500ECO settings per build environment using board_*** option, where *** is a JSON object path from board manifest wizwiki_w7500eco.json. For example, board_build.mcu, board_build.f_cpu, etc.
; change microcontroller board_build.mcu = wiznet7500eco
Uploading WIZwiki-W7500ECO supports the next uploading protocols:
WIZwiki-W7500ECO has on-board debug probe and IS READY for debugging. You don't need to use/buy external debug probe.
WIZwiki-W7500P Contents • WIZwiki-W7500P
┌────────────────┬─────────────┐ │Microcontroller │ WIZNET7500P │ ├────────────────┼─────────────┤ │Frequency       │ 48MHz       │ ├────────────────┼─────────────┤ │Flash           │ 128KB       │ ├────────────────┼─────────────┤ │RAM             │ 48KB        │ ├────────────────┼─────────────┤ │Vendor          │ WIZNet      │ └────────────────┴─────────────┘
Configuration Please use wizwiki_w7500p ID for projectconf_env_board option in projectconf:
[env:wizwiki_w7500p] platform = wiznet7500 board = wizwiki_w7500p
You can override default WIZwiki-W7500P settings per build environment using board_*** option, where *** is a JSON object path from board manifest wizwiki_w7500p.json. For example, board_build.mcu, board_build.f_cpu, etc.
; change microcontroller board_build.mcu = wiznet7500p
Uploading WIZwiki-W7500P supports the next uploading protocols:
WIZwiki-W7500P has on-board debug probe and IS READY for debugging. You don't need to use/buy external debug probe.
Custom Platform & Board Custom Development Platforms PlatformIO can build the same binary code under different host systems via the single command cmd_run without any dependent software or requirements.
A manifest describes how to produce binaries for a particular platform under one or multiple host systems by a set of build scripts, toolchains, the settings for the most popular embedded boards, etc.
This guide explains how to write manifests, to support building for new development platforms.
Step-by-Step Manual
1. Choose Packages for platform
2. Create Manifest File platform.json
3. Create Build Script main.py
4. Finish with the Installation.
Contents • Custom Development Platforms
• Manifest File platform.json
• Build Script main.py
• Installation
Packages Some tools are the same when compiling for several platforms, for example a common compiler. A package is some tool or framework that can be used when compiling for one or multiple platforms. Even if multiple platforms use the same package, the package only needs to be downloaded once. Since each package is pre-built for the different host systems (Windows, Mac, Linux), developers can get started without first compiling the tools.
PlatformIO has a registry with pre-built packages for the most popular operating systems and you can use them in your platform manifest. These packages are stored in the super-fast and reliably CDN storage provided by JFrog Bintray.
Each platform definition must define packageRepositories to link to package manifest files that lists how PlatformIO can download the used packages. To use the pre-built packages, include http://dl.platformio.org/packages/manifest.json in the packageRepositories list. Platform definitions can also use custom packages.
Manifest File platform.json Each platform definition includes a manifest file with a particular format that is parsed by PlatformIO when handling projects using that platform.
Here is an example platform.json for the fictitious platform "myplatform":
{ "name": "myplatform", "title": "My Platform", "description": "My custom development platform", "url": "http://example.com", "homepage": "https://platformio.org/platforms/myplatform", "license": "Apache-2.0", "engines": { "platformio": "~3.0.0" }, "repository": { "type": "git", "url": "https://github.com/platformio/platform-myplatform.git" }, "version": "0.0.0", "packageRepositories": [ "https://dl.bintray.com/platformio/dl-packages/manifest.json", "http://dl.platformio.org/packages/manifest.json", { "my_custom_package": [ { "url": "http://dl.example.com/my_custom_package-darwin_x86_64-1.2.3.tar.gz", "sha1": "bb7ddac56a314b5cb1926cc1790ae4de3a03e65c", "version": "1.2.3", "system": [ "darwin_x86_64", "darwin_i386" ] }, { "url": "http://dl.example.com/my_custom_package-linux_aarch64-1.2.3.tar.gz", "sha1": "127ddac56a314b5cb1926cc1790ae4de3a03e65c", "version": "1.2.3", "system": "linux_aarch64" } ], "framework-%FRAMEWORK_NAME_1%": [ { "url": "http://dl.example.com/packages/framework-%FRAMEWORK_NAME_1%-1.10607.0.tar.gz", "sha1": "adce2cd30a830d71cb6572575bf08461b7b73c07", "version": "1.10607.0", "system": "*" } ] } ], "frameworks": { "%FRAMEWORK_NAME_1%": { "package": "framework-%FRAMEWORK_NAME_1%", "script": "builder/frameworks/%FRAMEWORK_NAME_1%.py" }, "%FRAMEWORK_NAME_N%": { "package": "framework-%FRAMEWORK_NAME_N%", "script": "builder/frameworks/%FRAMEWORK_NAME_N%.py" } }, "packages": { "toolchain-gccarmnoneeabi": { "type": "toolchain", "version": ">=1.40803.0,<1.40805.0" }, "framework-%FRAMEWORK_NAME_1%": { "type": "framework", "optional": true, "version": "~1.10607.0" }, "framework-%FRAMEWORK_NAME_N%": { "type": "framework", "optional": true, "version": "~1.117.0" }, "tool-direct-vcs-url": { "type": "uploader", "optional": true, "version": "https://github.com/user/repo.git" } }, "pythonPackages": { "pypi-pkg-1": "1.2.3", "pypi-pkg-2": ">=2.3, <3" } }
Build Script main.py Each platform definition must include a main.py.
PlatformIO's build script is based on a next-generation build tool named SCons. PlatformIO has its own built-in firmware builder env.BuildProgram with deep library search. Please see the following template as start for developing your own main.py.
""" Build script for test.py test-builder.py """
from os.path import join from SCons.Script import AlwaysBuild, Builder, Default, DefaultEnvironment
env = DefaultEnvironment()
# A full list with the available variables # http://www.scons.org/doc/production/HTML/scons-user.html#app-variables env.Replace( AR="ar", AS="gcc", CC="gcc", CXX="g++", OBJCOPY="objcopy", RANLIB="ranlib",
UPLOADER=join("$PIOPACKAGES_DIR", "tool-bar", "uploader"), UPLOADCMD="$UPLOADER $SOURCES" )
env.Append( ARFLAGS=["..."],
ASFLAGS=["flag1", "flag2", "flagN"], CCFLAGS=["flag1", "flag2", "flagN"], CXXFLAGS=["flag1", "flag2", "flagN"], LINKFLAGS=["flag1", "flag2", "flagN"],
CPPDEFINES=["DEFINE_1", "DEFINE=2", "DEFINE_N"],
LIBS=["additional", "libs", "here"],
BUILDERS=dict( ElfToBin=Builder( action=" ".join([ "$OBJCOPY", "-O", "binary", "$SOURCES", "$TARGET"]), suffix=".bin" ) ) )
# The source code of "platformio-build-tool" is here # https://github.com/platformio/platformio-core/blob/develop/platformio/builder/tools/platformio.py
# # Target: Build executable and linkable firmware # target_elf = env.BuildProgram()
# # Target: Build the .bin file # target_bin = env.ElfToBin(join("$BUILD_DIR", "firmware"), target_elf)
# # Target: Upload firmware # upload = env.Alias(["upload"], target_bin, "$UPLOADCMD") AlwaysBuild(upload)
# # Target: Define targets # Default(target_bin)
Installation Using the "myplatform" platform example above:
1. Create a platforms directory in projectconf_pio_core_dir if it doesn't exist.
2. Create a myplatform directory in platforms
3. Copy the platform.json and builder/main.py files to the myplatform directory.
4. Search the available platforms via the cmd_platform_search command. You should see the new myplatform platform.
5. Install the myplatform platform via the cmd_platform_install command.
Now, you can use myplatform as value for the projectconf_env_platform option in projectconf.
Examples Please take a look at the source code of existing PlatformIO Development Platforms.
Custom Embedded Boards PlatformIO has pre-built settings for many popular embedded boards. The list of these boards is available as a web page at PlatformIO Boards Explorer or through the CLI command cmd_boards.
Custom boards can also be defined from scratch or by overriding settings of existing boards. All data is declared using the JSON syntax via associative array name/value pairs.
Contents • Custom Embedded Boards
• JSON Structure
JSON Structure The key fields are:
• build data is handed over to the platforms and frameworks builders
• frameworks is the list with supported frameworks. Each working environment for each project that uses the board will choose one of the frameworks declared here.
• platform name of platforms
• upload upload settings which depend on the platform
For details, see existing boards as examples, available under .platformio/platforms/*/boards/.
{ "build": { "extra_flags": "-DHELLO_PLATFORMIO", "f_cpu": "16000000L", "hwids": [ [ "0x1234", "0x0013" ], [ "0x4567", "0x0013" ] ], "mcu": "%MCU_TYPE_HERE%" }, "frameworks": ["%LIST_WITH_SUPPORTED_FRAMEWORKS%"], "platforms": ["%LIST_WITH_COMPATIBLE_PLATFORMS%"] "name": "My Test Board", "upload": { "maximum_ram_size": 2048, "maximum_size": 32256 }, "url": "http://example.com", "vendor": "MyCompany" }
Installation 1. Create boards directory in projectconf_pio_core_dir if it doesn't exist.
2. Create myboard.json file in this boards directory.
3. Search available boards via cmd_boards command. You should see myboard board.
Now, you can use myboard for the projectconf_env_board option in projectconf.
NOTE: You can have custom boards per project. In this case, please put your board's JSON files to projectconf_pio_boards_dir.
Examples Please take a look at the source code of PlatformIO Development Platforms and navigate to boards folder of the repository.
PIO Account PIO Account is required for using:
• Community Forum
PlatformIO IDE pioide has built-in UI in PIO Home to manage PIO Account. You can create a new account, reset your password, update profile, or fetch an authentication token.
CLI Guide PIO Check New in version 4.1.
Automated code analysis without hassle!
Static analysis became an important part of software development cycle. It can identify potential bugs, vulnerabilities and security threats by doing an analysis on the source code level without having to test it on hardware or execute any code.
PIO Check helps reduce development cost by enabling engineers to detect the precise location of defects and eliminate issues more efficiently and earlier in the development cycle. It can also ensure compliance with internal or industry coding standards such as MISRA, CERT, etc.
Key features • Fully integrated within the PlatformIO ecosystem and easy to execute on the entire project.
• Straightforward integration with ci services.
• Possibility to reuse the same setup on other projects.
• Easy and flexible rule configuration.
• Comprehensive and detailed error information
• Multiple architectures and development platforms.
• Cross-platform: Windows, MacOS, Linux.
PIO Check can detect a wide range of known defects in C/C++ code, including:
• Potential NULL pointer dereferences
• Possible indexing beyond array bounds
• Suspicious assignments
• Reads of potentially uninitialized objects
• Unused variables or functions
• Out of scope memory usage
WARNING: Before performimg a static analysis check, make sure your project builds without errors. For information about how to build a project, see the cmd_run command or ide_vscode guide.
User Interface There is the rich and friendly interface for PIO Check in piohome.  It allows you to filter messages or directly jump to an issue in a source code.  [image] [image]
Configuration PIO Check allows selecting what tool is used for finding defects in the project, what source files are checked. PIO Check can be configured from projectconf using the next options:
Check tools You can switch between or specify multiple tools used for finding defects using projectconf_check_tool option:
Detailed information about supported check tools and their configuration process can be found on these pages:
Cppcheck Cppcheck is a static analysis tool for C/C++ code. It provides a unique code analysis to detect bugs and focuses on detecting undefined behavior and dangerous coding constructs. The goal is to detect only real errors in the code (i.e. have very few false positives). More information about this tool on the official webpage.
HINT: Cppcheck is rarely wrong about reported errors. But there are many bugs that it doesn't detect. You will find more bugs in your software by testing your software carefully than by using Cppcheck.
Contents • Features
• Additional checks
• Extra flags
• Suppressing warnings
• Addons (MISRA, CERT)
• MISRA
• CERT
Features Cppcheck supports a wide variety of static checks that may not be covered by the compiler itself. These checks are static analysis checks that can be performed at a source code level. The program is directed towards static analysis checks that are rigorous, rather than heuristic in nature.
Some of the defects that might be detected include:
• Automatic variable checking
• Bounds checking for array overruns
• Classes checking (e.g. unused functions, variable initialization, and memory duplication)
• Usage of deprecated or superseded functions
• Exception safety checking, for example, usage of memory allocation and destructor checks
• Memory leaks, e.g. due to lost scope without deallocation
• Resource leaks, e.g. due to forgetting to close a file handle
• Invalid usage of Standard Template Library functions and idioms
• Miscellaneous stylistic and performance errors
Additional checks Be default Cppcheck is configured to check the next additional defects:
• warning
• style
• performance
• portability
• unusedFunction
The full list of supported check with detailed description is located on the official webpage.
Configuration Cppcheck is implicitly used as the default check tool when projectconf_check_tool option in projectconf is not set. To be explicit, you can specify it in the configuration directly:
[env:myenv] platform = ... board = ... check_tool = cppcheck check_flags = --enable=all
Useful options that can be used used for adjusting check process:
Extra flags Useful flags that can help more precisely configure Cppcheck to satisfy your project requirements:
Suppressing warnings It might be useful to explicitly instruct Cppcheck to ignore some of the known defects in project codebase. Since --inline-suppr is enabled by default, it's possible to directly mark pieces of code that will be excluded from Cppcheck report using // cppcheck-suppress warningId syntax.
NOTE: Warning ID can be found in square brackets at the end of defect description, for example: src\Blink.cpp:17: [low:style] The function 'loop' is never used. [unusedFunction]
By default, piocheck command doesn't scan framework sources and that's why some functions from in your project might be reported as unused. For example, you can ignore warnings about setup and loop functions from Arduino-based projects:
// cppcheck-suppress unusedFunction void setup() { ... }
// cppcheck-suppress unusedFunction void loop() { ... }
Addons (MISRA, CERT) Cppcheck provides several addon scripts that analyze dump files to check compatibility with secure coding standards and to locate various issues. Most useful addons for verifying compliance with popular guidelines are MISRA and CERT.
MISRA MISRA is a proprietary set of software development guidelines for the C/C++ programming languages developed by MISRA (Motor Industry Software Reliability Association).  It aims to facilitate code safety, security, portability, and reliability  in the context of embedded systems, specifically those systems programmed in ISO C/C++.
NOTE: Since this standard is proprietary, Cppcheck does not display error text by specifying only the number of violated rules (for example, [c2012-21.3]).  If you want to display full texts for violated rules, you will need to create a text file containing MISRA rules, which you will have to pass when calling the script with --rule-texts flag.
In order to use MISRA addon you will need to provide a special file with the description of MISRA rules. Usually, it has the next contents:
Appendix A Summary of guidelines Rule 3.1 Required R3.1 Rule description Rule 4.1 Required ... Rule 21.3 Required R21.3 Rule description Rule 21.4 R21.4 Rule description
Next, you need to instruct Cppcheck that you want to run an additional addon script. Since this script requires an additional file with rules, you can pass it via a special json file:
{ "script": "addons/misra.py", "args": ["--rule-texts=misra-rules.txt"] }
Finally, add new flag to projectconf_check_flags:
[env:myenv] platform = ... board = ... check_tool = cppcheck check_flags = cppcheck: --addon=misra.json
The full list of implemented MISRA checks can be found on the official webpage.
CERT SEI CERT coding standard provides rules for secure coding in the C programming language. The goal of these rules and recommendations is to develop safe, reliable, and secure systems, for example by eliminating undefined behaviors that can lead to undefined program behaviors and exploitable vulnerabilities.
In order to use the CERT addon, simply specify it as an additional flag in projectconf_check_flags section:
[env:myenv] platform = ... board = ... check_tool = cppcheck check_flags = cppcheck: --addon=cert.py
Clang-Tidy Clang-Tidy is a clang-based C++ "linter" tool. Its purpose is to provide an extensible framework for diagnosing and fixing typical programming errors, like style violations, interface misuse, or bugs that can be deduced via static analysis.  Official page can be found here.
• Supported checks
Features Clang-Tidy supports a large variety of static checks that may not be covered by the compiler itself. These checks are static analysis checks that can be performed at a source code level.
• Buffer overflow
• Use of memory that has already been deallocated
• Failure to set a return value from a subroutine
Configuration To enable Clang-Tidy tool simply add it to the projectconf_check_tool option in projectconf:
[env:myenv] platform = ... board = ... check_tool = clangtidy
Supported checks There are currently the following groups of most used checks (By default all checks are enabled):
┌───────────────────┬─────────────────────────────┐ │Check              │ Description                 │ ├───────────────────┼─────────────────────────────┤ │abseil-            │ Checks related to Abseil    │ │                   │ library.                    │ ├───────────────────┼─────────────────────────────┤ │boost-             │ Checks related to Boost     │ │                   │ library.                    │ ├───────────────────┼─────────────────────────────┤ │bugprone-          │ Checks that target bugprone │ │                   │ code constructs.            │ ├───────────────────┼─────────────────────────────┤ │cert-              │ Checks related to CERT      │ │                   │ Secure Coding Guidelines.   │ └───────────────────┴─────────────────────────────┘
│cppcoreguidelines- │ Checks related to C++ Core  │ │                   │ Guidelines.                 │ ├───────────────────┼─────────────────────────────┤ │clang-analyzer-    │ Clang Static Analyzer       │ │                   │ checks.                     │ ├───────────────────┼─────────────────────────────┤ │google-            │ Checks related to Google    │ │                   │ coding conventions.         │ ├───────────────────┼─────────────────────────────┤ │hicpp-             │ Checks related to High      │ │                   │ Integrity C++ Coding        │ │                   │ Standard.                   │ ├───────────────────┼─────────────────────────────┤ │modernize-         │ Checks that advocate usage  │ │                   │ of modern (currently modern │ │                   │ means C++11) language       │ │                   │ constructs.                 │ ├───────────────────┼─────────────────────────────┤ │performance-       │ Checks that target          │ │                   │ performance-related issues. │ ├───────────────────┼─────────────────────────────┤ │portability-       │ Checks that target          │ │                   │ portability-related issues  │ │                   │ that don’t relate to any    │ │                   │ particular coding style.    │ ├───────────────────┼─────────────────────────────┤ │readability-       │ Checks that target          │ │                   │ readability-related issues  │ │                   │ that don’t relate to any    │ │                   │ particular coding style.    │ └───────────────────┴─────────────────────────────┘
The full list of supported checks can be found on the official webpage.
Extra flags Useful flags that can help more precisely configure Clang-Tidy to satisfy your project requirements:
┌────────────────────────┬─────────────────────────────┐ │Flag                    │ Meaning                     │ ├────────────────────────┼─────────────────────────────┤ │--checks=<string>       │ Comma-separated list of     │ │                        │ enabled checks (* default)  │ ├────────────────────────┼─────────────────────────────┤ │--fix                   │ Apply suggested fixes.      │ │                        │ Without -fix-errors         │ │                        │ clang-tidy will bail out if │ │                        │ any compilation errors were │ │                        │ found.                      │ ├────────────────────────┼─────────────────────────────┤ │--fix-errors            │ Apply suggested fixes even  │ │                        │ if compilation errors were  │ │                        │ found. If compiler errors   │ │                        │ have attached fix-its,      │ │                        │ clang-tidy will apply them  │ │                        │ as well.                    │ ├────────────────────────┼─────────────────────────────┤ │--format-style=<string> │ Style for formatting code   │ │                        │ around applied fixes: llvm, │ │                        │ google, webkit, mozilla,    │ │                        │ none (default)              │ ├────────────────────────┼─────────────────────────────┤ │--system-headers        │ Display the errors from     │ │                        │ system headers.             │ └────────────────────────┴─────────────────────────────┘
An example with enabling specific checks and fixing code on the fly:
[env:myenv] platform = ... board = ... check_tool = clangtidy check_flags = clangtidy: --checks=-*,cert-*,clang-analyzer-* --fix
PVS-Studio PVS-Studio is a static code analysis tool for detecting bugs and security weaknesses in the source code of programs, written in C, C++, C# and Java. It analyze source code intended for 32-bit, 64-bit and embedded ARM platforms.  Official page can be found here.
• Obtaining license
Features PVS-Studio performs a wide range of code checks, and it is also useful in finding misprints and Copy-Paste errors. These checks are static analysis checks that can be performed at a source code level. Some of the defects that might be detected include:
• Arithmetic over/underflow
• Array index out of bounds
• Undefined/unspecified behavior
• Incorrect usage of exceptions
• Buffer overrun
• Null pointer/null reference dereference
• Improper understanding of function/class operation logic
• Illegal bitwise/shift operations
Configuration To enable PVS-Studio tool simply add it to the projectconf_check_tool option in projectconf:
[env:myenv] platform = ... board = ... check_tool = pvs-studio
Extra flags Useful flags that can help more precisely configure PVS-Studio to satisfy your project requirements:
┌────────────────────────┬─────────────────────────────────────┐ │Flag                    │ Meaning                             │ ├────────────────────────┼─────────────────────────────────────┤ │--analysis-mode <arg>   │ Analysis mode (0 - full             │ │                        │ analysis (default), 1 -             │ │                        │ 64-bit. analysis, 2 -               │ │                        │ reserved, 4 - general               │ │                        │ analysis, 8 - optimization,         │ │                        │ 16 - customer's specific            │ │                        │ requests, 32 - MISRA)               │ ├────────────────────────┼─────────────────────────────────────┤ │--analyzer-errors <arg> │ Errors activation (Default:         │ │                        │ all errors is on)                   │ ├────────────────────────┼─────────────────────────────────────┤ │--errors-off <arg>      │ Errors OFF (Default: all            │ │                        │ errors is on)                       │ ├────────────────────────┼─────────────────────────────────────┤ │--exclude-path <arg>    │ All code that is located            │ │                        │ under the path will be              │ │                        │ excluded from analysis              │ ├────────────────────────┼─────────────────────────────────────┤ │--lic-file <arg>        │ Path to custom license              │ │                        │ file. Default locations             │ │                        │ ~/.config/PVS-Studio/PVS-Studio.lic │ │                        │ on Unix and                         │ │                        │ %APPDATA%\PVS-Studio\PVS-Studio.lic │ │                        │ on Windows                          │ ├────────────────────────┼─────────────────────────────────────┤ │--rules-config <arg>    │ Specifies the path to rules         │ │                        │ configuration file.                 │ ├────────────────────────┼─────────────────────────────────────┤ │--platform <arg>        │ Platform name (Win32, x64, etc)     │ │                        │ (Default: ARM)                      │ └────────────────────────┴─────────────────────────────────────┘
An example with a special analysis mode, disabled errors and license file:
[env:myenv] platform = ... board = ... check_tool = pvs-studio check_flags = pvs-studio: --analysis-mode=4 --errors-off=V532,V586 --lic-file=/path/to/file.lic
Obtaining license Since PVS-Studio is a paid B2B solution, a license should be purchased. But PVS-Studio can be used for free of charge, for example for checking open source projects. More information about the cases when you can get a free PVS-Studio license can be found on the official webpage.
TIP: If you're experiencing problems with the license file or see the following error message: License information is incorrect. Please check your registration data or contact Customer Support, try saving the license file in UTF-8 + BOM format with the following contents:
name@domain.com AAAA-BBBB-CCCC-DDDD
Defect severity Defect severity is a classification of software defect (bug, vulnerability, etc) that indicates the degree of negative impact on the quality of software. PIO Check uses the next classification of possible defects:
┌─────────┬─────────────────────────────┐ │Severity │ Meaning                     │ ├─────────┼─────────────────────────────┤ │high     │ Issues that are possibly    │ │         │ bugs                        │ ├─────────┼─────────────────────────────┤ │medium   │ Suggestions about defensive │ │         │ programming in order to     │ │         │ prevent potential bugs      │ ├─────────┼─────────────────────────────┤ │low      │ Issues related to code      │ │         │ cleanup and performance     │ │         │ (unused functions,          │ │         │ redundant code, const-ness, │ │         │ etc)                        │ └─────────┴─────────────────────────────┘
CLI Guide PIO Check can be configured using command line commands. Detailed description of these commands can be found here:
PIO Remote Your devices are always with you!
PIO Remote allows you to work remotely with devices from Anywhere In The World. No matter where are you now! Run a small and cross-platform cmd_remote_agent on a remote machine and you are able to list active devices (wireless + wired), to upload firmware (program), to process remote unit tests, or to start remote debugging session via Remote Serial Port Monitor.
Using PIO Remote you can share your devices with colleagues across your organization or friends. In combination with ide_cloud, you can create awesome things at any time when inspiration comes to you.
You should have pioaccount to work with PIO Remote.  A registration is FREE.
Contents • PIO Remote
• Features
• Use Cases
• Technology
• CLI Guide
Features • Remote Device Manager
• Remote Serial Port Monitor
• Remote Firmware Updates
• PIO Remote Share
• Continuous Deployment
• Continuous Delivery
• Remote Unit Testing
Use Cases Cloud IDE Program your devices from anywhere in the world using the most popular ide_cloud. You do not need to install any extra software, no need to have static IP or open network ports. Everything works out of the box.
Devices behind card sized PC Work with your favorite development environment and program devices connected to card-sized PC (Raspberry Pi, Cubie Board, etc.). You do not need to open SSH ports, install any extra Linux packages, toolchains.
Remote Unit Testing Instruct any of ci services to run remote tests on a physical device.  See the documentation for Remote Test Runner.
• You commit new changes to your source code repository
• ci service deploys unit tests to a remote agent
• unit_testing engine runs tests on a physical device, process them, and send results
• ci service prints results in human readable format
• If one test fails, current CI build will fail too.
Board Farm A similar concept as described in "Remote Unit Testing" above. Let's imagine that you need to test some logic on the unlimited number of target devices.  Very often it can be the same hardware prototype but with different factory revisions.
You connect these devices via USB hub to PC and instruct PIO Remote to process your test on ALL targets connected to a specific agent. See documentation below.
Remote Serial Monitor Sometimes you don't have physical access to a target device but you need to read data from some serial port. PIO Remote allows you to connect to a remote agent and list connected devices with their serial ports. See cmd_remote_device_monitor command for details.
Technology [image]
PIO Remote is an own PlatformIO technology for remote solutions without external dependencies to operating system or its software based on client-server architecture.  The Server component (PlatformIO Cloud) plays a role of coupling link between cmd_remote_agent and Client (cmd_remote, ide_cloud, ci, SDKs, etc.).  When you start cmd_remote_agent, it connects over the Internet with PlatformIO Cloud and listen for the actions/commands which you can send in Client role from anywhere in the world.
PIO Remote is multi-agents and multi-clients system. A single agent can be shared with multiple clients, where different clients can use the same agent.  This approach allows one to work with distributed hardware located in the different places, networks, etc.
This technology allows one to work with remote devices in generic form as you do that with local devices using PlatformIO ecosystem. The only one difference is a prefix "remote" before each generic PlatformIO command. For example, listing of local and remote devices will look like cmd_device_list and cmd_remote_device_list.
Installation PIO Remote is built into pioide. Please open PlatformIO IDE Terminal and run pio remote --help command for usage (see cmd_remote).
If you do not have pioide, or use ide_cloud or a card-sized PC (Raspberry Pi, BeagleBoard, etc.), please install piocore.
Quick Start 1. Start PIO Remote Agent using cmd_remote_agent_start command on a remote machine where devices are connected physically or are accessible via network. PIO Remote Agent works on Windows, macOS, Linux and Linux ARMv6+.  It means that you can use desktop machine, laptop or credit card sized PC (Raspberry Pi, BeagleBoard, etc).
You can share own devices/hardware with friends, team or other developers using platformio remote agent start --share option.
2. Using host machine (cmd_remote, ide_cloud Terminal in a browser, SDKs, etc.), please authorize via cmd_account_login command with the same credentials that you used on the previous step.  Now, you can use cmd_remote commands to work with remote machine and its devices.
You don't need to have networking or other access to remote machine where PIO Remote Agent is started.
If you use PIO Remote in pair with ci or want automatically authorize, please set PLATFORMIO_AUTH_TOKEN system environment variable instead of using cmd_account_login command.
NOTE: In case with ide_cloud, your browser with Cloud IDE's VM is a "host machine". The machine where devices are connected physically (your real PC) is called "remote machine" in this case. You should run PIO Remote Agent here (not in Cloud IDE's Terminal).
NOTE: Please use local IP as "upload port" when device is not connected directly to a remote machine where PIO Remote Agent is started but supports natively Over-the-Air (OTA) updates. For example, platform_espressif8266 and platform_espressif_ota. In this case, the final command for remote OTA update will look as platformio remote run -t upload --upload-port 192.168.0.255 or platformio remote run -t upload --upload-port myesp8266.local.
CLI Guide PIO Unified Debugger It Simply Works. Easier than ever before!
NOTE: Demo, discussions, request a support for new hardware.
PlatformIO offers a unique debugging experience for productive embedded development. Using our multi-board and multi-architecture programming experience, we simplified the debugging process in the same way. A zero debugging configuration with support for the most popular debugging probes and compatibility between IDEs and OS.
Developers can finally forget about complex UI windows which they need to pre-configure before a simple “Hello World!” debugging session. No need to know any aspects about the debugging server or how to configure it. PIO Unified Debugger does this complex work automatically having a rich configuration database per each board and debugging probe.
Just select a board, connect debugging probe (if a board does not have onboard debugging interface), specify it in PlatformIO project configuration file “platformio.ini”, and a project is ready for 1-Click debugging.
• "1-click" solution, zero configuration
• Support over 300+ embedded boards (see below)
• Multiple architectures and development platforms
• Windows, MacOS, Linux
• Built-in into ide_atom and ide_vscode
• Integration with ide_eclipse and ide_sublimetext
You should have pioaccount to work with PIO Unified Debugger.  A registration is FREE.
HINT: In our experience, ide_vscode has the best system performance, modern interface for PIO Unified Debugger, and users have found it easier to get started.  Key debugging features of ide_vscode:
• Local, Global, and Static Variable Explorer
• Conditional Breakpoints