• Nice - I'd be interested to find out if there's anything else that uses the long writes? I'm not sure I'd want to merge that exactly as-is, but I reckon it could be tweaked such that the memory buffer would be allocated on demand out of JsVars.

    The malloc thing should really be allocated on the stack I guess (since I don't really support malloc in Espruino - I'm amazed that worked). Although honestly I don't think that's even needed - the event could be posted and then the data read directly out of the buffer outside of the IRQ.

    I had a quick play with the MTU stuff and did this: https://github.com/espruino/Espruino/treĀ­e/increased_mtu

    But it takes a huge chunk out of available RAM. Perhaps an increased (but not huge) MTU would still be an idea?

    I haven't had a chance to test it out properly, but my hope is that I can enable it for the bootloader to try and improve the speed of flashing (but then the flasher will have to know about the MTU).

  • Would it be possible to create a library function that takes a maximum MTU size as parameter, and allocates the memory from jsVars? For example NRF.setMaxMTU(xxx) or something like that?
    I think right now this is could be an "expert" feature, so the user either knows the needed MTU size, or can spend some time guessing experimenting. Can the devices auto-negotiate?
    But if available, that could open up some new opportunities. For example my "data streaming" thingy might benefit from higher MTU size & higher bandwidth. Ok, should go and actually complete that :)

  • 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.

About

Avatar for AkosLukacs @AkosLukacs started