You are reading a single comment by @Gordon and its replies. Click here to read the full conversation.
  • 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/documenta­tion/nrf51/5.2.0/html/a01311.html#gaddbb­12e078d536ef2e93b41d77ff6243

    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)

About

Avatar for Gordon @Gordon started