C version of the API? about ble HOT 4 CLOSED

Hi Myles,

Which part of C++ is a showstopper for you?
If you study the demos, you'll find that there's hardly any C++ being used apart from instantiating a BLEDevice or a few BLE services; or perhaps classes which abstract the hardware. You're free to write the rest of your application in C if you prefer.

Is it the BLE API which you'd like to see written in C? Or is it the larger mbed API which you'd have in C? Please continue this discussion; your feedback could help us re-orient ourselves. thanks.

from ble.

Hi Rohit,

Thanks for the quick response.

I'm interested in using and extending the BLE API. Our project is written in C, and I'm worried that the necessary wrappers will add too much overhead in terms of size/execution time. C seems a lot easier to include in C++ than C++ is in C.

I'm working with an nRF51822, and I'd like to get to the point where the entire project is open source. It seems like it would be a much simpler road if BLE_API were in C. I'm open to suggestions, though.

Thanks,
Myles

from ble.

The C++ wrappers making up the BLE_API are very lightweight. Using them will not cause any performance or code bloat. C++ has come a long way in being efficient. Using C++ brings the benefit of much better compile-time checking and introduces near-zero run-time overhead.

Does your toolchain support C++?

If you really need everything to be C-only, you'll have to de-contruct every class BLE_API into a module and pass around extra pointers to structs. There are not too many classes in BLE_API, and this deconstruction can be achieved within a small amount of effort.

The Nordic SDK is in C. BLE_API only adds the benefit of being cross-platform. If you are not going to aim for portability, then you can also consider using the Nordic SDK directly.

from ble.

I agree. I didn't mean to imply that the C++ code in BLE_API were poorly written. My toolchain supports C++, but the project definition doesn't. I didn't want to use the Nordic API directly, because I wanted to support an open-source API. I was mostly surprised that C++ was chosen to wrap a C API. Presumably future APIs that you are targeting may be written in C++.

Thanks for your work. I agree that deconstructing the classes wouldn't be too much work. That may be the way forward for me.

from ble.