World's lowest power Bluetooth monolithic DA14580 software architecture-hierarchical architecture and BLE message Event processing

The "World's lowest power Bluetooth single chip DA14580 system architecture and application Development Framework analysis", "the world's lowest power Bluetooth single chip DA14580 hardware architecture and low power consumption", "the world's lowest power Bluetooth single chip DA14580 software system-RW kernel and message processing mechanism" Three articles analyze the DA14580 SDK Development directory structure, hardware architecture, low power consumption, RW kernel and message processing mechanism. This article will go deep into the specific source to analyze the software hierarchy of the DA14580 platform and the specific BLE message processing process, in support of the previous published article.

First, the software hierarchy structure

1.1 BLE protocol stack

From this, we can see that BLE protocol stack can be broadly divided into application layer, Profile Service layer, BLE host layer (software implementation), BLE controller layer (Hardware implementation, belongs to the baseband section), in fact, the hardware physical layer also has the RF layer radio, The baseband information will be modulated to 2.4G for transmission or demodulation.

BLE host implements data adaptation L2cap, link management gap, base attribute protocol Att,gatt is encapsulated based on ATT and provides interface services to the upper layer to make it easier for users to use ATT for data interaction. Each of them corresponds to one or more tasks for the RW kernel, such as gap management and gap control for two tasks.

The profile layer is based on GATT to provide data communication services to the application layer, each of which is responsible for its own proprietary service functions. For example, there are battery services, device information services, and custom profiles, and so on.

The GATT is responsible for the basic data communication, while profile is the local processing on the basis of the GATT. For example, when the GATT receives a write request from the other party, it notifies profile that the profile decides what to do with the received data, can be written to the attribute field, or not, and the profile can further send a notification to Task_app.

The profiles are independent and equal, as each GATT is equally serviced. Each profile corresponds to a task of the RW kernel.

The application layer is based on multiple profiles to achieve its own needs. Because the RW kernel is essentially a single-tasking kernel, the application layer is a special task. It deals with all profiles, it controls all profiles, and handles message callbacks for individual profiles.

1.2 Task Hierarchy

Based on the above analysis, we can get the following task-level graphs:

1.3 Task List

It is defined in Rwip_config.h, as follows:

It can be seen that the RW kernel supports up to 64 tasks, the link layer task has a high priority, then the profile, then the Task_app.

Second, the RW kernel message processing mechanism based on state machine

The task data structure is as follows:

The RW kernel processes messages based on the state machine. From Ke_task_desc, a task includes an explicit state-handling State_handler and a default state-handling Default_handler.

State is a status machine variable for a task, and a task may have more than one state, then State_handler is a collection of state handles, and each state may handle multiple message callbacks, such as the upper task sending a message to execute the call, or a lower task sending a message to execute the callback.

Messages processed by Default_handler represent messages that the task may receive in any state, such as a disconnect message from the underlying task.

We can also conclude that Ke_state_handler represents multiple message processing in a state. Therefore, State_handler is an Ke_state_handler array, and Default_handler is the Ke_state_handler element.

Third, App_task

As mentioned above, App_task is a special task that interacts with all profile_tasks to execute calls and callbacks. Based on the RW kernel, the state machine message processing mechanism, calls and callbacks are sent by the message to complete the callback.

App_task is Ke_task_create (Task_app, &task_desc_app) to register the message callback, and the Task_desc_app assignment is:

task_desc_app= {NULL, &app_default_handler, App_state,app_state_max, app_i Dx_max};

Visible, App_task only the default message callback interface set App_default_handler. As follows:

The default message callback interface set includes gap-related messages (portions of red circles), such as message events for the BLE initialization process, and data communication message events related to the profile application.

Next, we focus on the gap-related message events and describe the main process of BLE initialization.

Iv. process of initialization

4.1 ble initialization

The Main_func function calls the Rwip_init () interface to initialize the BLE portion of RW. The interface is cured code and is not disclosed externally. During BLE initialization execution, a corresponding message event is emitted to the app_task to tell the app_task the appropriate state to facilitate the app_task to invoke the next phase of initialization.

4.2 Initialization Process Analysis

1. Gapm_device_ready_ind

It can be seen that the first message event emitted when BLE is initialized is gapm_device_ready_ind. The kernel executes the callback Gapm_device_ready_ind_handler, which sends a GAPM_RESET_CMD message to TASK_GAPM, the RESET Gap Management module.

2. gapm_cmp_evt

When the TASK_GAPM reset manages the module, the GAPM_CMP_EVT message event is sent to Task_app, and the kernel executes the Gapm_cmp_evt_handler, which sends TASK_GAPM to GAPM_SET_DEV_ Config_cmd command to complete the BLE device configuration.

3. gapm_cmp_evt

When TASK_GAPM completes the device configuration, the GAPM_CMP_EVT message is sent to Task_app again, and the kernel executes the Gapm_cmp_evt_handler, which calls App_set_dev_config_complete_func , Inside call App_db_init to create the GATT property database.

App_db_init a command message that Xxx_create_db_req create the property database is sent to each profilexxx_task.

4. xxx_create_db_cfm

After each profile call to the GATT interface is completed, a XXX_CREATE_DB_CFM message event is sent to Task_app. The kernel executes the appropriate callback, and the callback sends a APP_MODULE_INIT_CMP_EVT message to Task_app (that is, itself).

5. App_module_init_cmp_evt

The kernel executes the App_module_init_cmp_evt_handler callback, which calls App_db_init again, returning to the 4th step. When App_db_init discovers that all profile property databases have been created, the App_db_init_complete_func interface is called, and the interface starts broadcasting and begins to apply the associated process.

V. Gap establish a message callback for the connection process

Todo

Vi. message callbacks in the data communication process

Todo

References: "um-b-015_da14580 software Architecture v4.0.pdf", "rw-bt-kernel-sw-fs.pdf".

Next article:

The software system of the world's lowest power Bluetooth single chip DA14580

-gap establishing the connection and data communication process

the original team of embedded Penguin Circle consists of senior engineers such as Ali, Meizu, nvidia, godson, Ju Li, and so on. Hundreds of original, two articles a week, sharing embedded, Linux, Internet of Things, GPU, Android, autonomous driving and other technologies. Welcome to sweep code attention to the public number: embedded Penguin ring, real-time push the original article!

World's lowest power Bluetooth monolithic DA14580 software architecture-hierarchical architecture and BLE message Event processing