All Bluetooth wireless systems work the same basic way. The programmer writes the application firmware that calls Bluetooth APIs in the network stack. The stack then talks to the radio hardware, which in turn sends and receives data. When an event happens in the radio hardware, the stack will initiate actions in the application firmware by creating events (e.g., when it receives a message from the other side of the Bluetooth connection). The application code is responsible for processing these events that was pushed up by the stack and doing the necessary post processing for these events. The ROM is preprogrammed with a boot sequence, device driver functions, low-level protocol stack components, and a boot loader. The ROM firmware in CYW207xx handles the Bluetooth stack activities and processes the radio events. The ROM firmware works like a Finite-State Machine (FSM) in handling the Bluetooth events. As an application developer, you do not have to worry about the low-level Bluetooth functionalities.
A minimal C file for an application will look something like this:
#include "wiced.h"
#include "wiced_platform.h"
#include "sparcommon.h"
#include "wiced_bt_dev.h"
/***************************** Function Prototypes *******************/
wiced_result_t bt_cback (wiced_bt_management_evt_t event, wiced_bt_management_evt_data_t *p_event_data);
/***************************** Functions *****************************/
/* Main application. This just starts the BT stack and provides the callback function.
* The actual application initialization will happen when stack reports that BT device is
* ready.
*/
APPLICATION_START ()
{
/* Add initialization required before starting the BT stack here */
wiced_bt_stack_init (bt_cback, NULL, NULL); /* Register BT stack callback */
}
/* Callback function for Bluetooth events */
wiced_result_t bt_cback (wiced_bt_management_evt_t event, wiced_bt_management_evt_data_t *p_event_data)
{
wiced_result_t result = WICED_SUCCESS;
switch (event)
{
/* Bluetooth stack enabled */
case BTM_ENABLED_EVT:
/* Initialize and start your application here once the BT stack is running */
break;
default:
break;
}
return result;
}
The purpose of an RTOS is to reduce the complexity of writing embedded firmware that has multiple asynchronous, response time critical tasks that have overlapping resource requirements. The RTOS maintains a list of tasks known as threads that are in different states such as active, inactive, or scheduled, and executes these tasks based on their priorities. Multi-threaded applications that make use of SoC peripherals should handle thread synchronization in the application when there are resource conflicts such as shared memory, mutual exclusion, hold and wait, and circular wait.
The RTOS in the ROM firmware creates multiple threads immediately after the bootup for handling the Bluetooth functionality and then gives control to the application thread. Currently, ModusToolbox supports multiple RTOSs. The device ROM has ThreadX by Express Logic built in and the license included, which makes this the best choice for developing applications with CYW207xx. To simplify using multiple RTOSs, the BT SDK has a built-in abstraction layer that provides a unified interface to the fundamental RTOS functions. You can find the documentation for the WICED RTOS APIs at Cypress WICED CYW20719: RTOS
