Critical review of several Zephyr features...

Hi,

Of late, I've been evaluating Zephyr in its support of the nrf5340.  I've come across several deficiencies that need to be addressed:

1.  All callbacks (for the most part), lack the ability to have associated "user data" or context information.  This hampers development in C++ where context information is critical to get back to object instances.  Including user data among callback parameters as part of callback registration is a must.  At a minimum, a void * is necessary.

2.  BLE notifications and indication callbacks return only a data pointer and data length.  If these data are destined for a different thread, one must stand on their head to get the data to that thread without the underlying buffer being reclaimed.  Seeing as how a net_buf underlies notification and indication callback parameters, I don't understand why the net_buf isn't provided directly to notification and indication callbacks.  Handing the net_buf off to another thread is then a simple matter of incrementing the reference count in the callback and forwarding the net_buf off to the other thread, allowing the callback to then simply return.

3.  net_buf and simple_net_buf should have been abstracted into a single type instead of two.  The differences should have been abstracted away from the developer.  Right now, it's difficult to maintain a consistent application-level API having two different types.

4.  More thought needs to be put into the polling API.  As an example, the polling interface lacks direct support for timers and mailboxes.  Again, one has to stand on their head to fit these constructs into the polling abstraction.

Thanks.

Related