Member | Action | Date |
---|---|---|
![]() |
Posted
Integrating Peripheral Examples into a Wireless Project with RTOS in Simplicity Studio V5 on 32-bit Microcontroller (MCU) Knowledge Base
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 ModelThe 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 - Initializationsl_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 ProcessingThe 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 Incorporating a Peripheral Example into a RTOS-based Wireless ProjectAdding RTOS to a Wireless ProjectRefer 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 IntegrationBefore 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.
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:
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. |
18 days ago |
![]() |
Updated
Integrating Peripheral Examples into a Wireless Project with RTOS in Simplicity Studio V5 on 32-bit Microcontroller (MCU) Knowledge Base
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 ModelThe 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 - Initializationsl_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 ProcessingThe 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 Incorporating a Peripheral Example into a RTOS-based Wireless ProjectAdding RTOS to a Wireless ProjectRefer 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 IntegrationBefore 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):
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:
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 -
E. Now, the ADC measurement and implementation need to be added to the application. Open the app.c file again.
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. |
18 days ago |
![]() |
Updated
Integrating Peripheral Examples into a Wireless Project with RTOS in Simplicity Studio V5 on 32-bit Microcontroller (MCU) Knowledge Base
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 ModelThe 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 - Initializationsl_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 ProcessingThe 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 Incorporating a Peripheral Example into a RTOS-based Wireless ProjectAdding RTOS to a Wireless ProjectRefer 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 IntegrationBefore 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.
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:
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. |
18 days ago |
![]() |
Updated
Integrating Peripheral Examples into a Wireless Project with RTOS in Simplicity Studio V5 on 32-bit Microcontroller (MCU) Knowledge Base
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 ModelThe 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 - Initializationsl_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 ProcessingThe 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 Incorporating a Peripheral Example into a RTOS-based Wireless ProjectAdding RTOS to a Wireless ProjectRefer 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 IntegrationBefore 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):
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:
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 -
NOTE:
E. Now, the ADC measurement and implementation need to be added to the application. Open the app.c file again.
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. |
18 days ago |
![]() |
Replied
to
Happy Gecko EM4 configuration mode
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 |
50 days ago |
![]() |
Replied
to
'Programming Flash' has encountered a problem - Invalid Argument
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. |
50 days ago |
![]() |
Replied
to
Connecting a Thunderboard to an ADC via SPI
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. 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?
|
50 days ago |
![]() |
Replied
to
EFM8UB2 Debug problem
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 |
50 days ago |
![]() |
Posted
Theads- can"t possible to set newtork between node on
qna
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
|
50 days ago |
![]() |
Posted
BGM220: how to access TRNG->FIFO on
qna
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? |
50 days ago |