shiftOut differences:

• Added pin info for bit-banded pin addresses (and jshGetPinAddress) - only for STM32s

• jshIsPinValid - not for STM32s

so there is potential for optimisation.

Compare simple functions like:
var a= 0; for(var i = 0; i < 100000;i++) a++;
Is cpu the problem, or compiler, or RTOS, or ???

I think in the JS execution case it's probably that while the CPU is fast it's having to grab the code to execute out of QSPI flash on demand? I imagine if you found the 'hot' interpreter functions and loaded them into RAM then execution speed would raise dramatically

I imagine if you found the 'hot' interpreter functions and loaded them into RAM then execution speed would raise dramatically

Yes, with ESP32 i2s parallel dma you can have about 500fps for a 64x64 panel without any flicker.

Reading the esp32 technical reference manual state that pins are register mapped

input

• one regsiter for D0-D31 and one for D32-D39

output

• one register to set D0-D31 and one for D32-D39 high
• one register to set D0-D31 and one for D32-D39 low

So the shiftOut for ESP32 will never be as fast as on STM32 boards

But ESP32 offers i2s, which can do parallel shiftout with dma, whith nearly no cpu impact.

Just added a sample video to this conversation

It's possible that jshGetPinAddress could be extended to be an address + bitmask. That would benefit nRF52 greatly as well

The ESP32 has a limit of 4MHz for setting gpio's via register. Just throttled i2s from 40MHz to 3MHz and the result is still ok.

It's possible that jshGetPinAddress could be extended to be an address + bitmask. That would benefit nRF52 greatly as well

Great! So working on this is a win for supported boards a well.

For the ESP32 there is one register plus bitmap to set a pin and a different register plus bitmap to set a pin low.

@jumjum123 can you please share your code for this.