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/tree/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 :)
iOS will automatically set MTU to 185 bytes. I think max. 200 bytes is a good size. This would be very handy if we are using the HTTP Proxy example.
Apart from that, is it correct that we would have to switch SDK to a newer version to support bigger MTU sizes? I feel like Espruino still runs on SDK 12.
© Espruino, powered by microcosm.
Report a problem