Espressif BLE fixes: advertising duration, _bleio.adapter.connected

[dhalbert]

I think this may fix #10007.

Advertising duration

The advertising duration value for "forever" is different for ble_gap_adv_start() and ble_gap_ext_adv_start(). It is BLE_HS_FOREVER and 0, respectively. The code was using BLE_HS_FOREVER In 6.0.1, this value is actually checked, and gives a parameter range error.

connected state check

Code was added in #9289 that required that the MTU value be non-zero when returning true for _bleio.adapter.connected.

circuitpython/ports/espressif/common-hal/_bleio/Adapter.c

Line 666 in 7a27366

if (connection->conn_handle != BLEIO_HANDLE_INVALID) {

circuitpython/ports/espressif/common-hal/_bleio/Adapter.c

Line 742 in d6fd51f

if (connection->conn_handle != BLEIO_HANDLE_INVALID && connection->mtu != 0) {

The MTU is zero when a connection has first been made but the MTU is not yet negotiated.

The MTU check above causes a brief interval, for both ble.connected() and ble.advertising() to be False. The transition between advertising and connected did not appear atomic. This compares with the nordic implementation where this glitch is not present.

I removed this MTU check and connections still work. I was testing with an HID keyboard example (derived from https://learn.adafruit.com/ble-hid-keyboard-buttons-with-circuitpython) which requires pairing. It is necessary to forget the CircuitPython device on the central side if its firmware is reloaded, at least for an iOS central.

@tannewt Do you remember why you added the MTU check in #9289? It's true that the connection is not complete until the MTU is negotiated. But we have a lot of example code something like this:

ble.start_advertising(advertisement)

while True:
    if not ble.connected and not ble.advertising:
        print("BLE disconnected, restarting advertising...")
        ble.start_advertising(advertisement)
    ...

So what happens is that when the central has connected initially but the MTU is not yet negotiated, the if statement is briefly False, which makes the program think erroneously that there was a disconnect, and it starts advertising again. On Espressif, this quickly causes "Nimble: out of memory".

If there was a ble.connection_initiated ble.connection_in_progress that could be used instead. But otherwise there's no state available to know that. And we'd have to change a lot of code.

[tannewt]

I think we can consider it connected when we are negotiating MTU. It's been a while since I did BLE but I think our MTU negotiation is just to get the most bytes over the air at the time. It is optional and not required.