Parallel Bluetooth connections?

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(?).