New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: BLE support #423

Open
igrr opened this Issue Jun 7, 2017 · 132 comments

Comments

Projects
None yet
@igrr
Member

igrr commented Jun 7, 2017

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

  • Decide which existing library to choose as a base for the API
  • Design of advertising API
  • Design of Peripheral/server API
  • Design of Central/client API
  • Implementation of advertising API
  • Implementation of Peripheral/server API
  • Implementation of Central/client API

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

This comment has been minimized.

Show comment
Hide comment
@igrr

igrr Jun 7, 2017

Member

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.

Member

igrr commented Jun 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@WALLTECH

WALLTECH Jun 7, 2017

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.

WALLTECH commented Jun 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@me-no-dev

me-no-dev Jun 7, 2017

Member

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 ;)

Member

me-no-dev commented Jun 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@zencuke

zencuke Jun 7, 2017

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.

zencuke commented Jun 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@kriswiner

kriswiner Jun 10, 2017

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.

kriswiner commented Jun 10, 2017

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

This comment has been minimized.

Show comment
Hide comment
@skateone

skateone Jun 10, 2017

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.

skateone commented Jun 10, 2017

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

This comment has been minimized.

Show comment
Hide comment
@S3ler

S3ler Jun 19, 2017

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.

S3ler commented Jun 19, 2017

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

This comment has been minimized.

Show comment
Hide comment
@copercini

copercini Jul 16, 2017

Collaborator

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

Collaborator

copercini commented Jul 16, 2017

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

This comment has been minimized.

Show comment
Hide comment
@ouki-wang

ouki-wang Jul 17, 2017

Contributor

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

Contributor

ouki-wang commented Jul 17, 2017

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

@jcmojj

This comment has been minimized.

Show comment
Hide comment
@jcmojj

jcmojj Jul 17, 2017

jcmojj commented Jul 17, 2017

@ayavilevich

This comment has been minimized.

Show comment
Hide comment
@ayavilevich

ayavilevich Jul 19, 2017

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.

ayavilevich commented Jul 19, 2017

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

This comment has been minimized.

Show comment
Hide comment
@d3cline

d3cline Jul 21, 2017

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.

d3cline commented Jul 21, 2017

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

This comment has been minimized.

Show comment
Hide comment
@WALLTECH

WALLTECH Jul 21, 2017

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.

WALLTECH commented Jul 21, 2017

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

This comment has been minimized.

Show comment
Hide comment
@gesaleh

gesaleh Jul 23, 2017

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

gesaleh commented Jul 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@tijnkooijmans

tijnkooijmans Jul 23, 2017

I also like the CurieBLE API.

tijnkooijmans commented Jul 23, 2017

I also like the CurieBLE API.

@scramble45

This comment has been minimized.

Show comment
Hide comment
@scramble45

scramble45 Jul 25, 2017

CurieBLE API +1

scramble45 commented Jul 25, 2017

CurieBLE API +1

@copercini

This comment has been minimized.

Show comment
Hide comment
@copercini

copercini Jul 25, 2017

Collaborator

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

Collaborator

copercini commented Jul 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@WALLTECH

WALLTECH Jul 25, 2017

@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.

WALLTECH commented Jul 25, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@MarosValter

MarosValter Jul 26, 2017

I vote for CurieBLE

MarosValter commented Jul 26, 2017

I vote for CurieBLE

@nkolban

This comment has been minimized.

Show comment
Hide comment
@nkolban

nkolban Jul 26, 2017

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?

nkolban commented Jul 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@d3cline

d3cline Jul 26, 2017

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.

d3cline commented Jul 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@Wekhrozomedo

Wekhrozomedo Jul 27, 2017

CurieBLE API

Wekhrozomedo commented Jul 27, 2017

CurieBLE API

@gmag11

This comment has been minimized.

Show comment
Hide comment
@gmag11

gmag11 Jul 30, 2017

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.

gmag11 commented Jul 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@jcmojj

jcmojj Jul 30, 2017

jcmojj commented Jul 30, 2017

@dineshjoshi

This comment has been minimized.

Show comment
Hide comment
@dineshjoshi

dineshjoshi Jul 31, 2017

I like CurieBLE as well.

dineshjoshi commented Jul 31, 2017

I like CurieBLE as well.

@WALLTECH

This comment has been minimized.

Show comment
Hide comment
@WALLTECH

WALLTECH Jul 31, 2017

@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);
}

WALLTECH commented Jul 31, 2017

@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);
}

@WALLTECH

This comment has been minimized.

Show comment
Hide comment
@WALLTECH

WALLTECH Sep 3, 2017

Attempted it and can't decide what's required and not and the client example is a bit too different for me from the others to translate it. I posted in the snippets repo about a client/central example.

WALLTECH commented Sep 3, 2017

Attempted it and can't decide what's required and not and the client example is a bit too different for me from the others to translate it. I posted in the snippets repo about a client/central example.

@DonWasabi

This comment has been minimized.

Show comment
Hide comment
@DonWasabi

DonWasabi Sep 11, 2017

Hi, are there some news of the status of the (official?) curie BLE arduino library?

DonWasabi commented Sep 11, 2017

Hi, are there some news of the status of the (official?) curie BLE arduino library?

@haosheng-huang

This comment has been minimized.

Show comment
Hide comment
@haosheng-huang

haosheng-huang Sep 19, 2017

Hi,I follow this project,but have a problem when esp32 power on,it always restart not to working,
what can I take it and next step ? thks..

this serial port info:

ets Jun 8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0010,len:4
load:0x3fff0014,len:708
load:0x40078000,len:0
load:0x40078000,len:11460
entry 0x400789f4

Brownout detector was triggered

ets Jun 8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0010,len:4
load:0x3fff0014,len:708
load:0x40078000,len:0
load:0x40078000,len:11460
entry 0x400789f4

Brownout detector was triggered

ets Jun 8 2016 00:22:57

haosheng-huang commented Sep 19, 2017

Hi,I follow this project,but have a problem when esp32 power on,it always restart not to working,
what can I take it and next step ? thks..

this serial port info:

ets Jun 8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0010,len:4
load:0x3fff0014,len:708
load:0x40078000,len:0
load:0x40078000,len:11460
entry 0x400789f4

Brownout detector was triggered

ets Jun 8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0010,len:4
load:0x3fff0014,len:708
load:0x40078000,len:0
load:0x40078000,len:11460
entry 0x400789f4

Brownout detector was triggered

ets Jun 8 2016 00:22:57

@me-no-dev

This comment has been minimized.

Show comment
Hide comment
@me-no-dev

me-no-dev Sep 19, 2017

Member

@haosheng-huang use good usb cable and stable power supply. The error means that the supplied voltage dropped too low. Could be a bad LDO, since you did not say what board exactly you are using.

Member

me-no-dev commented Sep 19, 2017

@haosheng-huang use good usb cable and stable power supply. The error means that the supplied voltage dropped too low. Could be a bad LDO, since you did not say what board exactly you are using.

@haosheng-huang

This comment has been minimized.

Show comment
Hide comment
@haosheng-huang

haosheng-huang Sep 19, 2017

@me-no-dev thks,But I already use power supply only. I use this board.

1e038497-7f1f-479e-ad52-0dbacba01c97

haosheng-huang commented Sep 19, 2017

@me-no-dev thks,But I already use power supply only. I use this board.

1e038497-7f1f-479e-ad52-0dbacba01c97

@Spritetm

This comment has been minimized.

Show comment
Hide comment
@Spritetm

Spritetm Sep 19, 2017

Member

@haosheng-huang Can I ask you to start a new issue (or post on the esp32.com forum) for this? It has nothing to do with the BLE/Arduino discussion in this issue.

Member

Spritetm commented Sep 19, 2017

@haosheng-huang Can I ask you to start a new issue (or post on the esp32.com forum) for this? It has nothing to do with the BLE/Arduino discussion in this issue.

@alexkirillov

This comment has been minimized.

Show comment
Hide comment
@alexkirillov

alexkirillov Sep 21, 2017

@MarosValter ,
Exactly the same "abort() was called at PC 0x400d880b on core 0" happens with my board.
After calling BLEServer *pServer = new BLEServer(); from sample.
If I would comment everything out and try enabling code line-by-line:
ble.init("MyESP32"); - works fine
call to new BLEServer(); - makes the board to panic

@nkolban
latest Arduino, latest ESP32_BLE.zip built from github
Board is "WeMOS" Wifi+Bluetooth+Battery (with wroom-32)

alexkirillov commented Sep 21, 2017

@MarosValter ,
Exactly the same "abort() was called at PC 0x400d880b on core 0" happens with my board.
After calling BLEServer *pServer = new BLEServer(); from sample.
If I would comment everything out and try enabling code line-by-line:
ble.init("MyESP32"); - works fine
call to new BLEServer(); - makes the board to panic

@nkolban
latest Arduino, latest ESP32_BLE.zip built from github
Board is "WeMOS" Wifi+Bluetooth+Battery (with wroom-32)

@nkolban

This comment has been minimized.

Show comment
Hide comment
@nkolban

nkolban Sep 21, 2017

@alexkirillov
For problems, issues, enhancements and other code related items on the BLE C++ classes for Arduino as delivered by the "cpp_utils" project, can I ask that you raise an issue here:

https://github.com/nkolban/esp32-snippets

This thread/issue is about "What should we do for BLE support for ESP32 Arduino" and not so much defect hunting/chasing on a given implementation. Currently the options for BLE support for ESP32 Arduino" are:

  1. Continue with the BLE C++ classes for Arduino as delivered by cpp_utils with existing API.
  2. Continue with the BLE C++ classes for Arduino as delivered by cpp_utils with alternate API.
  3. Create another implementation of BLE C++ classes based on ESP-IDF as an alternate for the delivered by cpp_utils.
  4. Something else ...

That thinking is still on-going and for the time being (1) exists and is gaining more users who are using it (and breaking it) in interesting ways. This has possibly taken the pressure off making a "formal" decision but one should assume that as time passes ... a community broad decision will likely be made.

nkolban commented Sep 21, 2017

@alexkirillov
For problems, issues, enhancements and other code related items on the BLE C++ classes for Arduino as delivered by the "cpp_utils" project, can I ask that you raise an issue here:

https://github.com/nkolban/esp32-snippets

This thread/issue is about "What should we do for BLE support for ESP32 Arduino" and not so much defect hunting/chasing on a given implementation. Currently the options for BLE support for ESP32 Arduino" are:

  1. Continue with the BLE C++ classes for Arduino as delivered by cpp_utils with existing API.
  2. Continue with the BLE C++ classes for Arduino as delivered by cpp_utils with alternate API.
  3. Create another implementation of BLE C++ classes based on ESP-IDF as an alternate for the delivered by cpp_utils.
  4. Something else ...

That thinking is still on-going and for the time being (1) exists and is gaining more users who are using it (and breaking it) in interesting ways. This has possibly taken the pressure off making a "formal" decision but one should assume that as time passes ... a community broad decision will likely be made.

@vanilla-thunder

This comment has been minimized.

Show comment
Hide comment
@vanilla-thunder

vanilla-thunder Sep 25, 2017

Imho, BLE API should be easy to use and understandable for newbies, so people could actually concentrate on building awesome IOT devices instead of researching and studying GATT and GAP services.
I might be a bit spoiled by JavaScript or PHP, but it seems wrong to me, if you need to copy-paste hundred(s) of cryptic code lines just to get a "hello world" program running.
After comparing example code for CurieBLE, BLEperipheral and mbed BLE, my favorite is CurieBLE.

vanilla-thunder commented Sep 25, 2017

Imho, BLE API should be easy to use and understandable for newbies, so people could actually concentrate on building awesome IOT devices instead of researching and studying GATT and GAP services.
I might be a bit spoiled by JavaScript or PHP, but it seems wrong to me, if you need to copy-paste hundred(s) of cryptic code lines just to get a "hello world" program running.
After comparing example code for CurieBLE, BLEperipheral and mbed BLE, my favorite is CurieBLE.

@d3cline

This comment has been minimized.

Show comment
Hide comment
@d3cline

d3cline Oct 10, 2017

I noticed an upstream change has broke BLE we had. I still feel this should be something the chip manuf cares about if they want the chip to live. I know if I was a rival chip manuf I would do everything I could to provide a sane arduino BLE stack to kill it because its clear the demand is here. Also I have the WiMos Battery and have beaten them up, I notice it has issues with the same brownout error as people are describing if the battery is low. Try removing the battery to see if this solves it, if so use a better battery and make sure it has a decent charge.

d3cline commented Oct 10, 2017

I noticed an upstream change has broke BLE we had. I still feel this should be something the chip manuf cares about if they want the chip to live. I know if I was a rival chip manuf I would do everything I could to provide a sane arduino BLE stack to kill it because its clear the demand is here. Also I have the WiMos Battery and have beaten them up, I notice it has issues with the same brownout error as people are describing if the battery is low. Try removing the battery to see if this solves it, if so use a better battery and make sure it has a decent charge.

@d3cline

This comment has been minimized.

Show comment
Hide comment

d3cline commented Oct 10, 2017

@d3cline

This comment has been minimized.

Show comment
Hide comment
@d3cline

d3cline Oct 10, 2017

To be quite blunt, why don't the people who work on the IDF pay attention to customer demand? With a little communication they could have had this built in no time. You know lots of other hardware manufactures ignored what people wanted and wasted tons of time and money on boondoggles too, they all failed. If I can order some nordic chips and have them working before this is fixed I likely will never buy another espreiff chip again. You may take this as rude, but it is just the nature of the beast and I am being honest.

d3cline commented Oct 10, 2017

To be quite blunt, why don't the people who work on the IDF pay attention to customer demand? With a little communication they could have had this built in no time. You know lots of other hardware manufactures ignored what people wanted and wasted tons of time and money on boondoggles too, they all failed. If I can order some nordic chips and have them working before this is fixed I likely will never buy another espreiff chip again. You may take this as rude, but it is just the nature of the beast and I am being honest.

@kriswiner

This comment has been minimized.

Show comment
Hide comment
@kriswiner

kriswiner Oct 10, 2017

kriswiner commented Oct 10, 2017

@DonWasabi

This comment has been minimized.

Show comment
Hide comment
@DonWasabi

DonWasabi Oct 11, 2017

I have mixed feelings about this, on the one hand: The few devs expressif pays to build the software seem to do a great job and the esp32 is one hell of a value for money beast which works pretty well on arduino, except BLE of course. As i heard the IDF 3.x is on the rise (my IDE of choice platformio still uses IDF 2.2x for arduino programming) so there might be some changes to the new IDF BLE part which may have delayed the arduino BLE work until the new IDF BLE APIs are stable? Just a guess from my side...

On the other hand: Well.. BLE was one of the main features why i decided to use this uc in my projects. My workaround is to use external components for BLE support until the arduino BLE API is ready. That may not be a perfect solution but at least i can work on other parts in the meantime while using the same communication interface.

What i would really appreciate is some kind of feedback from the BLE arduino devs, just to see how work is going on... is the work on hold? Is development done while we are speaking? Or do you even have some kind of release date in mind? If work is on hold or delayed, what are the reasons? Are there some parts where we could even help?

DonWasabi commented Oct 11, 2017

I have mixed feelings about this, on the one hand: The few devs expressif pays to build the software seem to do a great job and the esp32 is one hell of a value for money beast which works pretty well on arduino, except BLE of course. As i heard the IDF 3.x is on the rise (my IDE of choice platformio still uses IDF 2.2x for arduino programming) so there might be some changes to the new IDF BLE part which may have delayed the arduino BLE work until the new IDF BLE APIs are stable? Just a guess from my side...

On the other hand: Well.. BLE was one of the main features why i decided to use this uc in my projects. My workaround is to use external components for BLE support until the arduino BLE API is ready. That may not be a perfect solution but at least i can work on other parts in the meantime while using the same communication interface.

What i would really appreciate is some kind of feedback from the BLE arduino devs, just to see how work is going on... is the work on hold? Is development done while we are speaking? Or do you even have some kind of release date in mind? If work is on hold or delayed, what are the reasons? Are there some parts where we could even help?

@d3cline

This comment has been minimized.

Show comment
Hide comment
@d3cline

d3cline Oct 11, 2017

The issue is explained by nkolban at nkolban/esp32-snippets#121 (comment) Although I understand 'things take time' things in IT die quick, and there are always new solutions popping up, or cheaper old solutions, rivals trying to beat you to the punch (which if you are an independant app dev is the worst). Having something break like this is also frustrating. Why not base arduino on a stable release? When will this IDF development which breaks everything stop? ESP32 was supposed to be 'the 8266 + BLE' otherwise all the great things it can do can mostly be done by the 8266 (touch and audio is alright, but not even close to BLE). I would have never known or cared who espressif was if the 8266 wasn't so arduino friendly. So far it isn't that, and based on the track record for this issue it won't ever be that by the time it matters. And I think that is what upsets me, realizing this chip has a lot of potential which may be ignored because it will be obsolete by the time it is done, and all this time and effort I spent waiting for this solution when I should have just gave up on it months ago and used a nordic working solution. That this could be easily fixed if there was some kind of communication or priority to make BLE stable and functioning with a simple API. The functionality is there, it's just a pain to get to, I tend to feel the people who wrote those functions could easily write some wrappers but its 'community software' so why bother. Just because arduino is a community project should not mean it has the last priority. The licensing from my point of view is just as commercial as their IDF, more since I can rapidly develop things as a lone developer. The bottom line is if they care about selling chips and maintaining customer trust they might want to fix this and stop breaking it, make BLE a priority or expect we will move on.

d3cline commented Oct 11, 2017

The issue is explained by nkolban at nkolban/esp32-snippets#121 (comment) Although I understand 'things take time' things in IT die quick, and there are always new solutions popping up, or cheaper old solutions, rivals trying to beat you to the punch (which if you are an independant app dev is the worst). Having something break like this is also frustrating. Why not base arduino on a stable release? When will this IDF development which breaks everything stop? ESP32 was supposed to be 'the 8266 + BLE' otherwise all the great things it can do can mostly be done by the 8266 (touch and audio is alright, but not even close to BLE). I would have never known or cared who espressif was if the 8266 wasn't so arduino friendly. So far it isn't that, and based on the track record for this issue it won't ever be that by the time it matters. And I think that is what upsets me, realizing this chip has a lot of potential which may be ignored because it will be obsolete by the time it is done, and all this time and effort I spent waiting for this solution when I should have just gave up on it months ago and used a nordic working solution. That this could be easily fixed if there was some kind of communication or priority to make BLE stable and functioning with a simple API. The functionality is there, it's just a pain to get to, I tend to feel the people who wrote those functions could easily write some wrappers but its 'community software' so why bother. Just because arduino is a community project should not mean it has the last priority. The licensing from my point of view is just as commercial as their IDF, more since I can rapidly develop things as a lone developer. The bottom line is if they care about selling chips and maintaining customer trust they might want to fix this and stop breaking it, make BLE a priority or expect we will move on.

@kriswiner

This comment has been minimized.

Show comment
Hide comment
@kriswiner

kriswiner Oct 11, 2017

kriswiner commented Oct 11, 2017

@edcasati

This comment has been minimized.

Show comment
Hide comment
@edcasati

edcasati Oct 11, 2017

edcasati commented Oct 11, 2017

@kriswiner

This comment has been minimized.

Show comment
Hide comment
@kriswiner

kriswiner Oct 11, 2017

kriswiner commented Oct 11, 2017

@kriswiner

This comment has been minimized.

Show comment
Hide comment
@kriswiner

kriswiner Oct 11, 2017

kriswiner commented Oct 11, 2017

@ibaranov-cp

This comment has been minimized.

Show comment
Hide comment
@ibaranov-cp

ibaranov-cp Oct 20, 2017

Bit of a conflict of interest there @kriswiner , recommending your own products.. ;)

ibaranov-cp commented Oct 20, 2017

Bit of a conflict of interest there @kriswiner , recommending your own products.. ;)

@kriswiner

This comment has been minimized.

Show comment
Hide comment
@kriswiner

kriswiner Oct 20, 2017

kriswiner commented Oct 20, 2017

@me-no-dev

This comment has been minimized.

Show comment
Hide comment
@me-no-dev

me-no-dev Oct 21, 2017

Member

@kriswiner I could agree that sticking a competitor’s product in our face here is the least not nice ;) but whatever :D BTW @nkolban ’s BLE is now included ;)

Member

me-no-dev commented Oct 21, 2017

@kriswiner I could agree that sticking a competitor’s product in our face here is the least not nice ;) but whatever :D BTW @nkolban ’s BLE is now included ;)

@kriswiner

This comment has been minimized.

Show comment
Hide comment
@kriswiner

kriswiner Oct 21, 2017

kriswiner commented Oct 21, 2017

@Nakul93

This comment has been minimized.

Show comment
Hide comment
@Nakul93

Nakul93 Nov 14, 2017

How to increase the stack size I am using Wifi + BLE but when I use the wifimanager library it crashes. So I have to either comment wifi setup or ble setup. Please help

Nakul93 commented Nov 14, 2017

How to increase the stack size I am using Wifi + BLE but when I use the wifimanager library it crashes. So I have to either comment wifi setup or ble setup. Please help

@MartyMacGyver

This comment has been minimized.

Show comment
Hide comment
@MartyMacGyver

MartyMacGyver Nov 18, 2017

@Nakul93 I'd think adjusting the stack values in hardware/espressif/esp32/tools/sdk/include/config/sdkconfig.h might help. bt.h seems to use that and hardware/espressif/esp32/tools/sdk/include/esp32/esp_task.h as a basis for setting up their stacks. I'm not sure which stack value might be causing you problems though.

MartyMacGyver commented Nov 18, 2017

@Nakul93 I'd think adjusting the stack values in hardware/espressif/esp32/tools/sdk/include/config/sdkconfig.h might help. bt.h seems to use that and hardware/espressif/esp32/tools/sdk/include/esp32/esp_task.h as a basis for setting up their stacks. I'm not sure which stack value might be causing you problems though.

@haarislabs

This comment has been minimized.

Show comment
Hide comment
@haarislabs

haarislabs Jul 16, 2018

Is it still the same case ?? My team is planning to use Esp32 for a biomedical product in which reliability is a major factor, so @kriswiner do you still think esp32 is not ready for consumer products?
As of now I was testing all the features of esp32 (wifi,ble) using idf sdk and testing if everything would work for a quick prototype.

haarislabs commented Jul 16, 2018

Is it still the same case ?? My team is planning to use Esp32 for a biomedical product in which reliability is a major factor, so @kriswiner do you still think esp32 is not ready for consumer products?
As of now I was testing all the features of esp32 (wifi,ble) using idf sdk and testing if everything would work for a quick prototype.

@kriswiner

This comment has been minimized.

Show comment
Hide comment
@kriswiner

kriswiner Jul 16, 2018

kriswiner commented Jul 16, 2018

@beegee-tokyo

This comment has been minimized.

Show comment
Hide comment
@beegee-tokyo

beegee-tokyo Jul 17, 2018

Contributor

Same as @kriswiner , I tried to test all features, but using Arduino framework. Most of the stuff is working reliable now. Wrote some blogs about it ESP32

Working a customer project right now where we will use I2C to poll a sensor and send the data over BLE every 5ms. But because it (hopefully) will be a commercial product, we do not use Arduino framework for it, instead I program everything using directly ESP-IDF. First prototype code is working now. (Surprised that we could achieve the 5ms update rate over BLE).

Contributor

beegee-tokyo commented Jul 17, 2018

Same as @kriswiner , I tried to test all features, but using Arduino framework. Most of the stuff is working reliable now. Wrote some blogs about it ESP32

Working a customer project right now where we will use I2C to poll a sensor and send the data over BLE every 5ms. But because it (hopefully) will be a commercial product, we do not use Arduino framework for it, instead I program everything using directly ESP-IDF. First prototype code is working now. (Surprised that we could achieve the 5ms update rate over BLE).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment