To drive the panel decently, it needs a dedicated controller to meet the timing requirements for a flicker free operation. The software has to pull all registers to use optimally the hardware and not the sosftware. Reading https://thepihut.com/products/interstate-75 tells me that there is not much juice left on a STM32F103RB - not from point of memory and cycles - to run and application on a source based interpreter (even though thins have sped up incredibly since Espruino's birth in the form of and on the Original board).
BUT: you could find a way to combine any Espruino with an STM32F103RB Nucleo board and run some smart and fast buffer transfer-sw on both boards. In the Espruino you use the Graphics object to build the Graphics.... after all - w/ a 24bit color depth - it is 64x64x3 = 12288 < 13kBytes Espruino graphics buffer that has to be transferred in the background from Espruino to the Controller where it is then displayed.
The advantage of using neopixel is that there is no constant scanning required: each 8x8x8 color dot has its own memory and led driver. On the other hand, updating a 64x64 matrix with neopixels takes it's time since it is serial and can only be 800Kbps, which yields a max 8 fps (frames per second) using constant transfer. Going parallel allows higher frame rates.
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 STM32 option from Waveshare mentions Nucleo STM32F103RB (https://www.waveshare.com/wiki/RGB-Matrix-P3-64x64#Working_with_STM32) is the 'same' chip as is on the Espruino Original board.... The software is a different story, though.
To drive the panel decently, it needs a dedicated controller to meet the timing requirements for a flicker free operation. The software has to pull all registers to use optimally the hardware and not the sosftware. Reading https://thepihut.com/products/interstate-75 tells me that there is not much juice left on a STM32F103RB - not from point of memory and cycles - to run and application on a source based interpreter (even though thins have sped up incredibly since Espruino's birth in the form of and on the Original board).
BUT: you could find a way to combine any Espruino with an STM32F103RB Nucleo board and run some smart and fast buffer transfer-sw on both boards. In the Espruino you use the Graphics object to build the Graphics.... after all - w/ a 24bit color depth - it is 64x64x3 = 12288 < 13kBytes Espruino graphics buffer that has to be transferred in the background from Espruino to the Controller where it is then displayed.
Conceptually you can compare it with what is described in Large Display: x by y w/ 24 bpp Graphics buffer visualized with neopixel string in zig-zag layout. I used Espruino (-Wifi) to for the application and the Graphics buffer, and a neopixel string as a combined controller and display. All was inspired by Retro Horse Derby Game Board with Neopixels showing Reaction Game Status.
The advantage of using neopixel is that there is no constant scanning required: each 8x8x8 color dot has its own memory and led driver. On the other hand, updating a 64x64 matrix with neopixels takes it's time since it is serial and can only be 800Kbps, which yields a max 8 fps (frames per second) using constant transfer. Going parallel allows higher frame rates.
You find more 'display stories' of mine in the forum to inspire you... such as Driving LED matrix with shift registers such as 74HC595, or ShiftOut question for Hannio flipDot Display or Retro Bubble Displays driven with 74HC595... it is all about the same...
For fast manipulation / transfer within graphics buffer I esperimented with embeded C functions. Efficiently moving things around in zig-zag Graphics buffer visualized w/ 24/32 bpp displays / neopixel strings. This technique can be used for a fast transfer from Graphics application board to Display controller board....
How snappy graphics could be depends all on the color depth and resolution.