BLE event handlers, why so many! Plz explain structure!

[SeanHowsonTB]

Afternoon folks,

I'm new to nordic, previously a TI developer. I'm still getting my head around the SDK. I've unfortunately been left with some poorly organised, very-un-annotated firmware to try and decipher. I am currently trying to get my head around the system for handling BLE events:

I'm new to BLE terminology and subsequently i have tried to find best terms to express my understanding, please bare with me:

The code i have. Runs 3 event handlers every time a device is connected (for example). In no particular order, these are: a generic "ble_evt_handler", the register observer for this is set up during BLE stack initialisation. The application also runs a "ble_cus" handler, the register observer for this is set up during a separate initialisation function, before the main superloop. This second handler, contains a function that sets another event, triggering a third event handler "ble_cus_evt_handler" this handler is seemingly associated with the individual service during the initialisation of the service. 

I have seen a similar structure implemented on a few examples, but these examples seemed to split events across the handlers, not pile all events blindly through all 3 handlers. 

1: What is the difference between all of the "smaller", more specific handlers, such as "gatt_evt_handler", "hrs_evt_handler" etc. and the seemingly more global "ble_evt_handler"?

2: Why do these "smaller" handlers need to contain functions that trigger a secondary handler, can the first handler not just service the event itself?

3: Do i really need 3 handlers for a simple event?

4: I come from a background of "simplicity leads to functioning reliable code" - If i were to rationalise this, knowing the application will likely not have a great number of different events to process, is there some way i can do without one or two of these handlers? 

Many thanks,

Sean Howson

-nRf52840 DK, SDK17.0.2, S140, segger embedded studio, windows 10.

[SeanHowsonTB]

Torbjørn,

Thanks for the detailed reply.

To be honest, i was second guessing myself a little with the whole, multi-languge stuff.

I think my current aim is to gain a deeper understanding of the current code, and produce a working build for our upcoming prototyes, but eventually my aim will be to get rid of the C++

ovrebekk said:

Using C++ is very rare for Nordic projects,

...Thats all you had to say!

I'm really not sure why it's been done, besides the preference of the previous developer. But it seems to be causing numerous problems.

I'm still digesting the technical aspects to your reply, but in the meantime, one question has cropped up that i can't seem to find an immediate clear answer to:

We have talked about the "ble_evt_handler" being a "global/big" handler for all events and the other handlers "hrs_evt_handler", for example, only responding to events relevant to them.

This custom handler, which i'm assuming has been made up of butchered code, seems to respond to a great number of events, where might i look for a "list of things that trigger it", in plain english, i'm looking for a list of events from various modules that say "when one of these events happens, trigger the registered observer". Any clues as to where such lists are typically declared for other similar handlers (hrs handler, bas handler, for example)?

Thanks again for all the help. Always appreciated!

Sean

[ovrebekk]

Hi Sean

I don't think there is any simple way to create a list like that, unless you had some powerful code analysis tool that could figure it out. 

It should be possible to find all the places where the event handler is registered with other modules. Either the event handler has to be passed to another module as a function pointer, where it would be stored in some local variable so that it can be called later, or it would have to be called directly by other modules using the function name (in which case the function would have to be declared "extern" in some of the header files). 

Starting with a global file search for the function name would hopefully show all the places the callback is registered, or if it is declared extern. 

Best regards
Torbjørn