Overview#

The programming model applies only to projects that are generated by Simplicity Studio v5's project configuration tool. As of this release this is only applicable to Bluetooth and Proprietary SDKs. This section explains the details of how a project generated by Simplicity Studio v5's project configuration tool works, and how you integrate your application to it. This covers both new projects and projects that are migrated to the new SDK version.

The programming model covers several important areas such as hardware initialization, software initialization, and periodic action processing. It covers both baremetal and kernel based applications. For instance, in case of a baremetal application, this programming model will allow you to add processing action functions to the main loop.

If you are migrating an existing application to this new version, be aware that this programming model now handles some hardware initializations (hardware clocks, DCDC, etc) and some software initializations (kernel, stacks, etc) that you may have had to do manually with previous versions.

Using this programming model for your application is important as it will ensure proper hardware initialization and proper SDK software modules initalization. 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 on power management, refer to Power Manager section.

Note: The SDK Programming model is compatible with SiSDK 2024.6 and greater versions.

Features#

Initialization#

A single function, sl_system_init(), is provided to you. This function initializes all the SDK modules that are selected in your project.

Action Processing#

Some of the SDK modules (mostly services and wireless stacks) have actions to process periodically. Functions are also provided to help you with that. The action processing however differs depending on if you are using a kernel or if you have a bare metal application.

Bare Metal#

If your application is bare metal, a function called sl_system_process_action() is provided to you. This function contains all the SDK modules "step" functions that must be called in every iteration of the super loop. You must call this function from your super loop.

When Using a Kernel (RTOS)#

If you selected a kernel in your project, the SDK modules that have to process periodic actions will automatically create task(s) during initialization. The only thing you must do is start the kernel by calling the function sl_system_kernel_start(). You should ideally also create any task you might need before calling this function.

SDK Component Catalog#

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

Usage Examples#

These are examples of main functions that use the functions described above that you can use as a reference.

Bare Metal#

#include "sl_system_init.h"
#include "sl_system_process_action.h"
#include "sl_component_catalog.h"

#ifdef SL_CATALOG_POWER_MANAGER_PRESENT
#include "sl_power_manager.h"
#endif

int main(void)
{
  // Initialize Silicon Labs SDK modules.
  sl_system_init();


 // TODO: Add required initializations for your application

  while (1) {
    // TODO: Add required "step" actions for your application

    // Process periodic actions of Silicon Labs SDK modules
    sl_system_process_action();

#ifdef SL_CATALOG_POWER_MANAGER_PRESENT
    // Let the CPU go to sleep if the system allows it.
    sl_power_manager_sleep();
#endif
  }
}

When Using a Kernel (RTOS)#

#include "sl_system_init.h"
#include "sl_system_kernel.h"

int main(void)
{
  // Initialize Silicon Labs SDK modules.
  sl_system_init();


  // TODO: Add required initializations for your application


  // TODO: Create kernel tasks required for your application

  // Start the kernel.
  sl_system_kernel_start();
}

Initializing your Device#

When generating your project on a Silicon Labs kit, the project configuration tools will automatically add a component called Device Initialization. This component provides basic hardware configuration functionalities. These functions will automatically be called when calling sl_system_init().

When generating a project for a custom board, the Device Initialization module can be manually selected.

You can customize these basic configurations by modifying the configurations available in the Device Initialization software component. For more information on this component, see Device Initialization.

Atomic Section General Considerations#

Overview#

The sl_core module provides two types of basic critical sections (interrupt masking), the critical sections, and the atomic sections. The critical sections will always mask all the interrupts (except the non-maskable ones) by using the PRIMASK register. On the other hand, the atomic sections can mask the interrupts by using either the PRIMASK or BASEPRI register.

Using the BASEPRI register allows you to only mask interrupts based on their interrupt priority. That is to say, only interrupts with equal or lower priority (higher number) than the BASEPRI register value will be masked in an atomic section.

The default value for the BASEPRI register used to mask interrupts in an atomic section is 3. Otherwise, the BASEPRI value is kept to 0 to allow all interrupts.

The benefit of the atomic sections over the critical sections is that it won't mask interrupts that you would consider of very high priority and for which you want to have minimal latency. However, the atomic sections can obviously not be used to protect access to resources that would be accessed by these very high priority interrupt's handlers.

Kernel-aware vs. non kernel-aware interrupt considerations#

The RTOSs currently provided (Micrium OS and FreeRTOS, for example) implement the principle of kernel aware vs non kernel-aware interrupts. The threshold is defined by the BASEPRI register value. That is, when having to protect its internal resources, the kernel will always mask the interrupts using atomic sections. This means any very high priority interrupts will be able to interrupt the kernel. That also means you CANNOT use any kernel API from these very hight interrupt's handlers (you cannot post a semaphore, for instance).

When using FreeRTOS, interrupts priorities MUST be configured either manually or automatically using the Interrupt manager module. This is because when an MCU supports BASEPRI, FreeRTOS will use the configMAX_SYSCALL_INTERRUPT_PRIORITY setting to configure BASEPRI to protect its internal resources from concurrent access.

Interrupt Manager Module#

The Interrupt Manager component initializes all interrupt handler priorities via the sl_interrupt_manager_init() function. The Interrupt Manager module is a dependency of the sl_system module and is added automatically to your project if the sl_system module is selected.

Silicon labs devices with Cortex-M33 core have 4 bits in the NVIC register to encode a priority, therefore the priority range is 0-15.

The Interrupt manager module defines the following value:

sl_interrupt_manager_init() will therefore initialize all interrupt priorities (except fault handler) to SL_INTERRUPT_MANAGER_DEFAULT_PRIORITY. Since the default priority is lower than the BASEPRI value used in atomic sections, every interrupt is disabled by default during an atomic section. When the interrupt manager service initialization has finished, it is up to your application to call sl_interrupt_manager_set_irq_priority() to change the default priority of an Interrupt Handler according to its needs.

Any modification to an interrupt priority should be done carefully since it can introduce behaviour changes in your application difficult to pinpoint.

The interrupt manager is now in charge of the interrupt vector relocation in the internal RAM. The interrupt manager can now relocate the interrupt vector table in RAM and switch the interrupt vector table base address of the core to point to it. This can be achieved by setting the SL_INTERRUPT_MANAGER_S2_INTERRUPTS_IN_RAM configuration to true in the file sl_interrupt_manager_s2_config.h.