Parallel Bluetooth connections?

Hi Everyone,
is it correct that I can only connect to one device at a time via Bluetooth? Is this a limitation of the chip?

Will mb Bangle2 support more connections?

--Maxi

Hi,

Yes, it's only one connection type at a time - although realistically that means two devices can connect - one as a peripheral, and one as 'central'.

It's not a restriction of the chip, so the firmware could support it - but it means throwing lots of memory away all the time in order to allow it, and for the vast majority of users would just prefer the memory.

There is an open issue on GitHub for it, and maybe at some point it could get added to the new Bangle as we have more memory there, but I guess worst case we could have a separate firmware image that you could flash that allowed it.

I do have several attempts of resizing JS variables after reboot to allow softdevice requirements to grow and shrink so both larger MTU and this would be possible only when one needs it, the setting could stick across reboots like current time does now. Latest attempt was via moving JsVars array to the beginning of data segment so its real beginning and size can be computed dynamically after initializing softdevice and using only the rest that remains free. That was the least invasive way with minimum changes.

Previous attempt was a bit more invasive and flexible - moving static data after stack so stack could grow down, softdevice grow up and js variables array stay between them. trouble with this one was determining size of static data so that data segment is placed right below end of ram and cpu stack below it. This is not possible to do in gcc linker file so two linking stages and dynamic generation of linker file would be needed.

However for multiple connections other changes are needed since single connection is hardcoded in couple of places (e.g. there are two variables named m_peripheral_conn_handle and m_central_conn_handle, that would need to be changed to array but there is more to it)

Cool, on nrf52840 are 12000 vars, so larger mtu and multi connect would be great to have.(edit: by reduction of vars )

A MQTT - BLE gateway with W5500 ethernet device would be a nice candidate for multiple ble connections.

@fanoush anything you like to share?

The first option for dynamic sizing sounds good. It seems like that's a good option (allowing the softdevice to change as required).

However there's quite a bit of work to do to make this usable - for instance the RAM needed actually has to be computed, and the options have to be saved somewhere. I guess dedicating some area of flash memory to it would be a good idea.

I feel like just having separate firmware images would be far easier though. And it's something I need to do more anyway, and for instance many people would prefer not to have a networking capability inside Puck.js but to instead have a bunch of extra storage space.

There is a very neat online build facility for NodeMCU for the ESP8266 https://nodemcu-build.com/ which lets users select the modules they want and it then builds a custom firmware. Something like that for Espruino might be a solution - but a lot of implementation effort:-(

Well, @JumJum did make something but I'm not sure he felt enough people were using it for it to be worth maintaining (http://forum.espruino.com/conversations/­334202/)

It's something I have considered hosting here, but then I'd only do it for official boards.

anything you like to share?

as for sizing variables - not much right now, there is old conversation about this starting here http://forum.espruino.com/conversations/­338789/?offset=25#14922414
and it is true that it brings some additional complexity so basically I was just testing the idea with no expectation this could get merged. Currently I don't have the persistence of the change across reboot working, just sizing at startup according to what soft device needs - so with static MTU there is currently no variability => it always autosizes to same size as it is now. The only difference is that you don't need to tune where data segment starts in linker file according to MTU like it is done now here https://github.com/espruino/Espruino/blo­b/master/targetlibs/nrf5x_12/nrf5x_linke­rs/linker_nrf52_ble_espruino_bootloader.­ld#L7 You size variables to maximum value in board file like if it would start at 0x20000000 with no softdevice at all and it then scales down. So in a way it is more simple than it is now. On the other hand the number of variables in board file is then just theoretical maximum to keep enough space for static variables and stack, not the real value, which may be confusing.

Currently bluetooth on nrf52 is initialized before variables (= calling jsvInit() in main.c) so the available size for variables is already known when needed. This initialization order even now causes another issue here https://github.com/espruino/Espruino/iss­ues/1696 as BT code tries to read MAC address from uninitialized variables. Which also suggests that maybe another storage for such persistent data like mac address could be handy to not to need variables at that stage. I think ESP32 even have flash partition for that - mac address, last AP+password, assigned DNS,...?

Anyway I can clean it up and make pull request or publish patch/branch to see it. It is quite small but as explained it currently makes no difference in reality as the rest of stuff is static - no dynamic MTU implemented yet.

As for multiple connections it can either be added to current code or the NRF build could include (currently excluded) standard GATT module which handles that (and MTU too) see https://github.com/espruino/Espruino/tre­e/master/targetlibs/nrf5x_12/components/­ble/nrf_ble_gatt . Currently the BT is mostly handled via custom code which makes it smaller and more flexible so adding those additional nordic layers (= somehow hooking into this https://github.com/espruino/Espruino/blo­b/master/targetlibs/nrf5x_12/components/­ble/nrf_ble_gatt/nrf_ble_gatt.c#L255 ) may not be be a good idea(?).