Open theshteves opened 2 months ago
How do we test this with the btstack example?
Thanks for being so responsive, Peter!
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?
BTstack also has tests for their mesh
subsystem
mesh
subsystem testsNOTE: 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)
Thanks
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.
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?
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.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
ENABLE_MESH
flag by defaultsrc/mesh/**/*.c
pico_btstack_ble
(not justpico_btstack_base
by default)${PICO_BTSTACK_PATH}/src/mesh/gatt-service/*
mesh references frompico_btstack_ble
How can I help?
👇 See Pull Request below