BLE cordio status inside MaxIDE 32666FTHR

[thinking-binaries]

I am evaluating your MAX32666FTHR platform and IDE.

Could you answer:

1. Which version of Mbed OS is this built from?
2. Which version of the ARM PacketCraft cordio BLE is bundled? 2019 seems very old?
3. Do you support the C++ API, I didn't understand why your BLE demos such as BLE_dats use C rather than C++?
4. Why are there so many include files in the BLE_dats .c files, and also you seem to include header files from directories in the cordio stack that are not public API's (and paths are missing from the include paths as such). Many includes are from a path ending /include but there are some that are from non /include folders, and seem to be accessing internal code directly from the /sources folders, which seems to break the API abstraction.
5. The BLE_dats example is terribly complex, and doesn't seem to match up to any of the documentation I have found on the ARM MBED OS/cordio website. Do you have a set of simpler examples with many less include files and much less complex 'knitting' code, that just uses the API directly? All we want to do is send and receive a few bytes of data to a mobile phone, this set of examples look terribly complicated?

[thinking-binaries]

A lot to absorb here. Note we are at evaluation stage; if evaluation indicates additional pre-work is required to repackage examples into more useful starting points, that work can sometimes be rolled into future development plans. But it would be nicer if your examples were simpler :-)

I think a useful signpost at this point might be whether there are other simpler examples, whether there are C and C++ examples, and whether there are any plans to take the existing BLE_dats and other BLE examples and wrap them in helpers and surface a 'simple get going quick' API we can all build forward from.

The simplest API for me would be to include ble.h, call an init() function with the node advertisement name, perhaps call a register_attrs() function with a reference to an application specific attribute table that points to attribute variables, and call a tick() function that provides any necessary BLE stack processing. An app can then update attribute variables directly with very low coupling to everything else, and focus on doing what the app is designed to do, rather than getting sucked into understanding what all the moving parts of the BLE cordio stack does.

It might also simplify includes and paths, if our apps only have to include a single header file.

For the majority of cases, that allows anyone evaluating and developing production code, to build a system based on GATT attributes super quickly.

The points about mbed os and cordio version numbering becomes super important if we need to dig into all those moving parts, as we need to make sure we are using the correct version of the docs for the BLE stack that is bundled (as cordio seems to be moving regularly and quite quickly!). If the getting started example is super simple and allows the 80% of simple apps to be built really fast, doc versioning is less important I think.

[Jake-Carter]

Currently, the MSDK only supports C, not C++. Our build system is set up only at the most basic level. There is some significant work to be done to add C++ support, but it's something that we are looking at in the future.

We don't use Mbed OS in the MSDK. Instead, we've built up our own platform abstraction layer for our hardware and ported into the Cordio stack directly. It should be noted that our physical layer library contains proprietary info and is closed-source. It's distributed as a pre-compiled static library with stripped debug symbols. So you will be able to debug into the Cordio library functions up to, but not including, the BlePhy library.

@kevin-gillespie can offer some more insight into the library and examples organization

[kevin-gillespie]

Thanks for the feedback. It's a delicate balance to keep things simple and flexible at the same time. The BLE_periph is a better example to get started with.

The Cordio library that we use is forked from this repo.

https://github.com/packetcraft-inc/stacks

[thinking-binaries]

Thanks @kevin-gillespie and @Jake-Carter I will take a look at the BLE_periph example.

FWIW, I am finding the API's for all the on chip peripherals excellently written and really easy to integrate with, I particularly like the fact that you have provided low level, transactional, sync and async and DMA services for all the ones I have used already.