CC2640R2F BLE5.0 Application Framework

Application

Beginning with this chapter, we will explain in detail the application framework of the cc2640r2f BLE5.0, which we previously wanted to have stored the knowledge of the hardware and software architecture of the CC2640R2F platform in accordance with our learning route map. Understand application engineering to differentiate between app and stack engineering management. Here we mainly explain the framework of app application based on Ti-rtos.

Here is an introduction to the Simple_peripheral Demo Application section, which includes the following: Pre-main initialization ICall Simple peripheral Task intertask Messages

Note: Gaproletask is also part of the project, but we put it in the protocol stack section for discussion and its function is closely related to the protocol stack. Pre-main Initialization

The main function is contained in the resource file main.c of the IDE Startup folder. As the entry of the program, it mainly completes the global interrupt disable, peripheral driver initialization, power management, Ti-rtos task creation or construction, enabling Sys/bios kernel scheduling when the global interrupt is enabled. The main function does not return and will retain its resources throughout the project life cycle;

Basic MAIN.C function.

int main ()
{/
  * Register application callback to trap asserts raised in the Stack *
  /Registerassertcback (Asser Thandler);

  Pin_init (boardgpioinittable);

  #ifndef power_saving
    /* Set constraints for Standby, Powerdown and idle mode *
    /Power_setconstraint (powercc26xx_ Sb_disallow);
    Power_setconstraint (powercc26xx_idle_pd_disallow);
  #endif//power_saving/

  * Initialize ICall module */
  icall_init ();

  /* Start tasks of external images-priority 5 *
  /Icall_createremotetasks ();

  /* Kick off profile-priority 3 *
  /Gaprole_createtask ();

  Simplebleperipheral_createtask ();

  /* Enable interrupts and start Sys/bios *
  /Bios_start ();

  return 0;
}

Note: The above code icall message module must be initialized by Icall_init () and completed with the Icall_createremotetasks () completion of the protocol stack task. ICALL Introduction

In the Software Architecture section we explained that for historical compatibility reasons the entire application engineering is differentiated app and stack two project management, it is based on such a two engineering design, the communication between the app and the stack needs to reconsider, Because we have no way to accomplish message passing like regular API calls and global variables. TI introduces the Icall messaging mechanism to complete the communication between the app and stack independent engineering management. Here we focus on understanding the principles and code implementations, because they account for a large part of our program.

The Indirect call Framework (ICall message framework) provides services based on Ti-rtos (for example, synchronization threads, messages, events) to complete the BLE protocol stack and the application's message interaction in both projects, The application and protocol stack are guaranteed to run efficiently, communicate with each other and share resources in a unified ti-rtos environment.

The core component of the Icall architecture is its message dispatch (dispatcher), whose helper completes the Ble5-stack protocol stack and the application interaction in the library configuration in two mirrors/projects. Although most icall interactions have been abstracted in Ble5-stack APIs (such as GAP,HCI, etc.), we must understand their infrastructure that works properly in ble-stack and multithreaded RTOs environments.

ICALL source code in the application engineering (such as our simple_peripheral here) ICALL Ble/icall folder path.

ICall BLE5 Protocol stack service side

As shown in the figure above, the Icall implementation contains a communication between a client entity (for example, our application) and a server entity (that is, the BLE5.0 protocol stack here).

Note: Correctly differentiate the CS architecture of the Icall framework and the structure of the GATT server and client, which is implemented primarily by the BLE protocol stack.

TI is designed so that we have already talked about: implementation of the application and BLE stack of independent management and firmware update, from the traditional platform (i.e. cc254x osal) ported to CC2640R2F Ti-rtos, maintain API consistency;

ICall serves as the service interface for the BLE5 protocol stack API. When we need to invoke some protocol stack interfaces, the Icall module automatically distributes the commands (that is, dispatches) to the BLE5 protocol stack and uploads the message from the BLE5 protocol stack results back to the application.

Because the Icall message module itself is part of the application project, the application task can directly access Icall through function calls. Because the BLE protocol stack task always executes at the highest priority, but the application is not in a blocking state when there is no data return, some APIs are bound to respond immediately at the protocol stack task, and the application task can only wake up when the message is distributed through Icall. Other APIs only wait for the application task to return the results asynchronously through Icall (event update). Icall Primitive Services

Icall contains a series of primitive services that are abstracted into an RTOS-related function interface. Because of the communication between shared resources and threads, the application must use the following Icall primitive service features: Message delivery and thread synchronization heap allocation and management messaging and thread synchronization

Icall messaging and thread synchronization with the protocol stack are all based on Ti-rtos multithreading.

Icall two tasks message delivery occurs when a blocking message is sent through Message Queuing. The sender allocates a piece of memory dynamically, writes the contents of the message to memory, and then sends (that is, queues) the memory to the receiving thread before using the event flag. The accept task wakes up after the event flag is received, replicates the memory message, and processes, and then releases the memory block.

The protocol stack uses Icall to notify and send messages to the application. Icall passes these service messages, the application task receives it and then processes it. heap allocation and management

Icall provides a global heap-managed API for applications for dynamic memory allocation. The size of its heap is configured by macro heapmgr_size. For more details on managing dynamic memory, see dynamic memory allocation. The icall of the BLE protocol stack uses this heap management for all message-related memory management, and we also recommend that applications use these Icall APIs to allocate dynamic memory. Icall Initialization and registration

To instantiate and initialize the Icall service, the application must call the function in the code snippet in main () before starting the Ti-rtos kernel scheduler:

Required code to use Icall.

/* Initialize the ICall module * 
/ICall _init ();

/* Start the Protocol stack task-priority * 
/ICall _createremotetasks ();

Call Icall_init () to initialize the ICall primitive service (for example, heap management) and the framework, calling ICall _createremotetasks () to create but not start ble5-stack tasks. Before using the Icall protocol service, the server and client are registered and registered separately. The server needs to register a service at compile time. The enlistment function distinguishes each service by using a global unique identifier, which is also used as the back communication address. For example, the BLE protocol uses icall_service_class_ble to do some identification of the message interaction of the Bluetooth protocol stack ICALL.

For service-side registrations, included in the osal_icall_ble.c file

/*icall Server Registration */ 
ICall _enrollservice (ICall _service_class_ble, NULL, &entity, &synchandle);   

The client needs to register before the Icall dispatcher sends and/or receives messages.

For clients that use BLE5API, such as application tasks, the client must first register its tasks with Icall. This registration typically occurs in the application's task initialization function. The following code fragment is registered in Simple_peripheral_init simple_peripheral.c.

Icall Client Registration

Before completing the client registration, it is necessary to pass in the struct variables selfentity and syncevent, whose values are initialized when the function returns, and then the service side passes the two variables for message passing. The Syncevent parameter represents the event ID, selfentity represents the purpose task for processing the message, and is the source address for subsequent communication by the client entity, and each client registering Icall needs to use a unique syncevent and selfentity.

Note: The Icall related API defined in the ICALLBLEAPI.C file cannot be called until the client registers the Icall service. Icall thread Synchronization

Icall uses Ti-rtos events for thread synchronization instead of semaphores.

In order for the client or server to remain blocked until the message is received, Icall provides the following blocking API to keep the task blocking state until the associated semaphore is post:

UINT Event_pend (Event_handle Handle, uint andmask, uint ormask, UInt32 timeout);

The handle represents the handle (identifier) of the constructed event_handle. Andmask and Ormask Select the event flags to block/suspend for the user. Timeout is the time-out period in milliseconds. If it has not been returned after this time-out range, the function returns.

The Event_pend function indicates that blocking the current task waits for an event flag bit to occur.

There are 32 event flag bits (int types) that can be defined for their specific purpose. However, it is important to note that the Icall message queue has reserved a specific event flag bit.

Events associated with the Ti-rtos thread are issued/published when called by Event_post required flags

The event_post is used by the client/server to activate a task blocking task into a running state and perform the specified action by sending the corresponding flag bit.

void Event_post (Event_handle handle,uint eventmask);

The above event handle handle is obtained after the service-side Icall _enrollservice () and Icall _registerapp () are called.

Danger: Do not call the Icall function from the protocol stack callback. This operation may cause Icall to abort (using Icall_abort ()) and interrupt the system. Example Icall usage

The following illustration shows a sample command sent from an application to ble5-stack through the Icall framework, and returns the corresponding return value back to the application.

ICall _init () completes initializing the ICall module instance, and Icall_createremotetasks () creates a task for the protocol stack using the entry function for the known address.

The initialized Icall,app is registered as a client through Icall_registerapp ().

After the Sys/bios scheduler starts and the application task runs, the application sends a protocol command that is defined in ble_dispatch_jt.c such as Gap_getparamvalue ().

The protocol command is not executed in the application's thread, but is encapsulated in the Icall message and sent to the Ble5-stack task through the Icall framework. The command is sent to the Icall scheduler, which is dispatched and executed in the Ble5-stack context. The application thread is blocked at the same time until the corresponding command status message is received. Ble5-stack completes the execution of the command, and then sends the command status message response back to the application thread through Icall. An example diagram of this interchange is shown below.

The Ble-stack project is a direct-to-the-go app code that runs Ti-rtos a task in the app , and the following code snippet creates a protocol stack task.

C:\TI\SIMPLELINK_CC2640R2_SDK_1_35_00_33\SOURCE\TI\BLE5STACK\ICALL\SRC\ICALL.C  Icall_createremotetasks Line  519

void icall_createremotetasks (void {
  size_t i;
  UInt Keytask;
  /* CHEAP locking mechanism to lock tasks
   * Which-attempt to access the service call dispatcher