Awesome ! The simple fixes are the best and I really appreciate your support.
Not wanting to to drag this out but I am sure you want to make this 'networking' as robust as possible. I see at least one 'edge' case that would result in a tight infinite loop right now (which I assume locks pretty hard on this platform). It's an easy fix I think and I am happy to do it my end but probably best you maintain your own code base.
The handlers loop in the ser.on("data" function is now a while loop which checks against the string returned from the handler. There could be cases (like the current IPDHandler in the wifi code if it's not complete) where the same line is returned back to the function which would loop indefinitely I think.
Probably just a simple precondition vs result check with a break would solve it and if the handler didn't consume anything then it must be OK to continue ?
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.
Awesome ! The simple fixes are the best and I really appreciate your support.
Not wanting to to drag this out but I am sure you want to make this 'networking' as robust as possible. I see at least one 'edge' case that would result in a tight infinite loop right now (which I assume locks pretty hard on this platform). It's an easy fix I think and I am happy to do it my end but probably best you maintain your own code base.
The handlers loop in the
ser.on("data"
function is now a while loop which checks against the string returned from the handler. There could be cases (like the current IPDHandler in the wifi code if it's not complete) where the same line is returned back to the function which would loop indefinitely I think.Probably just a simple precondition vs result check with a break would solve it and if the handler didn't consume anything then it must be OK to continue ?
Thanks again, Steve