gh-raspberrypi/pico-sdk

Watch

Fork 0

Feature Request: unlock Bluetooth Mesh™ capabilities buried in BTstack #1691

New issue

Closed

opened 2024-04-23 20:02:10 -05:00 by theshteves · 6 comments

theshteves commented

2024-04-23 20:02:10 -05:00

(Migrated from github.com)

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

I just caught myself reinventing the wheel when I discovered [Bluetooth Mesh™](https://www.bluetooth.com/learn-about-bluetooth/feature-enhancements/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`](https://github.com/bluekitchen/btstack/blob/72ef1732c954d938091467961e41f4aa9b976b34/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`](https://github.com/raspberrypi/pico-examples) nor [`pico-extras`](https://github.com/raspberrypi/pico-extras) include [`mesh_node_demo`](https://github.com/bluekitchen/btstack/blob/72ef1732c954d938091467961e41f4aa9b976b34/example/mesh_node_demo.c), 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` - [x] Set `ENABLE_MESH` flag by default - [x] Link all of BTstack's `src/mesh/**/*.c` - [x] Include all of `pico_btstack_ble` (not just `pico_btstack_base` by default) - [x] Remove dangling ` ${PICO_BTSTACK_PATH}/src/mesh/gatt-service/*` mesh references from `pico_btstack_ble` - [x] TODO: Document in next major Pico SDK release How can I help? 👇 See Pull Request below

peterharperuk commented

2024-04-24 08:24:45 -05:00

(Migrated from github.com)

How do we test this with the btstack example?

theshteves commented

2024-05-01 01:28:14 -05:00

(Migrated from github.com)

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?

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`](https://github.com/raspberrypi/pico-sdk/pull/1692/commits/3534dbbba322935f6a446e4af6aedb15d2ff4ae0). Unlike the other tests, I made this one self-contained for your convenience, so you can quickly reproduce: ```bash 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 commented

2024-05-01 02:27:51 -05:00

(Migrated from github.com)

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)

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](https://github.com/bluekitchen/btstack/pull/591), so add my 2 lines. Yes, I submitted a PR. ```bash 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: ```bash . OK (39 tests, 39 ran, 1362 checks, 0 ignored, 0 filtered out, 9 ms) ```

peterharperuk commented

2024-05-01 04:18:19 -05:00

(Migrated from github.com)

Thanks

theshteves commented

2024-05-07 00:14:27 -05:00

(Migrated from github.com)

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?

Update: [my PR to fix BTstack's mesh tests](https://github.com/bluekitchen/btstack/pull/591) got merged into [their develop branch](https://github.com/bluekitchen/btstack/tree/develop). 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?](https://cmake.org/cmake/help/book/mastering-cmake/chapter/Testing%20With%20CMake%20and%20CTest.html))** 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?

kilograham commented

2024-11-23 12:40:27 -06:00

(Migrated from github.com)