Most recent activity
-
Hi,
I wanted to build the release 2.04 via the Espruino project make script, but I got the following error:
user@bash: ~/Espruino$ BOARD=MDBT42Q make python scripts/check_elf_size.py MDBT42Q espruino_2v04_mdbt42q.elf Testing espruino_2v04_mdbt42q.elf for MDBT42Q STORAGE: 442368 -> 483328 CODE: 126976 -> 467548 CODE AND STORAGE OVERLAP make: *** [espruino_2v04_mdbt42q.app_hex] Error 1I made a git clone and switched to the release tag
RELEASE_2V04. Am I doing something wrong?
I remember it was working properly.Thanks!
-
That's great! However the firmware builder seems to be offline.
-
@Gordon why not have different firmware versions? Some people may not need more than 23 bytes, but some others will need it. You could have a BLE4 and a BLE5 firmware, with different features active.
-
Even so, I think it would be worth losing a bit of RAM permanently for - maybe not to max out the MTU, but at least to go for something significantly higher than 20.
I second that. It would allow more flexibility.
-
I'll give it another spin. Maybe I also made a mistake in the implementation. Whenever I set a bigger MTU size of 23 the SDK returned me an error 7 which is INVALID_PARAM. In the docs they say it's due to the fact that the maximum MTU size is smaller than the requested one, but I did update all the maximum MTU size definitions.
-
Yeah long writes were the go-to feature in BLE 4.0 and 4.1, since bigger MTU sizes were not available before 4.2.
You could also combine a bigger MTU with a long write enabling you sizes up to kilobytes which is huge for a LE transport. For my special use-case bigger MTUs however would be more appealing because it would reduce the lag between a http request and its response.
-
They do automatically negotiate. I think though that the max MTU has to be set before initializing the softdevice so I'm unsure if you are able to change this in runtime. That's why the
NRF.requestMTU(byte size)function would be way more useful.
Oh, I see, I forgot to set
RELEASE=1. Now it works!