3. SDK Architecture

The SDK6 provided by Renesas for the DA14535, DA14531-00, DA14531-01, DA14585 and DA14586 contains the following:
  • Drivers for the on-chip peripherals.

  • Bluetooth LE Profile implementations.

  • Example projects demonstrating how to use the on-chip peripherals and Bluetooth LE stack APIs.

  • Documents detailing the available APIs.

  • Various utilities and tools for creating binary files.

Note

The Bluetooth LE stack (host and controller) is contained within the ROM of the DA1453x , DA14585 and DA14586 devices.

The following sections describe the structure and architectue of SDK6.

3.1. Directory Structure

The root SDK directory contains the following directories:

_images/root_tree.png

Figure 6 SDK root directory structure

  • binaries It stores executable binaries for PC applications found in the host_apps directory, along with binary files for the production test tool firmware.

  • config contains the DA1458x/53x configuration files for the SmartSnippets tool.

  • doc contains documents detailing the available APIs and SDK6 license files.

  • projects contains example projects.

  • sdk contains the core files of the SDK6.

  • third_party contains third-party source files that are used within the SDK6.

  • utilities contains utilities and tools that supplement the SDK6.

3.2. Architecture

The software platform for DA1458x/53x incorporates a compact and efficient Real-Time Kernel. The Bluetooth LE stack utilizes this kernel, benefiting from its task, message, events, and dynamic memory allocation capabilities. Tasks communicate through messages, which are queued for inter-task communication. Hardware events, including timers, also enqueue events. The kernel scheduler, invoked from the main loop, processes messages and events based on priority, invoking relevant handlers to execute tasks. Once the queues are empty, the kernel transitions the device to low-power sleep mode.

Application callback functions streamline application development by exposing selected events and messages to users. This approach eliminates the need for users to manage tasks, message events, and related complexities directly.

Creating tasks

In most cases, creating tasks during application development is unnecessary. The majority of applications can be implemented efficiently by adding code directly into the SDK6 application callback functions. It is strongly recommended to follow this technique for optimal development practices.

3.2.1. Application Callbacks

Two types of application callbacks are provided by the SDK6:
  • System callbacks are used to pass system events (such as woken from sleep, about to enter sleep etc.) to the users application.

  • Bluetooth LE callbacks are used to pass stack events (such as connected, disconnected etc.) to the users application.

user_callback_config.h

All of the available callback functions (both stack and system) are contained within data structures that are defined in user_callback_config.h.

3.2.1.1. System Callbacks

The SDK6 provides the following callbacks to indicate to the users application that certain system events have occurred:

Table 1 System Callbacks

Function

Description

Timing Constraints

app_on_init

Called following a reset during the device initialization process.

None

app_on_ble_powered

Called periodically by the main loop while the BLE core is active.

Medium

app_on_system_powered

Called periodically by the main loop while the BLE core can be in sleep mode.

Medium

app_before_sleep

Called just before the main loop starts checking if the device can be put into sleep mode.

Medium

app_validate_sleep

Called before the main loop puts the device into sleep mode (radio is off but peripherals are still on).

Hard

app_going_to_sleep

Called before the main loop puts the device into sleep mode (radio and perpipherals are off).

Hard

app_resume_from_sleep

Called just after the device exits sleep mode.

Hard

Managing Sleep Mode

The functions app_on_ble_powered and app_on_system_powered are periodically invoked until the main loop decides the device can enter sleep mode. Users can prevent the device from entering sleep mode by returning the necessary value in these functions. This feature enables the application to keep the device active until ongoing operations, such as sensor data reading, are completed.

Apart from the mentioned callbacks, users need to implement the periph_init function as part of their application. This function, found in the SDK6 examples (see the user_periph_setup.c file), is called upon device startup or wake from sleep mode. Its purpose is to initialize any peripherals required by the application.

The following diagrams illustrate the sequence of system callbacks that will occur under various conditions:
_images/sys_cb_reset_flowchart.png

Figure 7 System Callback Sequence (Reset)

_images/sys_cb_wake_flowchart.png

Figure 8 System Callback Sequence (Wakeup)

3.2.1.2. Bluetooth LE Stack Callbacks

Details of the available stack callbacks can be found in Application Software section of the SW Platform Reference Manual