BLE Implementation

[MrSurly]

It's not perfect, but it's working pretty well for me.

API docs are here: https://github.com/MrSurly/micropython-esp32/blob/dev-bluetooth/esp32/bluetooth_docs.md

Merge Checklist:

Should do:

• Properties should be methods

Maybe:

• Move network.Bluetooth to top-level module bluetooth
• Implement the bluepy API as closely as possible
  -- or --
• service.start() and service.stop() become service.listen() and service.unlisten()(?)
• Implement select interface for services (or should this be at the characteristic / descriptor level)

---

• Implement all functionality as separate objects (e.g. GATTC object GATTS object), while passing in controller ID.

[MrSurly]

@dpgeorge @tannewt

I've updated the first comment for this PR with a checklist, which presently is just a mashup of suggestions here. I'm not heavily invested in the present API; I like it, but the API should match what exists in other µPy modules. I would, however, only like to change it once, so let's hammer this out.

I'll take on the work of making the API whatever is decided upon, but the API shouldn't make some use-cases too onerous to implement.

I do feel that removing callbacks makes the device less-friendly for multitasking. My own use case involves the "main" task doing sensor reads or other non BLE stuff, and relies heavily on the BT callbacks.

What about using queue objects instead of callbacks?

[tannewt]

@chrismas9 I draw the line where I think functionality is commonly grouped amongst microcontrollers. The intent is to make it easier to understand the functionality available on a particular port. I would split Ethernet and Wifi myself since boards may offer one or the other. However, if there are higher level TCP classes for example, I'd separate out the shared functionality too.

I think its fine to have many, smaller modules. It makes it clearer what functionality code uses and reduces memory usage when the modules actually need to be loaded in. (machine not included because its built in.)

bitbangio is separate from busio to make it clear what implementation is used for ports where both are available. Its a different way to handle the same thing that MicroPython's peripheral index does.

[MrSurly]

I think its fine to have many, smaller modules. It makes it clearer what functionality code uses and reduces memory usage when the modules actually need to be loaded in. (machine not included because its built in.)

Right now, WiFi is started when you import network, since that's what it does at startup. Since Bluetooth is in network, it can be a possibly unwanted side-effect, even if it's just increased power consumption.

[Atzingen]

Is the bluetooth implemented in the oficial firmware (esp32-20170716-v1.9.1-219-g3580284e.bin) for me to try it ?

[MrSurly]

No, just a PR right now, but you can check out the branch the PR is based on.

…

On Jul 16, 2017 11:26, "Gustavo Voltani von Atzingen" < ***@***.***> wrote: Is the bluetooth implemented in the oficial firmware (esp32-20170716-v1.9.1-219-g3580284e.bin) for me to try it ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#86 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAYHCIJmUMI6Xh89tbgg6LnZlSPmLf0Gks5sOlXqgaJpZM4NZmY1> .

[rdagger]

@MrSurly any ETA when your bluetooth PR will be merged?

[MrSurly]

@rdagger

I'm not sure if the plan is to:

1. Make API changes, 2) merge

• or -

1. Merge 2) Make API changes.

I was waiting for comments from @dpgeorge & others per the planned changes in the top comment.

[ruudk]

Since this PR is a bit out of sync with this repository, it took me a long time to get it working. For anybody that wants to try it out, this is how I got it working on a fresh machine:

python --version
# Python 2.7.13

# xtensa
sudo easy_install pip
sudo pip install pyserial
mkdir -p ~/esp
cd ~/esp

# Make sure you grab the older Xtensa:
wget https://dl.espressif.com/dl/xtensa-esp32-elf-osx-1.22.0-61-gab8375a-5.2.0.tar.gz
tar -xzf xtensa-esp32-elf-osx-1.22.0-61-gab8375a-5.2.0.tar.gz

# ESP-IDF
cd ~/esp
git clone https://github.com/espressif/esp-idf.git
cd ~/esp/esp-idf
git checkout 4ec2abbf23084ac060679e4136fa222a2d0ab0e8
# SHA comes from from https://github.com/MrSurly/micropython-esp32/blob/dev-bluetooth/esp32/Makefile#L38
git submodule update --init --recursive

# Add to profile
export ESPIDF=/Users/Ruud/esp/esp-idf
export IDF_PATH=~/esp/esp-idf
export PATH=$PATH:$HOME/esp/xtensa-esp32-elf/bin

# ESP32 with Bluetooth
git clone https://github.com/MrSurly/micropython-esp32.git ~/micropython-esp32-bluetooth
cd ~/micropython-esp32-bluetooth
git checkout dev-bluetooth

git submodule init lib/berkeley-db-1.xx
git submodule update

make -C mpy-cross

cd esp32
make

export PORT=/dev/tty.SLAB_USBtoUART
make erase
make deploy
picocom -b 115200 /dev/tty.SLAB_USBtoUART

[v923z]

@MrSurly Do you think you could upload the current version of the firmware to somewhere? I would be interested in testing the bluetooth implementation, but haven't the time to set up the development environment. Thanks.

[MrSurly]

@v923z

I put a release here, buuuut ... this is very alpha.

https://github.com/MrSurly/micropython-esp32/releases/tag/dev-bluetooth-A1

[v923z]

@MrSurly
Many thanks!

[diogoviannaaraujo]

Since this looks the most attractive high level BLE API I've found I think I'll be implementing a complex(for me) prototype using this, my first dig in micropython and been 7 years i've touched a python code, hope I can provide useful feedback.

I too think bluetooth deserves to live outside the network module, and use network maybe for tcp over bluetooth. Maybe someday I get confident enough to try some PRs

Beautiful work btw 👍

[MrSurly]

The IDF implementation has changed considerably. Closing this, will submit a new PR when new code is ready.