This article will be providing a brief overview of the new programming model in Simplicity Studio V5 and provide instructions on integrating peripheral examples available on GitHub into wireless projects with RTOS. Note that this article is using a Bluetooth soc-empty example and the ADC polled example on EFR32BG13. The user is encouraged to apply this to other supported wireless stacks, devices and peripheral examples or custom code.  

Simplicity Studio V5 now has improved resources and GUI tools for embedded application development using EFM32, EFR32 MCU and Wireless MCU devices. Referred to together as Project Configurator and Gecko Platform, these resources are designed to simplify the development process and provide consistency when developing applications for Silicon Labs devices regardless of whether the application is bare-metal or RTOS-based, which radio stack is used and which of the many native software components are utilized. A new development architecture is designed to facilitate and streamline application development. One of the primary elements of this development architecture called Gecko Platform is a suite of embedded software components. It includes high level drivers and services as well as lower level components such as emlib and common utilities. It also encompasses modules such as board level APIs, RTOS, third party libraries and RAIL library.

Project Configurator is a collection of GUI tools available in Simplicity Studio V5 to allow developers to easily integrate and manage different software components from Gecko Platform in their applications. It simplifies the process of adding and removing platform software components in a project. In some cases, the Project Configurator can also be used to configure aspects of these software components or device features. It also includes a pin tool for assignment of peripheral functionality to device hardware pins. 

This article will provide instructions on integrating a peripheral example to a Bluetooth project with RTOS. This article uses Gecko SDK v3.1.1 and is running Simplicity Studio v5.1.1.0. This article pertains only to Gecko SDK versions 3.0.0 and greater. 

Brief Introduction to the Programming Model

The programming model enables the interaction between the Project Configurator GUI tools and the Gecko Platform software catalog.  The programming model is in essence a framework that provides predetermined points of entry for the automatic insertion of initialization code and operational process code. Hooks are provided for platform components as well as custom application code. The configuration tool can generate code that covers hardware initialization, software initialization, and periodic action processing. In addition to this, it also covers both bare-metal and kernel based applications. Using this programming model for user application is important as it will ensure proper hardware initialization and proper SDK software modules initialization. Using this programming model will also ensure proper power management, as power management has to be a centralized service (power requirements can come from different requesters). For more information, refer to - https://docs.silabs.com/gecko-platform/latest/sdk-programming-model. 

In a bare-metal project, the programming model groups firmware actions into an initialization phase and a process action phase. The programming model automatically adapts to the use of RTOS kernel but requires some changes in how the user should include custom application action processing code. More details are provided below - 

Initialization

sl_system_init()

In the initialization phase, gecko platform software modules that have been included in the project through the project configurator are initialized using a call from main to sl_system_init(). This function in turn calls several initialization functions that serve as entry points for the Project Configurator to insert initialization code for installed software components. 

In a project containing a kernel or RTOS, the programming model still contains an initialization phase. However, the function of the initialization phase differs from that of a bare-metal project. When using a kernel, the call from main to sl_system_init() and its nested init calls initialize installed Gecko Platform software modules as well as create RTOS tasks for any system actions that occur at runtime. 

app_init()

This is the entry point for user initialization code. Any initialization code not automatically generated by the project configurator that is used in the application should be inserted by the user such that it is called from within this function. 

In a project containing a kernel or RTOS, the user should also ensure that any custom runtime application actions are handled by a kernel task and should also add these kernel tasks from within app_init(). 

Action Processing

The next phase of the programming model occurs from within the main loop and is responsible for handling all action that the application must process during runtime. Some of the SDK modules (mostly services and wireless stacks) have actions to process periodically. Functions are also provided to help users with that. The action processing differs fundamentally if a kernel application is being used.

sl_system_process_action()

If a software component installed via the project configurator requires action processing, the code to do so will automatically be inserted and called from sl_system_process_action() function and the nested process action calls within this function. 

app_process_action()

After sl_system_process_action() returns, app_process_action() is called from the main loop. This function is the entry point for custom user runtime actions and users should place function calls to custom application code here. 

sl_system_kernel_start()

In the kernel programming model, autogenerated system actions and custom application actions are handled by kernel tasks added during the initialization phase. The main function then calls sl_system_kernel_start() which starts the kernel scheduler. Any system or custom application runtime actions registered as tasks during the initialization phase will execute according to the RTOS scheduler. 

Note: The SDK component catalog is a simple header file named sl_component_catalog.h that can be included from anywhere in the project. This file contains #define entries for the different SDK components available in the project. This allows users to enable/disable portions of code depending on whether an SDK component is present in the project or not.

Incorporating a Peripheral Example into a RTOS-based Wireless Project

Adding RTOS to a Wireless Project

Refer to the instructions provided in AN1260 to integrate RTOS into a Wireless Project. This article assumes that that the user has imported soc_empty Bluetooth example project and has created the tasks required to integrate an application into a Bluetooth project (section 3.3 in the Application Note).

NOTE: This article uses FreeRTOS, but either the FreeRTOS or Micrium Kernel will work with the provided application code. To switch to the Micrium OS follow the Micrium OS specific instructions provided in AN1260.

Peripheral Example Integration

Before integrating the peripheral example, the user needs to make sure that the previous section (adding RTOS to a Wireless Project) has been completed. The ADC Single Polled example code provided in our GitHub repository will be used to populate the necessary functions within the Bluetooth+RTOS application to take a software triggered measurement of an expansion header pin voltage. Similar steps can be followed for other peripheral examples or custom application code to integrate into RTOS-based Wireless Project. 

1. From the Simplicity IDE perspective and while viewing soc_empty.slcp in the main window, navigate to the "Software Components" tab. 
2. In the project configurator, the software components tab allows users to install and uninstall components as well as configure components that support customization (configurable components have a gear symbol next to the component name). In the left pane of the software components tab, users can browse categories of components. Categories can then be expanded to view individual component. From here, install the following Software Components (if not installed already):
   1. Platform > Peripheral > ADC

This will add the necessary source files from the emlib library which is required for running code provided through our Peripheral Examples repository on GitHub.

NOTE:

1. When a component is installed, the corresponding SDK files are copied/linked into the project folder, all dependencies of the component are copied into the project folder and new include directories are added into the project settings. In addition to this, configuration files are copied into the config folder and corresponding autogen files are modified in the autogen folder to integrate the component into the application. 
2. Several filters and a keyword search are provided to help explore component categories.
3. Here's the code from the ADC Single Polled example taken from the peripheral example 
4. Now, the code shown above must be split to match the programming model of the project in Simplicity Studio V5. In other words, the ADC initialization and ADC process action should be moved to appropriate APIs in the Gecko Platform project. In the "Project Explorer" window, open app.c. This article will be creating new subroutines for initialization, single conversion start and conversion complete in app.c file. Specifically - 
   1. Include em_adc.h and em_cmu.h at the top of the file
   2. Copy or add the definition of adcFreq and declare sample and millivolts global variables at the top of the file
   3. Create a function called my_adc_init() and copy the initialization code from step #3's initADC() function
   4. Copy or add the ADC single conversion start function to my_adc_start_measurement()
   5. Copy or add the code polling the ADC status and then retrieve the single conversion to my_adc_measurement_get()NOTE: 
      1. The ADC measurement is split in this example into two functions, one to kick off a conversion, and another to retrieve the conversion data, however the two could be combined. The benefit of splitting this up is while the ADC conversion is taking place, other code can be executing.
      2. It is up to the user to decide if they'd like to split this into different demo.c/demo.h files or directly paste it into app_init() or app_process_action().
5. Now, the ADC measurement and implementation need to be added to the application. Open the app.c file again. 
   1. In app_init(), add the ADC initialization function my_adc_init(). This now creates a kernel task to handle the ADC measurements. 
   2. Add the ADC conversion start and measurement functions to the kernel task. For more information about adding application tasks to a Bluetooth project, refer to section 3.3.3 in AN1260. 
6. Build the project and flash it on the WSTK. Set a breakpoint in my_adc_measurement_get() function and observe/confirm that it periodically gets triggered.

NOTE: The user can also add the IO Stream component to print the ADC values, but this implementation is outside the scope of this article. For more information on IO Stream, please refer to - https://docs.silabs.com/gecko-platform/latest/service/api/group-iostream. 

This article will be providing a brief overview of the new programming model in Simplicity Studio V5 and provide instructions on integrating peripheral examples available on GitHub into wireless projects with RTOS. Note that this article is using a Bluetooth soc-empty example and the ADC polled example on EFR32BG13. The user is encouraged to apply this to other supported wireless stacks, devices and peripheral examples or custom code.  

Simplicity Studio V5 now has improved resources and GUI tools for embedded application development using EFM32, EFR32 MCU and Wireless MCU devices. Referred to together as Project Configurator and Gecko Platform, these resources are designed to simplify the development process and provide consistency when developing applications for Silicon Labs devices regardless of whether the application is bare-metal or RTOS-based, which radio stack is used and which of the many native software components are utilized. A new development architecture is designed to facilitate and streamline application development. One of the primary elements of this development architecture called Gecko Platform is a suite of embedded software components. It includes high level drivers and services as well as lower level components such as emlib and common utilities. It also encompasses modules such as board level APIs, RTOS, third party libraries and RAIL library.

Project Configurator is a collection of GUI tools available in Simplicity Studio V5 to allow developers to easily integrate and manage different software components from Gecko Platform in their applications. It simplifies the process of adding and removing platform software components in a project. In some cases, the Project Configurator can also be used to configure aspects of these software components or device features. It also includes a pin tool for assignment of peripheral functionality to device hardware pins. 

This article will provide instructions on integrating a peripheral example to a Bluetooth project with RTOS. This article uses Gecko SDK v3.1.1 and is running Simplicity Studio v5.1.1.0. This article pertains only to Gecko SDK versions 3.0.0 and greater. 

Brief Introduction to the Programming Model

The programming model enables the interaction between the Project Configurator GUI tools and the Gecko Platform software catalog.  The programming model is in essence a framework that provides predetermined points of entry for the automatic insertion of initialization code and operational process code. Hooks are provided for platform components as well as custom application code. The configuration tool can generate code that covers hardware initialization, software initialization, and periodic action processing. In addition to this, it also covers both bare-metal and kernel based applications. Using this programming model for user application is important as it will ensure proper hardware initialization and proper SDK software modules initialization. Using this programming model will also ensure proper power management, as power management has to be a centralized service (power requirements can come from different requesters). For more information, refer to - https://docs.silabs.com/gecko-platform/latest/sdk-programming-model. 

In a bare-metal project, the programming model groups firmware actions into an initialization phase and a process action phase. The programming model automatically adapts to the use of RTOS kernel but requires some changes in how the user should include custom application action processing code. More details are provided below - 

Initialization

sl_system_init()

In the initialization phase, gecko platform software modules that have been included in the project through the project configurator are initialized using a call from main to sl_system_init(). This function in turn calls several initialization functions that serve as entry points for the Project Configurator to insert initialization code for installed software components. 

In a project containing a kernel or RTOS, the programming model still contains an initialization phase. However, the function of the initialization phase differs from that of a bare-metal project. When using a kernel, the call from main to sl_system_init() and its nested init calls initialize installed Gecko Platform software modules as well as create RTOS tasks for any system actions that occur at runtime. 

app_init()

This is the entry point for user initialization code. Any initialization code not automatically generated by the project configurator that is used in the application should be inserted by the user such that it is called from within this function. 

In a project containing a kernel or RTOS, the user should also ensure that any custom runtime application actions are handled by a kernel task and should also add these kernel tasks from within app_init(). 

Action Processing

The next phase of the programming model occurs from within the main loop and is responsible for handling all action that the application must process during runtime. Some of the SDK modules (mostly services and wireless stacks) have actions to process periodically. Functions are also provided to help users with that. The action processing differs fundamentally if a kernel application is being used.

sl_system_process_action()

If a software component installed via the project configurator requires action processing, the code to do so will automatically be inserted and called from sl_system_process_action() function and the nested process action calls within this function. 

app_process_action()

After sl_system_process_action() returns, app_process_action() is called from the main loop. This function is the entry point for custom user runtime actions and users should place function calls to custom application code here. 

sl_system_kernel_start()

In the kernel programming model, autogenerated system actions and custom application actions are handled by kernel tasks added during the initialization phase. The main function then calls sl_system_kernel_start() which starts the kernel scheduler. Any system or custom application runtime actions registered as tasks during the initialization phase will execute according to the RTOS scheduler. 

Note: The SDK component catalog is a simple header file named sl_component_catalog.h that can be included from anywhere in the project. This file contains #define entries for the different SDK components available in the project. This allows users to enable/disable portions of code depending on whether an SDK component is present in the project or not.

Incorporating a Peripheral Example into a RTOS-based Wireless Project

Adding RTOS to a Wireless Project

Refer to the instructions provided in AN1260 to integrate RTOS into a Wireless Project. This article assumes that that the user has imported soc_empty Bluetooth example project and has created the tasks required to integrate an application into a Bluetooth project (section 3.3 in the Application Note).

NOTE: This article uses FreeRTOS, but either the FreeRTOS or Micrium Kernel will work with the provided application code. To switch to the Micrium OS follow the Micrium OS specific instructions provided in AN1260.

Peripheral Example Integration

Before integrating the peripheral example, the user needs to make sure that the previous section (adding RTOS to a Wireless Project) has been completed. The ADC Single Polled example code provided in our GitHub repository will be used to populate the necessary functions within the Bluetooth+RTOS application to take a software triggered measurement of an expansion header pin voltage. Similar steps can be followed for other peripheral examples or custom application code to integrate into RTOS-based Wireless Project. 

A. From the Simplicity IDE perspective and while viewing soc_empty.slcp in the main window, navigate to the "Software Components" tab. 

B. In the project configurator, the software components tab allows users to install and uninstall components as well as configure components that support customization (configurable components have a gear symbol next to the component name). In the left pane of the software components tab, users can browse categories of components. Categories can then be expanded to view individual component. From here, install the following Software Components (if not installed already):

1. Platform > Peripheral > ADC

This will add the necessary source files from the emlib library which is required for running code provided through our Peripheral Examples repository on GitHub.

NOTE:

• When a component is installed, the corresponding SDK files are copied/linked into the project folder, all dependencies of the component are copied into the project folder and new include directories are added into the project settings. In addition to this, configuration files are copied into the config folder and corresponding autogen files are modified in the autogen folder to integrate the component into the application. 
• Several filters and a keyword search are provided to help explore component categories.

C. Here's the code from the ADC Single Polled example taken from the peripheral example 

D. Now, the code shown above must be split to match the programming model of the project in Simplicity Studio V5. In other words, the ADC initialization and ADC process action should be moved to appropriate APIs in the Gecko Platform project. In the "Project Explorer" window, open app.c. This article will be creating new subroutines for initialization, single conversion start and conversion complete in app.c file. Specifically - 

1. Include em_adc.h and em_cmu.h at the top of the file
2. Copy or add the definition of adcFreq and declare sample and millivolts global variables at the top of the file
3. Create a function called my_adc_init() and copy the initialization code from step #3's initADC() function
4. Copy or add the ADC single conversion start function to my_adc_start_measurement()
5. Copy or add the code polling the ADC status and then retrieve the single conversion to my_adc_measurement_get()NOTE: 
   1. The ADC measurement is split in this example into two functions, one to kick off a conversion, and another to retrieve the conversion data, however the two could be combined. The benefit of splitting this up is while the ADC conversion is taking place, other code can be executing.
   2. It is up to the user to decide if they'd like to split this into different demo.c/demo.h files or directly paste it into app_init() or app_process_action().

E. Now, the ADC measurement and implementation need to be added to the application. Open the app.c file again. 

1. In app_init(), add the ADC initialization function my_adc_init(). This now creates a kernel task to handle the ADC measurements. 
2. Add the ADC conversion start and measurement functions to the kernel task. For more information about adding application tasks to a Bluetooth project, refer to section 3.3.3 in AN1260. 

F. Build the project and flash it on the WSTK. Set a breakpoint in my_adc_measurement_get() function and observe/confirm that it periodically gets triggered.

NOTE: The user can also add the IO Stream component to print the ADC values, but this implementation is outside the scope of this article. For more information on IO Stream, please refer to - https://docs.silabs.com/gecko-platform/latest/service/api/group-iostream. 

This article will be providing a brief overview of the new programming model in Simplicity Studio V5 and provide instructions on integrating peripheral examples available on GitHub into wireless projects with RTOS. Note that this article is using a Bluetooth soc-empty example and the ADC polled example on EFR32BG13. The user is encouraged to apply this to other supported wireless stacks, devices and peripheral examples or custom code.  

Simplicity Studio V5 now has improved resources and GUI tools for embedded application development using EFM32, EFR32 MCU and Wireless MCU devices. Referred to together as Project Configurator and Gecko Platform, these resources are designed to simplify the development process and provide consistency when developing applications for Silicon Labs devices regardless of whether the application is bare-metal or RTOS-based, which radio stack is used and which of the many native software components are utilized. A new development architecture is designed to facilitate and streamline application development. One of the primary elements of this development architecture called Gecko Platform is a suite of embedded software components. It includes high level drivers and services as well as lower level components such as emlib and common utilities. It also encompasses modules such as board level APIs, RTOS, third party libraries and RAIL library.

Project Configurator is a collection of GUI tools available in Simplicity Studio V5 to allow developers to easily integrate and manage different software components from Gecko Platform in their applications. It simplifies the process of adding and removing platform software components in a project. In some cases, the Project Configurator can also be used to configure aspects of these software components or device features. It also includes a pin tool for assignment of peripheral functionality to device hardware pins. 

This article will provide instructions on integrating a peripheral example to a Bluetooth project with RTOS. This article uses Gecko SDK v3.1.1 and is running Simplicity Studio v5.1.1.0. This article pertains only to Gecko SDK versions 3.0.0 and greater. 

Brief Introduction to the Programming Model

The programming model enables the interaction between the Project Configurator GUI tools and the Gecko Platform software catalog.  The programming model is in essence a framework that provides predetermined points of entry for the automatic insertion of initialization code and operational process code. Hooks are provided for platform components as well as custom application code. The configuration tool can generate code that covers hardware initialization, software initialization, and periodic action processing. In addition to this, it also covers both bare-metal and kernel based applications. Using this programming model for user application is important as it will ensure proper hardware initialization and proper SDK software modules initialization. Using this programming model will also ensure proper power management, as power management has to be a centralized service (power requirements can come from different requesters). For more information, refer to - https://docs.silabs.com/gecko-platform/latest/sdk-programming-model. 

In a bare-metal project, the programming model groups firmware actions into an initialization phase and a process action phase. The programming model automatically adapts to the use of RTOS kernel but requires some changes in how the user should include custom application action processing code. More details are provided below - 

Initialization

sl_system_init()

In the initialization phase, gecko platform software modules that have been included in the project through the project configurator are initialized using a call from main to sl_system_init(). This function in turn calls several initialization functions that serve as entry points for the Project Configurator to insert initialization code for installed software components. 

In a project containing a kernel or RTOS, the programming model still contains an initialization phase. However, the function of the initialization phase differs from that of a bare-metal project. When using a kernel, the call from main to sl_system_init() and its nested init calls initialize installed Gecko Platform software modules as well as create RTOS tasks for any system actions that occur at runtime. 

app_init()

This is the entry point for user initialization code. Any initialization code not automatically generated by the project configurator that is used in the application should be inserted by the user such that it is called from within this function. 

In a project containing a kernel or RTOS, the user should also ensure that any custom runtime application actions are handled by a kernel task and should also add these kernel tasks from within app_init(). 

Action Processing

The next phase of the programming model occurs from within the main loop and is responsible for handling all action that the application must process during runtime. Some of the SDK modules (mostly services and wireless stacks) have actions to process periodically. Functions are also provided to help users with that. The action processing differs fundamentally if a kernel application is being used.

sl_system_process_action()

If a software component installed via the project configurator requires action processing, the code to do so will automatically be inserted and called from sl_system_process_action() function and the nested process action calls within this function. 

app_process_action()

After sl_system_process_action() returns, app_process_action() is called from the main loop. This function is the entry point for custom user runtime actions and users should place function calls to custom application code here. 

sl_system_kernel_start()

In the kernel programming model, autogenerated system actions and custom application actions are handled by kernel tasks added during the initialization phase. The main function then calls sl_system_kernel_start() which starts the kernel scheduler. Any system or custom application runtime actions registered as tasks during the initialization phase will execute according to the RTOS scheduler. 

Note: The SDK component catalog is a simple header file named sl_component_catalog.h that can be included from anywhere in the project. This file contains #define entries for the different SDK components available in the project. This allows users to enable/disable portions of code depending on whether an SDK component is present in the project or not.

Incorporating a Peripheral Example into a RTOS-based Wireless Project

Adding RTOS to a Wireless Project

Refer to the instructions provided in AN1260 to integrate RTOS into a Wireless Project. This article assumes that that the user has imported soc_empty Bluetooth example project and has created the tasks required to integrate an application into a Bluetooth project (section 3.3 in the Application Note).

NOTE: This article uses FreeRTOS, but either the FreeRTOS or Micrium Kernel will work with the provided application code. To switch to the Micrium OS follow the Micrium OS specific instructions provided in AN1260.

Peripheral Example Integration

Before integrating the peripheral example, the user needs to make sure that the previous section (adding RTOS to a Wireless Project) has been completed. The ADC Single Polled example code provided in our GitHub repository will be used to populate the necessary functions within the Bluetooth+RTOS application to take a software triggered measurement of an expansion header pin voltage. Similar steps can be followed for other peripheral examples or custom application code to integrate into RTOS-based Wireless Project. 

1. From the Simplicity IDE perspective and while viewing soc_empty.slcp in the main window, navigate to the "Software Components" tab. 
2. In the project configurator, the software components tab allows users to install and uninstall components as well as configure components that support customization (configurable components have a gear symbol next to the component name). In the left pane of the software components tab, users can browse categories of components. Categories can then be expanded to view individual component. From here, install the following Software Components (if not installed already):
   1. Platform > Peripheral > ADC

This will add the necessary source files from the emlib library which is required for running code provided through our Peripheral Examples repository on GitHub.

NOTE:

1. When a component is installed, the corresponding SDK files are copied/linked into the project folder, all dependencies of the component are copied into the project folder and new include directories are added into the project settings. In addition to this, configuration files are copied into the config folder and corresponding autogen files are modified in the autogen folder to integrate the component into the application. 
2. Several filters and a keyword search are provided to help explore component categories.
3. Here's the code from the ADC Single Polled example taken from the peripheral example 
4. Now, the code shown above must be split to match the programming model of the project in Simplicity Studio V5. In other words, the ADC initialization and ADC process action should be moved to appropriate APIs in the Gecko Platform project. In the "Project Explorer" window, open app.c. This article will be creating new subroutines for initialization, single conversion start and conversion complete in app.c file. Specifically - 
   1. Include em_adc.h and em_cmu.h at the top of the file
   2. Copy or add the definition of adcFreq and declare sample and millivolts global variables at the top of the file
   3. Create a function called my_adc_init() and copy the initialization code from step #3's initADC() function
   4. Copy or add the ADC single conversion start function to my_adc_start_measurement()
   5. Copy or add the code polling the ADC status and then retrieve the single conversion to my_adc_measurement_get()​​​​​​​NOTE: 
      1. The ADC measurement is split in this example into two functions, one to kick off a conversion, and another to retrieve the conversion data, however the two could be combined. The benefit of splitting this up is while the ADC conversion is taking place, other code can be executing.
      2. It is up to the user to decide if they'd like to split this into different demo.c/demo.h files or directly paste it into app_init() or app_process_action().
5. ​​​​​​​Now, the ADC measurement and implementation need to be added to the application. Open the app.c file again. 
   1. In app_init(), add the ADC initialization function my_adc_init(). This now creates a kernel task to handle the ADC measurements. 
   2. Add the ADC conversion start and measurement functions to the kernel task. For more information about adding application tasks to a Bluetooth project, refer to section 3.3.3 in AN1260. 
6. Build the project and flash it on the WSTK. Set a breakpoint in my_adc_measurement_get() function and observe/confirm that it periodically gets triggered.

NOTE: The user can also add the IO Stream component to print the ADC values, but this implementation is outside the scope of this article. For more information on IO Stream, please refer to - https://docs.silabs.com/gecko-platform/latest/service/api/group-iostream. 

This article will be providing a brief overview of the new programming model in Simplicity Studio V5 and provide instructions on integrating peripheral examples available on GitHub into wireless projects with RTOS. Note that this article is using a Bluetooth soc-empty example and the ADC polled example on EFR32BG13. The user is encouraged to apply this to other supported wireless stacks, devices and peripheral examples or custom code.  

Simplicity Studio V5 now has improved resources and GUI tools for embedded application development using EFM32, EFR32 MCU and Wireless MCU devices. Referred to together as Project Configurator and Gecko Platform, these resources are designed to simplify the development process and provide consistency when developing applications for Silicon Labs devices regardless of whether the application is bare-metal or RTOS-based, which radio stack is used and which of the many native software components are utilized. A new development architecture is designed to facilitate and streamline application development. One of the primary elements of this development architecture called Gecko Platform is a suite of embedded software components. It includes high level drivers and services as well as lower level components such as emlib and common utilities. It also encompasses modules such as board level APIs, RTOS, third party libraries and RAIL library.

Project Configurator is a collection of GUI tools available in Simplicity Studio V5 to allow developers to easily integrate and manage different software components from Gecko Platform in their applications. It simplifies the process of adding and removing platform software components in a project. In some cases, the Project Configurator can also be used to configure aspects of these software components or device features. It also includes a pin tool for assignment of peripheral functionality to device hardware pins. 

This article will provide instructions on integrating a peripheral example to a Bluetooth project with RTOS. This article uses Gecko SDK v3.1.1 and is running Simplicity Studio v5.1.1.0. This article pertains only to Gecko SDK versions 3.0.0 and greater. 

Brief Introduction to the Programming Model

The programming model enables the interaction between the Project Configurator GUI tools and the Gecko Platform software catalog.  The programming model is in essence a framework that provides predetermined points of entry for the automatic insertion of initialization code and operational process code. Hooks are provided for platform components as well as custom application code. The configuration tool can generate code that covers hardware initialization, software initialization, and periodic action processing. In addition to this, it also covers both bare-metal and kernel based applications. Using this programming model for user application is important as it will ensure proper hardware initialization and proper SDK software modules initialization. Using this programming model will also ensure proper power management, as power management has to be a centralized service (power requirements can come from different requesters). For more information, refer to - https://docs.silabs.com/gecko-platform/latest/sdk-programming-model. 

In a bare-metal project, the programming model groups firmware actions into an initialization phase and a process action phase. The programming model automatically adapts to the use of RTOS kernel but requires some changes in how the user should include custom application action processing code. More details are provided below - 

Initialization

sl_system_init()

In the initialization phase, gecko platform software modules that have been included in the project through the project configurator are initialized using a call from main to sl_system_init(). This function in turn calls several initialization functions that serve as entry points for the Project Configurator to insert initialization code for installed software components. 

In a project containing a kernel or RTOS, the programming model still contains an initialization phase. However, the function of the initialization phase differs from that of a bare-metal project. When using a kernel, the call from main to sl_system_init() and its nested init calls initialize installed Gecko Platform software modules as well as create RTOS tasks for any system actions that occur at runtime. 

app_init()

This is the entry point for user initialization code. Any initialization code not automatically generated by the project configurator that is used in the application should be inserted by the user such that it is called from within this function. 

In a project containing a kernel or RTOS, the user should also ensure that any custom runtime application actions are handled by a kernel task and should also add these kernel tasks from within app_init(). 

Action Processing

The next phase of the programming model occurs from within the main loop and is responsible for handling all action that the application must process during runtime. Some of the SDK modules (mostly services and wireless stacks) have actions to process periodically. Functions are also provided to help users with that. The action processing differs fundamentally if a kernel application is being used.

sl_system_process_action()

If a software component installed via the project configurator requires action processing, the code to do so will automatically be inserted and called from sl_system_process_action() function and the nested process action calls within this function. 

app_process_action()

After sl_system_process_action() returns, app_process_action() is called from the main loop. This function is the entry point for custom user runtime actions and users should place function calls to custom application code here. 

sl_system_kernel_start()

In the kernel programming model, autogenerated system actions and custom application actions are handled by kernel tasks added during the initialization phase. The main function then calls sl_system_kernel_start() which starts the kernel scheduler. Any system or custom application runtime actions registered as tasks during the initialization phase will execute according to the RTOS scheduler. 

Note: The SDK component catalog is a simple header file named sl_component_catalog.h that can be included from anywhere in the project. This file contains #define entries for the different SDK components available in the project. This allows users to enable/disable portions of code depending on whether an SDK component is present in the project or not.

Incorporating a Peripheral Example into a RTOS-based Wireless Project

Adding RTOS to a Wireless Project

Refer to the instructions provided in AN1260 to integrate RTOS into a Wireless Project. This article assumes that that the user has imported soc_empty Bluetooth example project and has created the tasks required to integrate an application into a Bluetooth project (section 3.3 in the Application Note).

NOTE: This article uses FreeRTOS, but either the FreeRTOS or Micrium Kernel will work with the provided application code. To switch to the Micrium OS follow the Micrium OS specific instructions provided in AN1260.

Peripheral Example Integration

Before integrating the peripheral example, the user needs to make sure that the previous section (adding RTOS to a Wireless Project) has been completed. The ADC Single Polled example code provided in our GitHub repository will be used to populate the necessary functions within the Bluetooth+RTOS application to take a software triggered measurement of an expansion header pin voltage. Similar steps can be followed for other peripheral examples or custom application code to integrate into RTOS-based Wireless Project. 

A. From the Simplicity IDE perspective and while viewing soc_empty.slcp in the main window, navigate to the "Software Components" tab. 

B. In the project configurator, the software components tab allows users to install and uninstall components as well as configure components that support customization (configurable components have a gear symbol next to the component name). In the left pane of the software components tab, users can browse categories of components. Categories can then be expanded to view individual component. From here, install the following Software Components (if not installed already):

1. Platform > Peripheral > ADC

This will add the necessary source files from the emlib library which is required for running code provided through our Peripheral Examples repository on GitHub.

NOTE:

• When a component is installed, the corresponding SDK files are copied/linked into the project folder, all dependencies of the component are copied into the project folder and new include directories are added into the project settings. In addition to this, configuration files are copied into the config folder and corresponding autogen files are modified in the autogen folder to integrate the component into the application. 
• Several filters and a keyword search are provided to help explore component categories.

C. Here's the code from the ADC Single Polled example taken from the peripheral example 

D. Now, the code shown above must be split to match the programming model of the project in Simplicity Studio V5. In other words, the ADC initialization and ADC process action should be moved to appropriate APIs in the Gecko Platform project. In the "Project Explorer" window, open app.c. This article will be creating new subroutines for initialization, single conversion start and conversion complete in app.c file. Specifically - 

1. Include em_adc.h and em_cmu.h at the top of the file
2. Copy or add the definition of adcFreq and declare sample and millivolts global variables at the top of the file
3. Create a function called my_adc_init() and copy the initialization code from step #3's initADC() function
4. Copy or add the ADC single conversion start function to my_adc_start_measurement()
5. Copy or add the code polling the ADC status and then retrieve the single conversion to my_adc_measurement_get()

NOTE: 

1. The ADC measurement is split in this example into two functions, one to kick off a conversion, and another to retrieve the conversion data, however the two could be combined. The benefit of splitting this up is while the ADC conversion is taking place, other code can be executing.
2. It is up to the user to decide if they'd like to split this into different demo.c/demo.h files or directly paste it into app_init() or app_process_action().

E. Now, the ADC measurement and implementation need to be added to the application. Open the app.c file again. 

1. In app_init(), add the ADC initialization function my_adc_init(). This now creates a kernel task to handle the ADC measurements. 
2. Add the ADC conversion start and measurement functions to the kernel task. For more information about adding application tasks to a Bluetooth project, refer to section 3.3.3 in AN1260. 

F. Build the project and flash it on the WSTK. Set a breakpoint in my_adc_measurement_get() function and observe/confirm that it periodically gets triggered.

NOTE: The user can also add the IO Stream component to print the ADC values, but this implementation is outside the scope of this article. For more information on IO Stream, please refer to - https://docs.silabs.com/gecko-platform/latest/service/api/group-iostream. 

Hey Aditya,

I am not sure what device you're using or what energy mode you want to get to, but please look through our peripheral examples on Github to find the closest match to your requirement - https://github.com/SiliconLabs/peripheral_examples

Hey Scott,

Is this on Simplicity Studio V4? This a very old thread and I am not sure if you're trying to flash a bootloader and having issues? Please elaborate on what you're trying to do so that we can see if it is reproducible here. 

Hey Marco,

Why are you using the SPI example with DMA? For your application, can you use a simple polled SPI example? I recommend starting simple if there's no DMA requirements in your application. 

>> I did connect it to my Thunderboard PINs 4, 6, 8, 10 and to Power on PIN 18 and GND PIN 1.

Are these the expansion header pins or the pins on the chip (fig 6.2)? Your pin definitions in the code is not matching either, so I am not sure what pins are being referred to here. The easiest way to see if you have configured your pins correctly is to view them on a scope or logic analyzer. Are you seeing SPI data from these pins?

The ADC device you're connecting to requires the CS pin to be asserted for 4 shift clocks. Can you confirm that you are doing this? 

How are you controlling power down reset for the ADC device? What state is this pin in? 

Hi Ili,

You can erase flash through the flash programmer available in Simplicity Studio or via the commander. It is a GUI tool that lets you flash and erase your device. 

Simplicity Commander

Flash Programmer

Dear, 

I am trying to create network between two nodes by following https://www.silabs.com/documents/public/quick-start-guides/qsg170-openthread-sdk-quick-start-guide.pdf.

I took TWO W72230F1(EFR32MG12 2.4GHz mesh networking kit) of 19db.  then I  programed the flash to device from (ot-cli-ftd.s37) for the device and flash proagmmer from tool by browsing the dummby bootloader file and i programmed it. 

later i followed and did same process for the another device also flash to device fom(ot-cli-ftd.s37) and flashing a bootloader from tool dialog. 

then now i am trying create network between them two devices.  so for that i open LANUCH CONSOLE from the one device then i given command as below:

>dataset init new

done 

>dataset commit active

done

>ifconfig up

done

>thread start

done

after that i am getting this type error which i mentioned below:

>dataset init new

Error35: Invalid Command

i tryed  this command from serial 0 and serial 1 from the both device even also i getting same error. i cant able to create the nework between the nodes. 

i want to create the create between the node and later i want to there bandwidth for how long  they communicate is possible.

I attach the image of my error. please find thye attachment.

But for now i cant able to create the network between them please help me regarding this. thanking you in advance.

Regards

Sri Naga

After porting my project from BG13 to BG22 I noticed that TRNG is now a part of the CRYPTOACC module. Although there are some FIFO related registers in the new module, I do not see how to access the FIFO itself. Is it possible to directly access TRNG FIFO on BG22? Previously on BG13 it was as simple as TRNG->FIFO.

Another question: what entropy source is used by the sl_bt_system_get_random_data() API?