<
<center>(click to zoom)</center>
<br>
**1: Configurable Modules** - Contains a list of software module such as drivers, middleware, and protocol stacks that can be configured in the SysConfig GUI.
**2: Module Configuration View** - This view is where you can add an instance of a module and configure it.
**3: Core Selection Tabs** (multi-core projects only) - These tabs allow you to switch between SysConfig views for cores in a multi-core/system project.
**4: Problems** - This view highlights any problems detected by the SysConfig solver, such as pinmux conflicts.
**5: Generated Files** - This view contains the source code generated by SysConfig.
**6: Device View** - This view contains the device pin layout and displays the number of GPIO pins used in the design.
**7: History** - This view logs all of the changes done in the SysConfig GUI.
<hr style="width:50%; margin: auto;" />
### View Selection
<br>
The **Problems** view, **Generated Files** view, **Device** view, and **History** view can be enabled or disabled by clicking the icons in the top-right corner of the SysConfig GUI.
<hr style="width:50%; margin: auto;" />
### Description View
<br>
Some modules have a description view that can be opened by clicking the question mark icon.
<br>
<hr style="width:50%; margin: auto;" />
Once opened, you can see further details about the current module as shown below for the IPC module.
<hr style="width:50%; margin: auto;" />
### SysConfig Diff
<br>
SysConfig shows the diff of the generated files in real time so you can see how the GUI changes affect the generated code.
<br>
<hr>
## Driver Configuration
<br>
SysConfig will generate driver configuration files based on the GUI selections. The driver configuration files call MCU+ SDK functions to enable these configurations.
For example, the below code (generated by SysConfig), sets up the UART peripheral to be used for logging. Here you see the auto-generated code uses the SDK structures `gUartAttrs()` and `gUartConfig()`.
```c
/*
* UART
*/
/* UART atrributes */
static UART_Attrs gUartAttrs[CONFIG_UART_INSTANCES] =
{
{
.baseAddr = CSL_UART0_BASE,
.inputClkFreq = 48000000U,
},
};
/* UART objects - initialized by the driver */
static UART_Object gUartObjects[CONFIG_UART_INSTANCES];
/* UART driver configuration */
UART_Config gUartConfig[CONFIG_UART_INSTANCES + 1] =
{
{
&gUartAttrs[CONFIG_UART_CONSOLE],
&gUartObjects[CONFIG_UART_CONSOLE],
},
{
NULL,
NULL,
},
};
```
<br>
<br>
The **Generated Source** folder contains the generated source files. It is provided to allow a user to quickly see the generated files instead of going into the **Debug** directory. Note: this example's default CCS Build Configuration is Debug so that is why the Debug folder is named as such. If the example was using the Release configuration, the folder would be named **Release.**
The following diagram shows how SysConfig and the generated sources tie into creating the application executable.
SysConfig code generation has the following advantages over having the application writer supply source code:
* Adding a driver instance is easier.
* Reduces the number of mistakes since the 'C' code is generated instead of hand-written.
* The source files are specifically tailored to your application with SysConfig.
<hr>
## Runtime usage and configuration of drivers
<br>
Currently SysConfig is focused on **static configuration** of driver code. Applications still need to initialize the drivers, i.e. call `System_init` and call the driver APIs at run-time to control the driver and perform driver functions.
Similarly, to re-configure drivers at run-time, applications can use the config APIs to do this.
<hr>
## Disabling SysConfig Auto-Generation
<br>
Once you generate the source files using SysConfig, you can disable the SysConfig auto-generation by copying the source files to your project folder and excluding the *.syscfg file from the build.
1. Copy the source files under the Debug > syscfg folder.
2. Paste them into the project folder.
3. Right-click on the *.syscfg file and select "Exclude from Build" - it will be grayed out after you exclude it.
4. You can now rebuild your project without SysConfig re-generating the source files.
<hr>
## Editing the .syscfg file
<br>
{{r TI does not recommend manually editing the .syscfg file by hand, only via the SysConfig Tool.}}
## []{ } Knowledge Check
<br>
**1.** Does SysConfig change the runtime usage of drivers?
[quiz]
x Yes --> Incorrect
v No --> Correct!
[quiz]
<br>
**2.** Where can the files generated by SysConfig be found?
[quiz]
v Generated Sources --> Correct!
x Binaries --> Incorrect
x Includes --> Incorrect
[quiz]
<br>
**3. Select all that apply:** SysConfig is available
[quiz_multi]
v with CCS Desktop --> Correct!
v with CCS Cloud --> Correct!
v as a stand-alone desktop tool --> Correct!
v as a cmdline tool --> Correct!
[quiz_multi]
<hr>
## Next Steps
<br>
Now that you are familiar with SysConfig, you can progress to the next module where you will learn how to use SysConfig to add a driver to an MCU+ SDK project.
##### [Part 4: Adding Drivers >](adding_driver.html)
<br>
<hr>
## Additional Reading
<br>
##### MCU+ SDK User Guide: [Using SDK with SysConfig](https://software-dl.ti.com/mcu-plus-sdk/esd/AM243X/latest/exports/docs/api_guide_am243x/SYSCONFIG_INTRO_PAGE.html)
<br/>
<hr>
{{r> [Back to Home](../overview.html)}}
{{r **Was this helpful? Let us know here:** [mcu_plus_academy_feedback@list.ti.com](mailto:mcu_plus_academy_feedback@list.ti.com)}}
<div align="center" style="margin-top: 4em; font-size: smaller;">
<a rel="license" href="https://creativecommons.org/licenses/by-nc-nd/4.0/"><img alt="Creative Commons License"
style="border-width:0" src="..//web_support/cc_license_icon.png" /></a><br />This work is licensed under a <a
rel="license" href="https://creativecommons.org/licenses/by-nc-nd/4.0/">Creative Commons
Attribution-NonCommercial-NoDerivatives 4.0 International License</a>.</div>
]]>