• you can just apply it and modify as you wish if you want as it is just few lines

    Not sure about the APP_RAM_BASE stuff, I guess it would be better to skip it for now or ifdef it at least. Or even inline the softdevice_enable directly into espruino code as it is basically just calling sd_ble_enable with variable app_ram_base containing &__data_start__ https://github.com/espruino/Espruino/blo­b/master/targetlibs/nrf5x_12/components/­softdevice/common/softdevice_handler/sof­tdevice_handler.c#L566

    Maybe the DLE stuff could be #ifdef-ed to some config parameter but since it is called after softdevice is already initialized it looks like it doesn't take any extra memory to have larger data PDU size. So not including and still keep larger MTU is useful only if it breaks compatibility.

    BTW currently it is all there only for NRF_SD_BLE_API_VERSION < 5

    and also it does not include MTU change in DFU bootloader for now. Tried that too and it works over 62 bytes now for me (tried MTU 131 as that hopefully sends blocks of 128 bytes?). Seems that nrfconnect for android now negotiates higher MTU and sends more data automatically and the speed average of FW upload is over 4KB for me - that progress graph it shows while uploading now spikes to 10-11KB/s but the average is far lower so I guess there are some fixed delays not related to faster BLE transfer as increased MTU does improve just those spikes while the average improves only partially. Still testing this. maybe it is those command packets which are send between data packets as those do not profit from larger size.

About

Avatar for fanoush @fanoush started