Bluetooth classic

[msacker]

Hi,

I have seen that Bluetooth Classic is not yet supported by the ESP32 SDK, only BLE.

Are there any plans to add BT classic support in the near future? It this an SDK limitation or a hardware limitation?

Thanks for your help
Matt

[ESP_Sprite]

Yes, we have plans to that effect. I can't give you a timeline for that, unfortunately, though.

[madscientist_42]

Kind of...odd...to not have the support. Is this because of considerations on the HCI side of the equation not being fully fleshed out or is it because you've just not got a good API wrapper for the same?

[ESP_Sprite]

Mostly because it's not ported to main esp-idf yet. We do have some HCI work fleshed out, as well as audio profile already working. I asked around, work to get all that into esp-idf will be starting this week. (It's most likely going to be post-esp-idf-v2.0 before it will make it in, though.)

[madscientist_42]

Hi,

I have seen that Bluetooth Classic is not yet supported by the ESP32 SDK, only BLE.

Are there any plans to add BT classic support in the near future? It this an SDK limitation or a hardware limitation?

Thanks for your help
Matt

It's definitely not hardware. They're using a Riviera Waves/CEVA IP core for at least the controller if not the modem side, per their and CEVA's press releases. That's full function to 4.1/4.2 as a dual mode device. The problem, apparently, is that they're implementing the full embedded profile design which means it kind-of skips the HCI being propagated through a channel and you don't have a raw HCI edge, only an API. Definitely annoying since they claim full support on the chip. That equates to all the hooks to drive that hardware fully, which is very definitely NOT the case.

[madscientist_42]

Mostly because it's not ported to main esp-idf yet. We do have some HCI work fleshed out, as well as audio profile already working. I asked around, work to get all that into esp-idf will be starting this week. (It's most likely going to be post-esp-idf-v2.0 before it will make it in, though.)

Is this a limitation to the IDF or can the Arduino core drive the hardware properly? I've an application that is going to be stalled on part of it's features if I don't have the ability to do both LE and Classic.

[ESP_Sprite]

Both. esp-idf doesn't do it yet, and for complicated features that partially need fixing up the lower level layers, Arduino is dependent on esp-idf.

[magicroomy]

Any updates on this topic ?
I saw that now there are some new examples for BT audio profile ... but no example for plain BT Classic ( especially SP)

[Hubberthus]

If you are interested in a particular profile, then as a workaround until the IDF doesn't support it yet, you can write it manually, the "esp_vhci*" can be used for this.

At least a bare minimum of profile stacks for testing purposes can be written, if you're just waiting for it to be available. And then change to the official code when it becomes available.

I've attached an example usage of "esp_vhci*" which just connects to the given hardcoded Bluetooth address (peer_addr), sends it a name, sets itself as a HID Keyboard (dev_class), and sends one L2CAP message.
Nothing else, I've just fiddled with it until kinda "worked". It gets into a restart loop until somehow the L2CAP is successfuly sent, then does nothing.

[ursfassler]

Thank you for the example.
I found 2 problems in it, unfortunately it does not prevent the cyclic rebooting. It does not reboot all the time when the callbacks are not registered.

The problems are:

• the hci_cmd_buf is too small. If I got it correctly, it should be HCIC_PREAMBLE_SIZE+HCI_COMMAND_SIZE which is 258.
• It takes some time to create the connection. You have to wait for (conn_handle != 0xffff) until calling l2cap_send_connection_request_control

Any hints or solutions wrt. the crash are appreciated.