This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

To properly set up a ble peripheral app, how many CBs do I have to register?

Hello, I'm trying to migrate an Atmel project to nrf51822 chip.

Now, in the original project there were 2 CB arrays registered, one dealing iwth GATT one with GAP:

a little sneak-peak:

ble_mgr_events_callback_handler(REGISTER_CALL_BACK, 
								BLE_GAP_EVENT_TYPE, 
								ble_mgr_gap_handle);
ble_mgr_events_callback_handler(REGISTER_CALL_BACK,
								BLE_GATT_SERVER_EVENT_TYPE,
								ble_mgr_gatt_server_handle);

and please note that the CBs, ble_mgr_gatt_server_handle for example, is an array of "smaller" CBs, each dealing with a specific situation:

 static const ble_event_callback_t ble_mgr_gatt_server_handle[10] = {
NULL,
NULL,
NULL,
NULL,
NULL,
NULL,
ble_mtu_changed_indication_handler,
ble_mtu_changed_cmd_complete_handler,
ble_characteristic_write_cmd_complete_handler,
NULL
};

Its counterpart/equivalent however, looks something like this:

static void ble_evt_dispatch(ble_evt_t * p_ble_evt)
{
dm_ble_evt_handler(p_ble_evt);
ble_hrs_on_ble_evt(&m_hrs, p_ble_evt);
ble_bas_on_ble_evt(&m_bas, p_ble_evt);
ble_conn_params_on_ble_evt(p_ble_evt);
bsp_btn_ble_on_ble_evt(p_ble_evt);
#ifdef BLE_DFU_APP_SUPPORT
/** @snippet [Propagating BLE Stack events to DFU Service] */
ble_dfu_on_ble_evt(&m_dfus, p_ble_evt);
/** @snippet [Propagating BLE Stack events to DFU Service] */
#endif // BLE_DFU_APP_SUPPORT
on_ble_evt(p_ble_evt);
ble_advertising_on_ble_evt(p_ble_evt);
}

So my questions:

  1. How many callbacks do I have to register in order to run an app on nrf51822 ble, using hearte rate sensor as example? The categorization of callback-registering doesn't seem to be in the GATT vs GAP style.

  2. Are those "sub-callbacks" or those "smaller" callbacks library function or completely "made up" by users? If they are arbitrarily "made up", please ignore question no.3. If not, please continue reading.

  3. If you could, please list those "sub-callbacks" or those "smaller" callbacks which are essential to the smooth running of the app. In other words, if some callbacks "are better left untouched"/"doesn't really have to be modified" - I can safely skip them and reduce my workload.

Parents
  • Hi Mitch,

    1. There isn't a split between GAP and GATT callbacks/event. They are all can be handled inside ble_evt_dispatch(). If you use our library (device manager for example), you don't need to register any more handler.

    2. I assume you are talking about ble_hrs_on_ble_evt() (for example) as "sub-callback" ? They are event handler of a service. Any service can subscribe to the events dispatch and handle events that it's interested in. It's completely up to the application what to do with the event.

    3. The question is what do you want to do with your application, for example if you want to handle an event. For example if there is a write request to a characteristic , then turn on an LED. Then you need to write that handler to catch the write event then turn on the LED.

    dm_ble_evt_handler() for example , is belong to the device manager library ,and you can leave it untouch. Other handler, is the service handler, if you don't plan to use it you can skip it. Or if you want to include it hrs for example, you just leave it as it is.

Reply
  • Hi Mitch,

    1. There isn't a split between GAP and GATT callbacks/event. They are all can be handled inside ble_evt_dispatch(). If you use our library (device manager for example), you don't need to register any more handler.

    2. I assume you are talking about ble_hrs_on_ble_evt() (for example) as "sub-callback" ? They are event handler of a service. Any service can subscribe to the events dispatch and handle events that it's interested in. It's completely up to the application what to do with the event.

    3. The question is what do you want to do with your application, for example if you want to handle an event. For example if there is a write request to a characteristic , then turn on an LED. Then you need to write that handler to catch the write event then turn on the LED.

    dm_ble_evt_handler() for example , is belong to the device manager library ,and you can leave it untouch. Other handler, is the service handler, if you don't plan to use it you can skip it. Or if you want to include it hrs for example, you just leave it as it is.

Children
No Data
Related