Skip to content

Configuration Files

Software components are configured by editing standard C/C++ header files using preprocessor macros. This means that configuration can only change the behavior of software already present in the project, and cannot add or remove dependencies or otherwise change the contents of the project. If such functionality is required, component validation scripts can be used to flag warnings and errors based on component and configuration state.

This separates the project assembly phase, where components are added and the project is generated, from the configuration phase, in which the user can change component settings after the project is generated.

Project Configuration Details

Components (.slcc), whether in an SDK or SDK Extension, can contain configuration files to be added to the project together with the component's sources, include paths, and other content. The project (.slcp) can also directly contribute configuration files. Configuration files are referenced using the config_file key.

During project generation, the configuration files referenced in .slcc and .slcp files are copied into the config/ directory in the project. This path is always available on the include path, and the configuration headers can be included in source code to configure drivers, etc. This gives the project a standalone copy of the configuration file to edit as needed. If a file with the same name is already present in the project config/ directory, it is not automatically overwritten by the file copied from the SDK. This preserves user edits to the configuration header.

In specific implementation-defined scenarios, tools may attempt to merge the SDK version of the configuration header with an existing copy in the project. An example of this is the Part/Board/SDK selection in Simplicity Studio, which allows the user to choose to merge changes and update the configuration headers when the part or board is changed. The slc upgrade command in SLC-CLI and equivalent functionality in Simplicity Studio is an other example, allowing for targeted updating of configuration headers when upgrading to a new version of the SDK. See SDK Upgrade for more information on upgrades.

Components and projects can also override configuration files from other components. This is typically used when a development board or IC module needs a specific configuration (such as a pinout) for a peripheral driver. In order to be overridable, the source component must give the config_file a file_id, as described in the config_file section. The overriding component or project can then use the override key to indicate what file_id of which component it intends to override.

Finally a project can set non-default values for specific configuration items to be applied during the initial project generation. This transformation occurs when the configuration header is initially copied to the project config/ directory using replacement values as given in the configuration secction of the project.

Configuration Header Annotations

A configuration header can be annotated to allow integration with configuration GUIs and tools like the SDK upgrade tool. A subset of the CMSIS Configuration Wizard Annotation format as described in the CMSIS Documentation is used for plain software configuration options. A configuration block is bounded by the following comment lines:

1
2
3
4
5
6
7
// A CMSIS annotation block starts with the following line:
// <<< Use Configuration Wizard in Context Menu >>>

// ...

// The block ends with the following line or at the end of the file:
// <<< end of configuration section >>>

See the page on the CMSIS Configuration Wizard Annotation format for details.

Configuration options that require integration with more advanced tools use their own configuration blocks:

1
2
3
4
5
6
7
// A configurator block for the tool "advanced_config":
// <<< sl:start advanced_config >>>

// ...

// The block ends with the following line or at the end of the file:
// <<< sl:end advanced_config >>>

One tool using this format is the Pin Tool (pin_tool), which allows for allocation of peripheral and pin resources on embedded devices.

Advanced Configurators

Certain tools require a more advanced save file than a C/C++ header, and their output may be generated code that is not necessarily human readable. Examples of this may include generated configuration blobs for hardware accelerators, or setup for complex wireless protocol databases such as ZCL or GATT.

Such tools are called Advanced Configurators. An Advanced Configurator takes its input from a sub-directory of the project config/ directory, and emits generated content to the autogen/ directory.

Examples of Advanced Configurators include

  • EFR32 Radio Configurator
  • Bluetooth Configurator
  • ZCL Advanced Platform
  • HomeKit Configurator
  • TensorFlow Lite Micro flatbuffer converter

An Advanced Configurator always has a generator that takes input from the config/ directory and generates output to the autogen/ directory. This generator typically watches for configuration files with a specific file extension.

The Advanced Configurator may also have a configuration GUI that is used to edit the configuration file if its content is not human-editable.

SLC-CLI and Simplicity Studio discover Advanced Configurators in an SDK through the Adapter Pack mechanism, and automatically invoke the necessary commands when generating a project.

Back to top