NRF -> BLE

[gfwilliams]

Historically NRF has made sense because Bluetooth LE was for Nordic chips, but now it's implemented on ESP32 we want something more general.

Of course everyone is now using NRF so we need to really make BLE just an alias of NRF for now (or vice-versa). This is easier said than done though!

[vshymanskyy]

Why is it hard to add an alias?
The NRF module also has some NFC functions, this could also be improved...

[gfwilliams]

build_jswrapper.py just needs modification. Sure you can just execute the code var NRF=BLE; at boot but ideally it'd be less of a hack than that.

NRF has NFC functions because it's for the NRF5x chips, which have BLE and NFC. So yeah, NFC could be split out but then it gets even more difficult to do nicely.

[wybiral]

For the API it would make the most sense to me if BLE and NFC were both their own object since not all devices are going to have them combined and users probably don't expect them to be combined.

How complicated of a change would it be to have NRF be exclusive to devices that actually have an nRF5X chip and then shim/alias BLE and NFC?

[gfwilliams]

I thought there might have been a smart way of doing it, but I think realistically it's just going to be a matter of duplicating entries - which would really be needed for the documentation anyway since we need the old stuff to say 'deprecated'.

However, the issue then is what happens for all the bluetooth events. Do we then have to double them up and emit them on BLE and NRF at the same time? That's just going to end up making everything slower and more memory hungry.

[wybiral]

Darn, I was hoping it would be as simple as something like NRF = {connect: BLE.connect, nfcURL: NFC.url, ...} and stubbing some functions for docs but it sounds much more involved.

Is this the main reason that BLE support is missing for the ESP32s?

[gfwilliams]

I was hoping it would be as simple as ...

Yeah, I some ways it is if you don't care about slowing things down & using more memory. I'd like to avoid that if I can.

Is this the main reason that BLE support is missing for the ESP32s?

There is BLE support in ESP32. The issue is it's not complete, but that's because just one person has been working on it as a hobby. Basically ESP32/ESP8266 are really hobbled by the fact that very few users contribute back to the main Espruino interpreter or are willing to pay so that someone else can fix issues. Some do, which is great - but it is just a handful of people.

[wybiral]

I've got a Puck, MDBT42Q, ESP32-DevKitC, experience programming in C/Javascript/Python, and I intend to use Espruino for a bunch of projects in the near future so I'll try to help out wherever I can (even if just testing and reporting).

It's an awesome project and I love the idea of having the same environment on multiple devices like this!

[ylh888]

I was hoping it would be as simple as ...

Yeah, I some ways it is if you don't care about slowing things down & using more memory. I'd like to avoid that if I can.

Is this the main reason that BLE support is missing for the ESP32s?

There is BLE support in ESP32. The issue is it's not complete, but that's because just one person has been working on it as a hobby. Basically ESP32/ESP8266 are really hobbled by the fact that very few users contribute back to the main Espruino interpreter or are willing to pay so that someone else can fix issues. Some do, which is great - but it is just a handful of people.

• I appreciate your points about supporting ESP32/ESP8266. In your product line will you consider making a more traditional ESP32 board (support for Wifi and Bluetooth but without the 'extras' in Puck.js)? It could see more people supporting Espruino than buying generic ESP32s and flashing Espruino.

• Will the BLE support in Espruino ESP32 be sufficient for BLE HID? What would it take to getting going?

Thanks.

[MaBecker]

@ylh888 not sure what you expect, because ESP's are unsupported boards.

You are welcome to join the development and push the ESP's.

Check this ongoing issue #1777

[gfwilliams]

In your product line will you consider making a more traditional ESP32 board

Realistically, no. It's come up a few times on the forum, but basically it comes down to this:

Would you buy one of these new Espruino boards? Maybe - but probably only one, and then every time you hit a problem on any of your other ESP32s you'd want support.

It's just not a sensible option for me business-wise in any way. About the only way it'd work is if I did a closed-source port to ESP32, but I imagine that's not what you'd want.

It could see more people supporting Espruino than buying generic ESP32s and flashing Espruino

Sadly that seems super unlikely given the current numbers. Many are drawn to ESPxx because of the price - they're not going to pay maybe 4x as much for a basically identical board.

Will the BLE support in Espruino ESP32 be sufficient for BLE HID?

Honestly, I don't know. I don't believe so though, no. It definitely isn't good enough to allow HID to work with the same API calls as it does on Nordic chips.