Closed eiffel31 closed 7 months ago
Hi, thanks for your attention.
ESP-IDF supports multiple Bluetooth HOSTs, one of which is Apache MyNewt NimBLE.
In order to easily pull the latest updates from the NimBLE repository, we cloned the original repository and added it to our components/bt
as it is in /host/nimble/nimble
as a submodule of IDF.
Therefore, the file structure and content of this repository are very similar to the original nimble. The original nimble structure not only includes the host, but also includes the controller part, the hci part and some examples (the file name is apps
in their file tree), which is the repeated part you see.
In the compilation structure of IDF, only the contents of host, a part of HCI and a part of porting are compiled, and other contents are not within the scope of our compilation, so this part is not a repeated part in the project. Other parts are kept as they are for the convenience of updating the source.
We have a set of menuconfig
to control what host to use and what functions to use. In the other question you mentioned, it was designed based on similar considerations.
I hope these answers can help you, and please feel free to ask any questions.
Hi, thanks for your response.
So, components/bt/host/nimble/nimble
is just a clone.
Please correct me if I am wrong, examples/bluetooth/nimble/bleprph
is not a clone. As it is an example, I expect it to show the recommended way to use a feature. So I guess that making a copy from the file provided in the components
hierarchy is a bad idea and the example should show how to write the application without this copy but using the provided file at the original location in order to benefit from future updates/fixes.
Yes, components/bt/host/nimble/nimble
is a clone and examples/bluetooth/nimble/bleprph
is a demo we provide that was adapted from the original repository to our ESP-IDF. You can start here, it is a very simple example of creating a BLE GATT server. The demo is described in the README file.
OK, So I think this example has to be modified in order to use the gatt_svr.c file available in the components
hierarchy instead of duplicating this file is the example project.
Oh, it might not be what you think it is. The gatt_svr.c
file is not actually a part of the component, its content is highly customized as needed. Different applications will implement different service functions and handle different content, so we should not put gatt_svr.c
in components
.
Looks like the security part is a gatt service that has to be implemented the way it is shown here, but I may be wrong. I have no good understanding of this part for now.
If my understanding is correct, the gatt_svr file could contain only the security part and be part of the standard files, being left untouched. Then the application can add it's own services by registering them to the gatt server with ble_gatts_add_svcs(my_ble_services);
You can look at the gatt_svr.c
file in several other examples that set up different GATT services based on the example functionality in the example. It's not just the security part.
I think it is too complex to start writing BLE code with such examples.
A minimal example with only the mandatory part would be very helpful.
Thanks
Hi @eiffel31 , recently readme and tutorials with walkthroughs for most of the examples were added in IDF code that highlights and explains various code segments of the example. Please let us know if it is still complex to understand the code, as we have tried to make it more self explanatory via this documentation.
Closing issue as README files / tutorials are updated with more information.
Is your feature request related to a problem?
Trying to use standard BLE UUID, I searched for existing definition in esp-idf.
I searched for 0x2A26. It is written many times in .h files. The perfect situation would be to have this constant written at one place only and used many times.
components/bt/esp_ble_mesh/mesh_core/include/mesh_uuid.h:#define BLE_MESH_UUID_DIS_FIRMWARE_REVISION BLE_MESH_UUID_DECLARE_16(0x2a26) components/bt/esp_ble_mesh/mesh_core/include/mesh_uuid.h:#define BLE_MESH_UUID_DIS_FIRMWARE_REVISION_VAL 0x2a26 components/bt/host/bluedroid/api/include/api/esp_gatt_defs.h:#define ESP_GATT_UUID_FW_VERSION_STR 0x2A26 components/bt/host/bluedroid/stack/include/stack/gattdefs.h:#define GATT_UUID_FW_VERSION_STR 0x2A26 components/bt/host/nimble/nimble/nimble/host/services/dis/include/services/dis/ble_svc_dis.h:#define BLE_SVC_DIS_CHR_UUID16_FIRMWARE_REVISION 0x2A26
Given this observation, it is not easy to understand the right way to do user code using standard UUID.
It is also difficult to understand the correct way to develop some BLE application because there is massive duplicated code between components and example.
For example, these 2 files: components/bt/host/nimble/nimble/apps/bleprph/src/gatt_svr.c examples/bluetooth/nimble/bleprph/main/gatt_svr.c
They differ by white spaces and 3 lines of code (3 init calls).
Is it on purpose there is so much "gatt_svr.c" files in the components? components/bt/host/nimble/nimble/apps/blecsc/src/gatt_svr.c components/bt/host/nimble/nimble/apps/blehr/src/gatt_svr.c components/bt/host/nimble/nimble/apps/bleprph/src/gatt_svr.c components/bt/host/nimble/nimble/apps/btshell/src/gatt_svr.c components/bt/host/nimble/nimble/apps/mesh_badge/src/gatt_svr.c examples/bluetooth/nimble/ble_phy/phy_prph/main/gatt_svr.c examples/bluetooth/nimble/ble_spp/spp_server/main/gatt_svr.c examples/bluetooth/nimble/blehr/main/gatt_svr.c examples/bluetooth/nimble/bleprph/main/gatt_svr.c examples/bluetooth/nimble/bleprph_wifi_coex/main/gatt_svr.c examples/bluetooth/nimble/throughput_app/bleprph_throughput/main/gatt_svr.c
Is it on purpose there is so much main.c files is the components? components/bt/esp_ble_mesh/mesh_core/main.c components/bt/host/nimble/nimble/apps/advertiser/src/main.c components/bt/host/nimble/nimble/apps/blecent/src/main.c components/bt/host/nimble/nimble/apps/blecsc/src/main.c components/bt/host/nimble/nimble/apps/blehci/src/main.c components/bt/host/nimble/nimble/apps/blehr/src/main.c components/bt/host/nimble/nimble/apps/blemesh/src/main.c components/bt/host/nimble/nimble/apps/blemesh_light/src/main.c components/bt/host/nimble/nimble/apps/blemesh_models_example_1/src/main.c components/bt/host/nimble/nimble/apps/blemesh_models_example_2/src/main.c components/bt/host/nimble/nimble/apps/blemesh_shell/src/main.c components/bt/host/nimble/nimble/apps/bleprph/src/main.c components/bt/host/nimble/nimble/apps/blestress/src/main.c components/bt/host/nimble/nimble/apps/btshell/src/main.c components/bt/host/nimble/nimble/apps/bttester/src/main.c components/bt/host/nimble/nimble/apps/central/src/main.c components/bt/host/nimble/nimble/apps/ext_advertiser/src/main.c components/bt/host/nimble/nimble/apps/mesh_badge/src/main.c components/bt/host/nimble/nimble/apps/peripheral/src/main.c components/bt/host/nimble/nimble/apps/scanner/src/main.c components/bt/host/nimble/nimble/porting/examples/dummy/main.c components/bt/host/nimble/nimble/porting/examples/linux/main.c components/bt/host/nimble/nimble/porting/examples/linux_blemesh/main.c components/bt/host/nimble/nimble/porting/examples/nuttx/main.c components/cmock/CMock/examples/make_example/src/main.c components/esp_system/test_eh_frame_parser/main.c components/openthread/openthread/examples/apps/cli/main.c components/openthread/openthread/examples/apps/ncp/main.c components/openthread/openthread/src/posix/main.c components/spiffs/spiffs/src/test/main.c
Thank you for your clarifications
Describe the solution you'd like.
Having 2 BLE examples would be great:
The purpose is to understand the BLE requested base part and how/where to add application specific parts.
Describe alternatives you've considered.
No response
Additional context.
No response