Feature Request: unlock Bluetooth Mesh™ capabilities buried in BTstack

[theshteves]

I just caught myself reinventing the wheel when I discovered Bluetooth Mesh™ does what I want & more. Fortunately, BlueKitchen has already been working on Bluetooth Mesh™ support for years! I tried to build their hidden example, mesh_node_demo.c, as a template for my project.

Side note: I couldn't find a single GitHub Issue or reason why pico-examples nor pico-extras include mesh_node_demo, unlike the rest of their examples. It has been there for 5 years.

After enough fighting with our build system, this is the most harmonious solution I could work out. I'm excited for other Pico W users to discover mesh networking!

Add CMake library: pico_btstack_mesh

• Set ENABLE_MESH flag by default
• Link all of BTstack's src/mesh/**/*.c
• Include all of pico_btstack_ble (not just pico_btstack_base by default)
• Remove dangling ${PICO_BTSTACK_PATH}/src/mesh/gatt-service/* mesh references from pico_btstack_ble
• TODO: Document in next major Pico SDK release

How can I help?

👇 See Pull Request below

[peterharperuk]

How do we test this with the btstack example?

[theshteves]

Thanks for being so responsive, Peter!

Test added: pico_btstack_mesh_test

I committed a minimum-viable test example for ./lib/btstack/example/mesh_node_demo.c on the same #1692 branch under ./test/pico_btstack_mesh_test. Unlike the other tests, I made this one self-contained for your convenience, so you can quickly reproduce:

cd test/pico_btstack_mesh_test
cmake . -B build
cd build
make

You know CMake better than I do, so you'll know right away how to refactor out my redundant pico_sdk_import.cmake. That will make this test case build more coherently alongside the others. I assume you don't intend on keeping this heavier example, but let me know if you like it.

We could include pico_btstack_ble, pico_btstack_classic, & maybe even build support tests for the other libraries while we're at it? Is this already taken care of somewhere I don't see?

[theshteves]

BTstack also has tests for their mesh subsystem

Running BTstack's mesh subsystem tests

NOTE: I needed to add 2 missing include's in their CMake, so add my 2 lines. Yes, I submitted a PR.

cd $(PICO_SDK_PATH)
cd lib/btstack/test

# cpputest is required for their test suite (see `./lib/bstack/test` README)
git clone https://github.com/cpputest/cpputest.git
cd cpputest
./autogen.sh
./configure
make
sudo make install  # be careful out there.

cd mesh
# Did you add my `CMakeLists.txt` fix noted above?
cmake . -B build
cd build
make

./mesh_message_test -h
./mesh_message_test -lg
./mesh_message_test -g MessageTest

After running in bash on macOS 14, I get all tests passing:

.
OK (39 tests, 39 ran, 1362 checks, 0 ignored, 0 filtered out, 9 ms)

[peterharperuk]

Thanks

[theshteves]

Update: my PR to fix BTstack's mesh tests got merged into their develop branch.

My pico_btstack_mesh abstraction just seems so harmonious with our build system, but pico_btstack_mesh_test doesn't fit naturally with the others. Why? Our tests are a quick gut-check for internal tooling, but with pico_[3rd-party]_test I'd be looking for reassurance that our external/3rd-party submodules don't break our entire build system every new release. That deserves a completely different focus.

💡 Let's Standardize

This is out-of-scope for this Feature Request,
but might be worth a discussion in a separate thread

Instead of bolting on yet another feature, let's make pico_btstack_mesh a more robust abstraction alongside pico_btstack_classic & pico_btstack_ble, by holding all of them to a higher standard. Perhaps I could build out some [build] tests in Python (or maybe CMake has a more native way?) to validate newer versions of our 3rd-party submodules. It'd be nice to auto-verify that recent releases of any of our 5 submodules don't break our builds.

Let me know if you'd like me to discuss that elsewhere & build something out.

---

As for this feature #1692,
how would you like my help most?