You are reading a single comment by @fanoush and its replies.
Click here to read the full conversation.
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.
@fanoush
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_enabledirectly into espruino code as it is basically just callingsd_ble_enablewith variableapp_ram_basecontaining&__data_start__https://github.com/espruino/Espruino/blob/master/targetlibs/nrf5x_12/components/softdevice/common/softdevice_handler/softdevice_handler.c#L566Maybe 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 < 5and 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.