search

espressif / arduino-esp32

Arduino core for the ESP32
GNU Lesser General Public License v2.1
13.58k stars 7.4k forks source link

RFC: BLE support #423

Closed igrr closed 4 years ago

igrr commented 7 years ago

This ticket is opened to discuss possible approaches to implementing BLE wrappers, desired API and implementation choices.

Note: please don't use this issue to express your desire/need to have BLE support in the form of "+1" comments, questions on schedule and such. Instead, please use "Subscribe" button on the right to receive email updates on the discussion.

Prior art

Support for ESP32 BLE in other frameworks

Resources

Action list

Everyone is welcome to offer suggestions and comments about API design. Contributing actual code is also a great way to move this issue forward; however please post the proposed API for comment before starting implementation.

igrr commented 7 years ago

Having taken a look at the existing libraries and their example code, i like the way sandeepmistry/arduino-BLEPeripheral is designed. The chip-specific part is separated reasonably well to attempt shoehorning ESP32 support into that library. The way adding services and characteristics works in this library will probably play nice with GATT table APIs in the ESP-IDF. Would be nice if someone else would have a brief look at the code and examples to see if there are any things which will make porting problematic.

WALLTECH commented 7 years ago

FWIW, having worked with the Curie BLE libraries they are a pleasure to use and I vote for that. Obvious preference to under the hood ease of conversion and time of course. My needs are in a central role too. Compatibility would also be good in the Arduino community.

me-no-dev commented 7 years ago

Probably the only major missing piece for me (in IDF) is the ability to properly pair with a device and hold that key, so the same device can reconnect again without peering. The rest I somewhat understand and have working. Have not tried to be gatt client and server at the same time also. I wonder if that is possible or we need to figure out a safeguard to prevent it. Properly connecting an item in the gatt server table to id so you can alter that item is also not so clear. Using human logic I can get to it, but that could not work in code ;)

zencuke commented 7 years ago

Thank you. "Other frameworks:" I've been prototyping my central mode app in Xcode/OSX mostly because I know Xcode environment for command line apps and Apple's Core BLE library is well documented. There are lots of example projects. That works as a self education process but a proprietary closed library example is obviously less helpful for this project. I mention it for completeness. It is a working ble library.

kriswiner commented 7 years ago

We're using Nordic's SDK (not well) to enable both central and peripheral roles for custom nRF52 devices. I think BLEPeripheral cannot accomodate central role specification at the moment. I would just say that this is a serious deficiency and I would encourage the BLE API developers to take the need for both central and peripheral roles into account in the design of the ESP32 BLE API.

I do like the syntax BLEPeripheral has chosen to specify services and characteristics and this would be a good choice for the ESP32 to emulate. I have found this much easier to use than mbed BLE.

skateone commented 7 years ago

i am also trying to get the esp32 to communicate with a Nordic nRF52 device. in my case we try setup the esp32 with a GATTs server hosting services and characteristics and try use the Nordic to discover the ESP32. for some reason we can only see the device from the ESP32 and non of the services.

S3ler commented 7 years ago

I started thinking of a Bluetooth Central API Implementation for the nRF5 Chips. It is a good Idea to use overall the same API so i participate here. I agree with sandeepmistry to use the CurieBLE API. It provides both API for Central, Peripheral and is already used in an Arduino project.

copercini commented 7 years ago

I really love @nkolban C++ implementation: https://www.youtube.com/watch?v=WGozJXuQ8dY&feature=youtu.be https://github.com/nkolban/esp32-snippets/tree/master/cpp_utils

It's clean and already works with ESP32, so just need a minimal effort to make an Arduino port

ouki-wang commented 7 years ago

Do you decide which api to use? I vote for curieBLE.

jcmojj commented 7 years ago

Do vou know if de can check signal strenght with it? It is all I Will Need..

On Monday, July 17, 2017, ouki <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

Do you decide which api to use? I vote for curieBLE.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/423#issuecomment-315710433, or mute the thread https://github.com/notifications/unsubscribe-auth/AV5_E_UAQ0bYZIBnlSsID6h2GYGFbR19ks5sOy0cgaJpZM4NyKlw .

ayavilevich commented 7 years ago

Sandeep's library is very easy to work with and a nicely designed API, but as mentioned above it doesn't support Central roles or running Central at the same time as running Peripheral. I would like to see a library that is as easy to understand as Sandeep's but can support Central with many Peripherals and Central and Peripheral roles at the same time.

Naturally, it makes sense to get an initial version out quickly, even if it is only Peripheral. Thanks.

d3cline commented 7 years ago

CurieBLE is my personal vote as far as an API to emulate, Intel has been pushing the Arduino 101 and the curie chip a lot recently, giving away a bunch on hackster (i got one) The API is nice once you understand it. Having the same basic code between platforms would be nice.

WALLTECH commented 7 years ago

I agree, and it's ok to update the library as features become available rather than holding off until it's done. Different people need different features and as they come out people should be able to use them.

gesaleh commented 7 years ago

I agree for the Sandeep's library easy to use, even if i had some issue with RB blend 2, if there is any progress I would like to test it. for now I need only the Peripheral (sending sensors from ESP to Pi) that would be a great start

tijnkooijmans commented 7 years ago

I also like the CurieBLE API.

scramble45 commented 7 years ago

CurieBLE API +1

copercini commented 7 years ago

So, Intel has announced the end-of-life timeline for the Intel Curie module, and will discontinue manufacturing Arduino 101: https://communities.intel.com/thread/116434

WALLTECH commented 7 years ago

@copercini this doesn't change the simplicity and suitability of the CurieBLE library. The hardware cost and misjudging the market for hardware needs was what's closing it down. They will leave their github up too to use.

MarosValter commented 7 years ago

I vote for CurieBLE

nkolban commented 7 years ago

Howdy folks, I have been tinkering with a BLE API in C++ on the ESP32 that exposes an API that I came up with ... see:

https://esp32.com/viewtopic.php?f=13&t=2330

Is anyone actively working on a different/alternate encapsulation of ESP32 BLE support?

I see discussion of desire for a BLE API that matches that provided as described here:

https://www.arduino.cc/en/Reference/CurieBLE

Is there a designated sub-project leader for the technical discussion described in this Github issue? What would be a shame is if we all went in separate directions and perform individual work as opposed to a collaborative effort. I'll be delighted to pitch in in some way. It may be as simple as taking my existing library of BLE C++ functions are re-exposing the interfaces to match those of CurieBLE or maybe there is a design proposal that starts from scratch?

d3cline commented 7 years ago

I am waiting to see what the official decision is by espreiff and igrr. I wish I could provide more feedback from the hardware end. I need a little boiler plate to run with and I am willing to help debug and provide more feedback. I am anxious to start coding with Kotlin, BLE, and ESP32. The arduino code I already have which was for Arduino-101 and what will be similar in future projects just needs to send a JSON string. Basically waiting to see what will happen before I see what/if any assistance I can lend beyond debugging.

wekhrozomedo commented 7 years ago

CurieBLE API

gmag11 commented 7 years ago

I'm following tutorials from @nkolban and trying to replicate same code on Arduino. The problem is that included precompiled IDF is behind main esp32-idf repository development, and many of the functions there are not implemented here.

Anyway I find his implementation simple enough (on the interface) and close to esp32 capabilities.

I'd vote to see his work integrated on arduino-esp32.

jcmojj commented 7 years ago

So far I see that CurieBle was the most voted. I vote against it because for me it is very important to read signal strength (rssi) and CurieBle as far as I read is unable to do it. The kolban could do it.

On Sunday, July 30, 2017, Germán Martín notifications@github.com wrote:

I'm following tutorials from @nkolban https://github.com/nkolban and trying to replicate same code on Arduino. The problem is that included precompiled IDF is behind main esp32-idf repository, and many of the functions there are not implemented here.

Anyway I find his implementation simple enough (on the interface) and close to esp32 capabilities.

I'd vote to see his work integrated on arduino-esp32.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/423#issuecomment-318893125, or mute the thread https://github.com/notifications/unsubscribe-auth/AV5_ExsTmFIUB5ilk28-5Tp5D1WMl0xQks5sTF1ygaJpZM4NyKlw .

dineshjoshi commented 7 years ago

I like CurieBLE as well.

WALLTECH commented 7 years ago

@jcmojj Of course CurieBLE can do signal strength. Use .rssi() on a BLEDevice object to get it.

int BLEDevice::rssi() const { return BLEDeviceManager::instance()->rssi(this); }

d3cline commented 7 years ago

Do we have any ETA? The market doesn't wait. Reengineering low level APIs isn't my focus, but picking what is ready and building products is. I thought the ESP32 was more developed and supported, BLE has been discussed for about a year now, there is a 'simple example' which shouldn't even exist since it's incomplete and misleading. How much longer are we going to have to wait for even an alpha/beta or some kind of decision? What is the current decision by the upstream providers? Are they waiting for the community to write something? The intel curie chip still can be bought without an arduino, I can still run that code in my products. I could hook up a cheap BLE module to the box of NodeMCUs I already own. I could use the ESPIDF if i wanted to port my code to a low level, proprietary format, and spend hours learning how BLE works at a hardware level, but I won't do that as I am only 1 person and have so much effort to place elsewhere. Arduino matters because rapid development matters, BLE is the 1 feature we need from ESP32 that we can't get from the 8266, why is it not a major priority and done already?

zencuke commented 7 years ago

@d3cline. I feel your pain but your post was a bit undirected. You may have posted it in the wrong place. Do you understand the purpose of this particular forum and who is likely to read it? Maybe you could clarify your post. Exactly who is it that you think has the wrong priorities? And who do you think should be answering your questions and addressing the issues you raise? Who do you think should have already solved them?

clowrey commented 7 years ago

@d3cline Curie module is EOL (end of life) according to an email I got from Digikey a few days ago. So not recommended for new designs.

d3cline commented 7 years ago

Espressif is the upstream provider, and they have paid developers, one of them started the thread, they have dumped a ton of time into the IDF. They are in the best position to make this move forward. It is in their interest to as well since many of us are waiting to put the ESP32 in use, but if I have to decide on another MCU since it will take another few months I will. BLE is all that matters to an end user, "can I make this wireless with my mobile". There are 8000+ Curies on digikey right now, aliexpress has BLE modules with arduino code for $3USD. I am only stating the facts, it's a hard market if you are interested in more then hobbyist stuff, but don't have unlimited funds or a large research team. That is what made the 8266 a hit, and it could make or break the ESP32.

d3cline commented 7 years ago

Or let me put it this way, I would order a few hundred right now from aliexpress if I knew this was working and I could check it off my logistics checklist for my next project. Since it may be 'whenever', the thread is 2 months old, and BLE demand in general is almost a year old, I am looking into alternatives. The IDF is swell, i am impressed with its speed and the fact it exists, but it isn't what I need as a developer who needs to focus on other parts of the stack and has a limited amount of time. 100% Arduino compatibility is what allows rapid development with all the sensors and modules which already exist. It should be a priority for the upstream provider as opposed to making their own monolithic rival to arduino.

WALLTECH commented 7 years ago

@clowrey "this doesn't change the simplicity and suitability of the CurieBLE library. The hardware cost and misjudging the market for hardware needs was what's closing it down. They will leave their github up too to use." - from posts above

kriswiner commented 7 years ago

For product development today there is always the nRF52, which has a passable Arduino core and BLEPeripheral support. Not ideal, but it is more useable for products requiring BLE connectivity than the ESP32 is today. I hope that changes. But for now, this https://www.tindie.com/products/onehorse/nrf52832-development-board/?pt=full_prod_search is what I am using for my product development.

On Sat, Aug 5, 2017 at 9:28 AM, John Wall notifications@github.com wrote:

@clowrey https://github.com/clowrey "this doesn't change the simplicity and suitability of the CurieBLE library. The hardware cost and misjudging the market for hardware needs was what's closing it down. They will leave their github up too to use." - from posts above

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/423#issuecomment-320453119, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qqCDupuC0ivZPdlX6eLQ81fezgU7ks5sVJg_gaJpZM4NyKlw .

nkolban commented 7 years ago

I was reading the posts and something spooked me. I try and maintain a C++ ESP-IDF library for BLE which seems to work well enough. However, I have built my library against ESP-IDF release v2.1. I think I saw someone post that the Arduino level of ESP-IDF is back-level. Does anyone know of any project plans to bring ESP32 Arduino support to a level that supports the ESP-IDF 2.1?

WALLTECH commented 7 years ago

@kriswiner Very true, BLE peripheral is easy and can be done with a myriad of devices. BLE central however is what I'm after, and that is few and far between and what I like about CurieBLE and am hoping for from the ESP32.

kriswiner commented 7 years ago

Agreed. I need BLE central role devices as well. Currently, we use the Nordic SDK to load a UART bridge solution in central role onto an nRF52. It works great and makes for a convenient laptop dongle to pair with a nRF52 peripheral running the same Nordic UART service. But we haven't figured out how to make it pair with more than one peripheral at a time by MAC address, which is really what we want. BLEPeripheral currently does not support any kind of central role.

I would expect that any easy-to-use, Arduino-compatible BLE API that does support central role with multiple peripherals will become the standard implementation. Could this be Curie BLE? I don't know...

On Sat, Aug 5, 2017 at 1:58 PM, John Wall notifications@github.com wrote:

@kriswiner https://github.com/kriswiner Very true, BLE peripheral is easy and can be done with a myriad of devices. BLE central however is what I'm after, and that is few and far between and what I like about CurieBLE and am hoping for from the ESP32.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/espressif/arduino-esp32/issues/423#issuecomment-320470075, or mute the thread https://github.com/notifications/unsubscribe-auth/AGY1qtjkODg2XEuc_OGPYJsGHa4udcRqks5sVNdzgaJpZM4NyKlw .

copercini commented 7 years ago

@nkolban I got your C++ lib working on Arduino today (with all the examples of your repo), the compile time is slow on arduino IDE, so probably will need to be precompiled like others parts of core. Maybe @igrr or @me-no-dev can help with this

Now, It's just re-expose the API to match with Curie.

I don't know if is a good thing release it now as kolbanBLE or cppBLE and then when it match 100% with Curie make another release or develop until it match with curie and just release the curie version

vshymanskyy commented 7 years ago

I have also started integrating BLE for ESP32 into the Blynk App, but it would be much easier and better to rely on high-level API. CurieBLE or BLE Peripheral variant would work best for us. Blynk community would love to create smartphone apps for this chip - we get so many requests for ESP32 support! Some inspiration: img

nkolban commented 7 years ago

@copercini That is awesone news. Email me at kolban1@kolban.com or ping on IRC in channel #ESP32 and let me know how we can collaborate (if desired).

If we (as a community) decide to go down the paths that you are working, then we have three possibilities:

  1. We expose the APIs that are currently found in the cpp_utils C++ BLE library.
  2. We expose the CurrieAPI building on the API currently found in the cpp_utils C++ BLE library.
  3. We rework the expose API currently found in the cpp_utils C++ BLE library to natively expose the CurrieAPI.

The 4th possibility (of course) is that work is done on a complete implementation of an API (likely the CurrieAPI) starting from nothing but the raw ESP-IDF.

My personal preference would be option (1). The thinking behind this is that it would take the least amount of effort to get it working ... and it sounds like you already have. What we need to do next is figure out if any changes were required and then retrofit them into the common code base, likely separate it out into a "ESP32 BLE C++" project (away from the generic cpp_utils in which it lives today). Ideally, we would want a library that can be used by both ESP32 programmers and Arduino programmers ... separate libraries doesn't see to satisfy any needs.

Once we have (1) ... then Arduino ESP32 programmers can start writing ESP32 BLE apps. From there, we can test function and make sure all is working. As experience grows, we can then achieve (2) (if needed) pretty quickly with just wrapping. My belief is that will be performant sufficient. However, if not performant OR the CurrieAPI doesn't map cleanly, then we can move into a gradual realm of (3).

Again ... I say all of this to try and push the ball forward. Ideally we nominate a sub-project leader/architect. The ideal would be the owner of Arduino on ESP32 or, failing that, a representative from Espressif. However ... failing either of them, it could be one of us who want to see BLE on the Arduino API on ESP32.

I'll nominate myself if no-one else volunteers but if anyone else wants the job, please speak up. We'll then arrange a quick team chat and see how far (if at all) thinking on design diverges and take it from there. However, the ideal situation is that either the ESP32 architect @igrr or the ESP32 Arduino architect @me-no-dev takes the reigns. From there they can either dictate what they want to see happen or delegate down to one of us in this issue/community.

me-no-dev commented 7 years ago

I personally prefer to only take other API as a general guide and have something implemented that makes more sense with the lower IDF API. All layers of classes and abstractions need to be properly written so it is easy to implement all higher level functions and not break one another. My first thought is what will users do and break. Not so important is which API to adhere to, because much more users will jump on the ESP32 than any other such platform.

copercini commented 7 years ago

Let’s show some code: in attachment is the functional cpp_utils C++ port as Arduino library (it’s still missing some examples, but the intent is more discussion of APIs) BLE.zip

My thoughts about it:

Compatibility between IDF and Arduino:

Compatibility between c++BLE and CurieBLE:

Issues:

copercini commented 7 years ago

@me-no-dev

I personally prefer to only take other API as a general guide

It's CurieBLE

and have something implemented that makes more sense with the lower IDF API.

It's cpp_utils from @nkolban

Not so important is which API to adhere to, because much more users will jump on the ESP32 than any other such platform.

cpp_utils and CurieBLE are almost close (some code are in the .zip above), personally I vote to change a bit of cpp_utils APIs to match with CurieBLE (which already has documentation and examples ready) and keep the compatibility between IDF and Arduino to use the same library in both

d3cline commented 7 years ago

TYVM @copercini I am testing the library now. I had to do a git pull to the latest hardware/arduino-esp32 if anyone else runs into compile errors and this did not occur to them.

d3cline commented 7 years ago

I have tested the 4 examples and BLE_scan seems to function without error. The others compile but I get a crash in the serial monitor different for each. I could post the errors and work through them on a better thread when/if one is created. (I got BLE_server to work by adding some print code above the delay in the loop)

d3cline commented 7 years ago

As for feedback. I am impressed by the simplicity already, great work. Much better than 500+ lines, and it does compile on Arduino 1.8.0 on Ubuntu. Going to try to get it to read some I2C and send it. This all looks very promising. (I am able to read i2c sensor data and dynamically update the Characteristic from a rather complex sensor and send it over BLE to my kotlin code with a little tweaking to variable location in the BLE_server example)

nkolban commented 7 years ago

I had some good chats with Mr @copercini and understand what he did to enable BLE within the Arduino environment. I was able to recreate and it looks great. At the highest level he has determined the recipe for building the cpp_utils BLE library for the ESP32 Arduino environment.

The next stage was to build a "Makefile" that will be part of the cpp_utils that can build an Arduino BLE.zip library file from the ccp_utils source that is ready for distribution as an Arduino BLE library. This has been done and is now being better tested. When this is complete, it will allow maintainers of the eventual Arduino BLE library to repeatedly build the ZIP without manual or mistaken tasks.

One of the design goals is to ensure that the BLE library is as close to the same code for ESP-IDF as for Arduino and so far we have zero discrepancies between the two allowing us to have an identical code base without any conditional compilation logic. However, the one snag (and its a small one) is that the BLE library on ESP-IDF allows one to debug the internals using the ESP32 ESP_LOGx() macros. These macros are disabled in the Arduino environment. They could be quite easily enabled. Issue #565 asks for permission to change the code base of the Arduino environment ( a few lines) to enable ESP_LOGx() macros in the Arduino environment. At that point we could have what would appear to be 100% code affinity between BLE for ESP-IDF and BLE for Arduino.

nkolban commented 7 years ago

Work continues on the BLE library polish for Arduino. A simple BLE scan worked without incident. No issue. Next I tried to create a BLE Server but that's where things started to get sticky. The current problem is logged as issue #568 which results in a rebooting exception. My guess work is loosely the following:

In ESP-IDF programming, we have a utility called "make menuconfig" which allows us to change the characteristics of the environment in which an ESP-IDF application will run. When we run "make menuconfig", the result is a configuration file that eventually becomes "sdkconfig.h". If we look at the ESP32 Arduino environment, we don't have "make menuconfig" instead we have a pre-supplied "sdkconfig.h". See:

https://github.com/espressif/arduino-esp32/tree/master/tools/sdk/include/config

and this is where things slow down and become painstaking. What I believe I need to do is compare, line by line, the settings "present" in the pre-supplied "sdkconfig.h" with the settings I understand I want/need for BLE to work in ESP-IDF using "make menuconfig". Without the menu driven "make menuconfig" it isn't "easy" to see what is set, what is not set, what are defaults and what are customized. My gut is saying that there is something in the Arduino environment that is distinct from the the default/customized ESP-IDF environment. As a loose example, I have found that when working in ESP-IDF, the default BLE task stack size is not large enough and I usually have to bump it up from the default 2K to about 8K. The default in the Arduino sdkconfig remains at 2K (and yes, I tried that but that hasn't resolved the core issue). Unfortunately, it looks like I have to grunge through the lines one by one looking for the distinctions ... this may be a good opportunity for a tool or script.

MrSurly commented 7 years ago

@nkolban

I went through the same thing w/ BLE for MicroPython. You can see the changes necessary in https://github.com/MrSurly/micropython-esp32/tree/dev-bluetooth, by comparing esp32/sdkconfig.h to the version found in the esp32 branch. The BT differences are summed up in a handy #if about halfway down.

I seem to remember two big ones: CONFIG_BT_RESERVE_DRAM, and the fact that the available heap went from about 100K to about 48K. Not sure the latter will affect Arduino much. In MicroPython, most of the available heap is taken for use as the Python heap.

diff --git a/esp32/sdkconfig.h b/esp32/sdkconfig.h
index de8630e..81587e0 100644
--- a/esp32/sdkconfig.h
+++ b/esp32/sdkconfig.h
@@ -1,9 +1,9 @@
 #define CONFIG_TRACEMEM_RESERVE_DRAM 0x0
-#define CONFIG_BT_RESERVE_DRAM 0x0
 #define CONFIG_ULP_COPROC_RESERVE_MEM 0
 #define CONFIG_PHY_DATA_OFFSET 0xf000
 #define CONFIG_APP_OFFSET 0x10000

+
 #define CONFIG_SPI_FLASH_ROM_DRIVER_PATCH 1
 #define CONFIG_FOUR_UNIVERSAL_MAC_ADDRESS 1
 #define CONFIG_NUMBER_OF_UNIVERSAL_MAC_ADDRESS 4
@@ -51,7 +51,6 @@
 #define CONFIG_FREERTOS_ASSERT_ON_UNTESTED_FUNCTION 1
 #define CONFIG_FREERTOS_CHECK_STACKOVERFLOW_NONE 1
 #define CONFIG_FREERTOS_THREAD_LOCAL_STORAGE_POINTERS 2
-#define CONFIG_FREERTOS_IDLE_TASK_STACKSIZE 1024
 #define CONFIG_FREERTOS_ISR_STACKSIZE 1536
 #define CONFIG_FREERTOS_BREAK_ON_SCHEDULER_START_JTAG 1
 #define CONFIG_FREERTOS_MAX_TASK_NAME_LEN 16
@@ -59,7 +58,6 @@
 #define CONFIG_ENABLE_STATIC_TASK_CLEAN_UP_HOOK 1

 #define CONFIG_MAIN_TASK_STACK_SIZE 4096
-#define CONFIG_IPC_TASK_STACK_SIZE 1024
 #define CONFIG_BTC_TASK_STACK_SIZE 3072
 #define CONFIG_SYSTEM_EVENT_TASK_STACK_SIZE 4096
 #define CONFIG_SYSTEM_EVENT_QUEUE_SIZE 32
@@ -70,9 +68,24 @@
 #define CONFIG_NEWLIB_STDOUT_ADDCR 1
 #define CONFIG_PHY_ENABLED 1
 #define CONFIG_WIFI_ENABLED 1
+#define CONFIG_SMP_ENABLE 1
 #define CONFIG_OPTIMIZATION_LEVEL_DEBUG 1
 #define CONFIG_MEMMAP_SMP 1

+#if (MICROPY_ESP32_BLUETOOTH)
+#   define CONFIG_BT_ENABLED 1
+#   define CONFIG_BLUEDROID_ENABLED 1
+#   define CONFIG_GATTS_ENABLE 1
+#   define CONFIG_BT_DRAM_RELEASE 1
+#   define CONFIG_GATTC_ENABLE 1
+#   define CONFIG_BT_RESERVE_DRAM 0x10000
+#   define CONFIG_BTDM_CONTROLLER_RUN_CPU 0
+#   define CONFIG_BT_ACL_CONNECTIONS 4
+#   define CONFIG_BLE_SMP_ENABLE 1
+#else
+#   define CONFIG_BT_RESERVE_DRAM 0
+#endif
+
 #define CONFIG_PARTITION_TABLE_SINGLE_APP 1
 #define CONFIG_PARTITION_TABLE_FILENAME "partitions_singleapp.csv"
 #define CONFIG_PARTITION_TABLE_CUSTOM_APP_BIN_OFFSET 0x10000
@@ -110,3 +123,6 @@

 #define CONFIG_TOOLPREFIX "xtensa-esp32-elf-"
 #define CONFIG_PYTHON "python2"
+
+
+
nkolban commented 7 years ago

Update: First a question ... given the chatter on this issue, do we want to create a forum thread for our discussions on BLE support for ESP32 Arduino or do we wish to continue using this Git issue? My vote would be a thread but we'll let majority decide. Here is an online poll we can use:

http://www.easypolls.net/poll.html?p=598a9015e4b05211e16ff0e6

Now for the update. At the end of yesterday we found that we were running into problems building and running BLE servers. After experimentation, it was found that this was caused as a result of an experiment that switched on ESP_LOGx debugging. This is the diagnostics technology that we leave on during development to visualize what is going on inside the BLE libraries. Normally, users wouldn't need to run with that on. It turns out that our hope that we had a recipe to enable ESP_LOGx within Arduino weren't as fruitful as we'd believed. When we switched off the ESP_LOGx debugging (which is the default), the crashes went away and all appears to function. So ... hooray.

Mr @copercini made some fantastic changes to the project to make specification of service and characteristic UUIDs much easier. These are now merged with master.

As changes will likely be coming thick and fast for a while and we are still months away from anything we might term a "release", we wanted to make sure that anyone who wished, could get a "build" from the latest code anytime they wanted. As such, we now have a written recipe for building such that should hopefully be pretty straight forward. It has been written up here:

https://github.com/nkolban/esp32-snippets/blob/master/cpp_utils/ArduinoBLE.md

If you decide to play with the builds of the BLE library, it will be assumed that you are using the latest build created from these instructions. This will give us "one source of truth" on what code is in effect at any given time.

me-no-dev commented 7 years ago

I prefer you stick to using this github issue, or I will not be able to follow the development. As you @nkolban know, I am not big on forums, nor I have the time to go through them.