Some fixme in bluetooth.c

Working on NRF.setAdvertizing there are some FIXME on the road (jswrap_bluetooth.c)
Actually I reach these:

• sd_ble_gap_device_name_set
  
• sd_ble_gap_adv_data_set
  
• adv_data_encode
  For the first one, there is an idea what to do.
  The others are some more questionmarks on a long long way.
  
  

Generally, I would prefer not to have device related code seperated by #if in a core file
@gordon, whats your point to that, could we move them to bluetooth.c ?

Yes, I ifdef'd the code because I was trying to do a big refactor quite quickly and was trying to make as few breaking changes as possible - so you'd have an easier way to get started with your port :) It would definitely make sense to move those to calls in bluetooth.c

For the functions, I would just google the function name in the nordic docs...

sd_ble_gap_adv_data_set

https://devzone.nordicsemi.com/documentation/nrf51/5.2.0/html/a01311.html#gaddbb12e078d536ef2e93b41d77ff6243

Sets the raw data packet that the device should advertise.

adv_data_encode

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.sdk52.v0.9.1%2Fgroup__ble__sdk__lib__advdata.html

Work out what the raw advertising data should actually be, based on what is fed in. The ESP32 SDK probably has something similar.

However this is actually platform independent code, and is actually pretty simple if you look inside adv_data_encode (once you get past all the checks and call soup). It would make a lot more sense to do all the encoding inside jswrap_nrf_bluetooth_getAdvertisingData itself...

For instance there's a decoder for that same advertising data on line 1300 (jswrap_nrf_bluetooth_setScan_cb), so it's probably more sensible to stick an encoder into the file than to have separate calls for each different encoder (as well as the slightly iffy alloca memory allocation we have to do for it)

After digging through ADV-functions for esp32 I found these only :

• esp_ble_gap_config_adv_data(esp_ble_adv_data_t *adv_data) //adv data is something like ble_advdata_t
  
• esp_ble_gap_config_adv_data_raw(uint8_t *raw_data, uint32_t raw_data_len)
  
  

As expected esp_ble_adv_data_t is different to ble_advdata_t. There is some overlapping and I'm sure to find a way to get it working

But I cannot find anything like adv_data_encode. Looks like it happens behind the curtain.
In my (poor) understanding of jswrap_nrf_bluetooth_setAdvertising the only way to make this matching would be a big rebuild of jswrap_nrf_bluetooth_setAdvertising.
Any better idea ?

esp_ble_gap_config_adv_data_raw looks perfect - and yes, I'd imagine the standard function has stuff built into the library.

adv_data_encode is here: https://github.com/espruino/Espruino/blob/059eb0a3e6031e065dea5bc1101561d4b95b8e9c/targetlibs/nrf5x/components/ble/common/ble_advdata.c#L474

It calls into other functions to include the relevant advertising bits and bobs. They're all pretty simple once you strip away all the checks though - for example services is this: https://github.com/espruino/Espruino/blob/059eb0a3e6031e065dea5bc1101561d4b95b8e9c/targetlibs/nrf5x/components/ble/common/ble_advdata.c#L451

So it just adds an array that's [len, BLE_GAP_AD_TYPE_SERVICE_DATA, uuid_16, uuid_16, data....] to the stuff that's advertised.

So yes, you'd need to rebuild jswrap_nrf_bluetooth_getAdvertisingData so it didn't use ble_advdata_t, but it should be pretty straightforward. I can look into it at some point in the next few weeks if you want?

Thanks for the feedback, each information is its own step for my (hopefully better) understanding.
There is a function deep inside Bluetooth stack sources, which might help.
For now I bypass the data from jswrap_nrf_bluetooth_getAdvertisingData and use the API-Call which takes a structure to set ADV data.
At least for first examples it works.
Next step will be how to handle readable and writeable for char and descriptors