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...
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)
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
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...
https://devzone.nordicsemi.com/documentation/nrf51/5.2.0/html/a01311.html#gaddbb12e078d536ef2e93b41d77ff6243
Sets the raw data packet that the device should advertise.
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 iffyalloca
memory allocation we have to do for it)