World's lowest power Bluetooth single chip DA14580 software system-RW kernel and message processing mechanism

The hardware architecture and low power consumption of the Bluetooth single chip DA14580 describes the DA14580 hardware architecture and the low power consumption principle. This paper expounds the software system of the platform, and emphatically analyzes the processing mechanism of the message event.

First, DA14580SOC hardware composition and software system composition

The DA14580 chip hardware architecture consists of three parts:

1) use Arm Company's Cortex M0 as the Cpuprocessor processor.

2) Use Rivierawaves Company's IP core as the Blecore and baseband, RF part.

3) Integrated clock management CMU, power management PMU, memory control storage and other peripheral module controllers such as Gpio, UART, I²c, SPI and timer, etc.

Accordingly, the software component of the DA14580 Platform SDK also includes the following components:

1) Armcortex M0 platform-related library files, such as startup, CMSIS (the Cortex Microcontroller software interface standard) supported register access, interrupt exception provider, and so on.

2) RW's ble drive, RF driver, and RW ble also integrates the kernel part of the system, which provides core functions such as message processing, timers, and task scheduling. So the development of the DA14580 Platform SDK is based on the core developed by RW, not the dialog company. Most of the code in this section is cured in ROM.

3) The driver of other modules of Soc integration, provided by dialog company, such as UART driver, and it calls the relevant interface of RW kernel to complete the message loop and low power function.

4) application, call the above three-part interface to complete the custom function.

We focus on the RW kernel mechanism and features in 2.

Second, RW core

The RW core guidance document is "Rw-bt-kernel-sw-fs.pdf". It mainly consists of the following three parts:

1) message, messaging mechanism.

2) Taskand Schedule, Task and dispatch.

3) timer, how to use the timer.

Third, Task

RW Abstracts Multiple task Tasks on the basis of the BLE protocol stack level, each task completes a software level function. So the RW kernel supports multiple task tasks, but in essence, the RW kernel is also a single-tasking kernel, so each task can be seen as an independent function body or a collection of functions capable of accomplishing certain functions.

Each task has a task ID, which has a priority function, similar to the priority of Ucos.

The difference between the RW kernel and the ucos is that the ucos is a multitasking kernel that has time slices in turn and has a mutex synchronization.

Iv. Message

4.1 Message ID

A message distinguishes between what task it belongs to and the different messages within the same task. So a message consists of two parts:

Task_type is the ID of the task. At dispatch time, the message of a high-priority task is processed first.

4.2 Message struct elements

We just need to focus on the five elements in the red circle, and the first element can see that the message struct nodes are managed in the form of a linked list. HCI is related to the USB dongle this application form, controlled by the PC host Bluetooth ble, we do not discuss this application.

The five elements of the red circle are:

1) ID, which is the 1th message identity.

2) which target task the message is processed by.

3) The task that sent the message

4) Length of message parameters

5) Structure address of the message parameter

The message parameter structure can be customized, where the incoming address is converted by void*.

4.3 Message dynamic memory management

The RW kernel provides a dynamic memory management mechanism specifically for message processing, with the following interfaces:

Void*ke_msg_alloc (ke_msg_id_t const ID, ke_task_id_t const dest_id,

ke_task_id_t Const src_id,uint16_t const param_len);

Generally, a macro is provided for the application to simplify the notation:

#defineKE_MSG_ALLOC (ID, dest, src, param_str) \

(struct param_str*) ke_msg_alloc (ID, dest, src, sizeof (STRUCTPARAM_STR))

The release interface is: void Ke_msg_free (struct ke_msg const *param);. In the scheduling mechanism, the message is processed by judging the return value of the message processing, such as freeing the memory of the message. User programming generally does not call the release interface.

4.4 Message Interface

1) message sending with parameters

Voidke_msg_send (void const *param_ptr); Param_ptr needs to request dynamic memory via the Ke_msg_alloc interface.

The General Command message is sent in the following notation:

structgapm_set_dev_config_cmd* cmd = Ke_msg_alloc (Gapm_set_dev_config_cmd,

TASK_GAPM, Task_app,gapm_set_dev_config_cmd);

Ke_msg_send (CMD);

2) Send message without parameters

Voidke_msg_send_basic (ke_msg_id_t const ID, ke_task_id_t const dest_id,ke_task_id_t const src_id)

Five, TIMER

5.1 Timing Units

The 10MS,RW core provides a timer that is not DA14580 integrated TIMER1 and TIMER3. The initialization of the timer is done in the BLE initialization, and does not require user programming settings. The user only needs to invoke the RW kernel's timer interface.

5.2 Setting up a timer

Voidke_timer_set (ke_msg_id_t const TIMER_ID, ke_task_id_t const task, uint16_tconst delay);

TIMER_ID is a timer message, which belongs to a message,delay with no parameters is the timing time, 10ms units, when the time arrives, the RW kernel will send timer_id to the target task of the message queue. The corresponding callback for the timer is executed when the kernel schedule.

Liu, Schedule

1. First remove the message event for the highest priority task, which pops out of the message queue

2. Get the corresponding handler based on the status of the task and the message ID

3. Execute the handler callback

4. Processing the message based on the return value of the callback

1) If Ke_msg_consumed is returned, the kernel free will drop the message.

2) If Ke_msg_no_free is returned, the kernel does not process the message, but the message is not re-placed in the message queue, that is, the kernel can no longer obtain the message from the message queue.

3) If ke_msg_saved is returned, the kernel does not free the message, and the message is into row again.

Seven, 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.

Viii. Reference Documents:

"Um-b-015_da14580 Software Architecture V4.0.pdf",

"Rw-bt-kernel-sw-fs.pdf".

Next, please look forward to:

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

-Hierarchical architecture and BLE message event handling process

Technical advice please email: [Email protected].

hundred percent original, two articles per week, Ali, Meizu, nvidia, godson, Ju Li, top enterprise senior engineers to share----embedded, Linux, Internet of Things, GPU, Android, autonomous driving technology, welcome to sweep code attention to the public number: embedded Penguin ring, Push original articles in real time!

World's lowest power Bluetooth single chip DA14580 software system-RW kernel and message processing mechanism