Is the bind used to partially apply the function and 'store' it in a variable
Yes - exactly as @JumJum says - you're basically eliminating the parsing step, which is the slow bit in Espruino.
In your approach, setting pins with a register limits other solutions.
I'm totally happy to have something like this at the top of shiftOut so you can still have your fast I2S implementation:
[#ifdef](https://forum.espruino.com/search/?q=%23ifdef) ESP32
if (pins.length<=8 && clk && jsvIsFlatArray(data) && etc...)
return esp32_I2S_implementation(...);
[#endif](https://forum.espruino.com/search/?q=%23endif)
// original register-based code
The thing I don't like is creating a duplicate API for the same thing if there isn't a good reason. Having two similar APIs just confuses people, gives us more stuff to maintain, and ultimately means that instead of one, optimised solution we have two partially optimised solutions.
If we can make the existing shiftOut fast, existing code that uses it (like LPD6416) should benefit as well.
If there really is something in shiftOut's API that makes it too slow that's different, but am I right in thinking that as far as we've found out so far:
Currently, shiftOut is quite fast on STM32, less so on other platforms
With the branch I posted (and maybe a few fixes) it should be fast on all platforms, but not as fast as @JumJum's test code
So far the biggest reason we're sure of for the difference in speed seems to be direct memory access vs jsvIterateCallback?
So if we can merge my tweaks and fix jsvIterateCallback we should be within a few percent of @JumJum's implementation, and then maybe we can add the special case for I2S to really speed things up for ESP32 in the right cases?
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.
Yes - exactly as @JumJum says - you're basically eliminating the parsing step, which is the slow bit in Espruino.
I'm totally happy to have something like this at the top of
shiftOut
so you can still have your fast I2S implementation:The thing I don't like is creating a duplicate API for the same thing if there isn't a good reason. Having two similar APIs just confuses people, gives us more stuff to maintain, and ultimately means that instead of one, optimised solution we have two partially optimised solutions.
If we can make the existing
shiftOut
fast, existing code that uses it (like LPD6416) should benefit as well.If there really is something in
shiftOut
's API that makes it too slow that's different, but am I right in thinking that as far as we've found out so far:shiftOut
is quite fast on STM32, less so on other platformsSo if we can merge my tweaks and fix jsvIterateCallback we should be within a few percent of @JumJum's implementation, and then maybe we can add the special case for I2S to really speed things up for ESP32 in the right cases?