The loop puzzled me and also the double setInterval(). ...but as you noticed, I had withdrawn it right after initial/partial post. NM.
If you restart a function at the end with a setTimeout() (with a time dependent, calculated/variable) tiemout time), you are fine, because this gives the system time to answer things that may have queued up. Chopping up bit work helps in that respect.
Regarding spi transfer being asynchronous, I'm not sure. I assume that it is some what and when it is, it still has a buffer that may overflow... It is for sure implemented natively - not in JS - in order to act timely, especially when it is soft spi. Being natively implemented and considerate of the Espruino context, I expect it on higher priority - can interrupt JS process - but is 'knows' what JS can do to the system and behaves accordingly (managing variables, buffer, etc).
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.
The loop puzzled me and also the double setInterval(). ...but as you noticed, I had withdrawn it right after initial/partial post. NM.
If you restart a function at the end with a setTimeout() (with a time dependent, calculated/variable) tiemout time), you are fine, because this gives the system time to answer things that may have queued up. Chopping up bit work helps in that respect.
Regarding spi transfer being asynchronous, I'm not sure. I assume that it is some what and when it is, it still has a buffer that may overflow... It is for sure implemented natively - not in JS - in order to act timely, especially when it is soft spi. Being natively implemented and considerate of the Espruino context, I expect it on higher priority - can interrupt JS process - but is 'knows' what JS can do to the system and behaves accordingly (managing variables, buffer, etc).