NimBLE support for ESP32-C6, H2 and future MCU's and why is Bluedroid still the default?

[h2zero]

Board

esp32-c6-devkitc-1

Device Description

esp32-c6-devkitc-1

Hardware Configuration

nothing

Version

latest master (checkout manually)

IDE Name

all

Operating System

all

Flash frequency

all

PSRAM enabled

yes

Upload speed

any

Description

First, sorry for skirting the default fields, I'm opening this here for discussion and exposure.

Times have changed, classic Bluetooth has become, well, classic, yet the default Bluetooth/BLE stack is still Bluedroid, even though no other Espressif SOC except the original ESP32 has supported Bluetooth classic, why?

This is detrimental to the users that are using one of the many other MCU's that are not the original ESP32.

The latest release has shined the spotlight on the issue, as of now the NimBLE-Arduino library is not able to support the C6 and H2 variants in the 3.x.x releases because the libbt has Bluedroid enabled and the controller is NimBLE based which causes all kinds of conflicts. Would it not make sense to enable NimBLE host for the "other-than-original-esp32-devices" and incorporate the supporting library esp-nimble-cpp, which NimBLE-Arduino is derived from and many use?

Alternatively, maybe have an option to select the BLE stack and link a different 'libbt' for each stack?

If none of this is viable, I understand, close this at your leisure, just thought I'd open some discussion.

Sketch

#include "NimBLEDevice.h"

void setup(){}

void loop(){}

Debug Message

Broke..

Other Steps to Reproduce

No response

I have checked existing issues, online documentation and the Troubleshooting Guide

• I confirm I have checked existing issues, online documentation and Troubleshooting guide.

[me-no-dev]

Moving this to discussion instead

[Jason2866]

Would be great if this would be done. I do exactly this for our Tasmota fork. Well not exactly the same since I enable NimBLE for all MCUs ;-) and use the h2zero esp-nimble-cpp for all BLE stuff. Don't need classic BT for esp32.... It just works :-)

[greubon]

Hello, how do you proceed to "enable NimBLE for all MCUs"?
I am currently trying to use esp-nimble-cpp for a H2 in ESP-IDF (with Aruidno as component), and I'm struggling to make it work.
It works with an ESP32 WROOM, but compilation fails when it turns to do it for a H2...

[Jason2866]

H2 is not tested with esp-nimble-cpp You have to add the H2 here https://github.com/h2zero/esp-nimble-cpp/blob/cabd48aef3c2c7b2947007f76e190633a5ce12fe/CMakeLists.txt#L28

[greubon]

Perfect, it compiles now. For some reasons also my IDF target in variable environment was not well defined too (done using $env:IDF_TARGET="esp32h2). So far the simple client example works, at least. Thank you very much!

[h2zero]

Nobody looks at discussions, I guess this is where it dies... 👎

[jhmaloney]

Can someone post a link to the discussion for this topic?

As an enthusiastic user of NimBLE-Arduino and the entire ESP32 family, I would love to see NimBLE as an option for all ESP32 boards that can support Bluetooth. FYI, I started with Bluedroid but I found that NimBLE had a smaller RAM footprint and excellent performance. (I am only using BLE, not Bluetooth Classic.)

[Jason2866]

@jhmaloney Here #9836
You may try the Platformio build h2zero and I are working on. WiP but should already work

platform = https://github.com/jason2866/platform-espressif32.git#Arduino/IDF-NimBLE

[h2zero]

not true. And this is already in discussion internally also

My apologies @me-no-dev, I was frustrated by spending many hours and not being able to work around the issues that make supporting the new chips impossible. Not many people look at discussions and your own team opened an issue here due to visibility I suppose. I have commented there and what I have said would also allow me to provide support for the new chips.

[me-no-dev]

Switching the BLE stack is no easy decision. The BLE lib has been around now for some good time and we do expect some people to get angry if we switch, so we need to do it properly and easy. Decision has been made and this will happen, but I can not give a timeframe yet. We are a small team and have many things to take care of

[jhmaloney]

FWIW, MicroBlocks started out with the Espressif Bluetooth stack. When we switched to NimBLE, the Flash and RAM footprints went down and performance was the same or better. Of course, nobody likes to be forced to change code that is already written so changing BLE stacks would certainly cause some pain but there are benefits as well.

[Swiftnesses]

[Jason2866]

What is a bad decision, that the change to NimBLE is done taking care to do it nice?