Most recent activity
-
sure... but the intention w/ modules in the end is to have them accessed and used like modules. For development it is nice to have them inline. Putting the 'module-frame' around keeps the code as close as possible to the module require() and use pattern.
-
...oops... sorry @Coder2012 to have mysellf repeated.... figured by digging in the past...
-
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.
-
Teaching Programming, JavaScript,... and enrich the student's take away with a nifty gadget!
Worked also w/ a Puck and w/ Pixle. I see more creativity w/ a device w/ no display or limited display feature, like the Puck with the 3 color LEDs.
-
Glad you got it sorted out.
-
Sorry for the confusion... updated the original post and repeat it here again for who ever will come across same need...
Getting cutting edge build: Go to the Espruino Download page,
Find a Binarysection,select the board, and pick theCutting Edge buildlink - at the bottom of the build(/release) list.Btw, list of ALL cutting edge Espruino builds is at espruino.com/binaries/travis/master/
-
The cutting edge build
espruino_2v19.123_wifi.binfrom https://www.espruino.com/binaries/travis/master/espruino_2v19.123_wifi.bin does it [EDITED: BUT WATCH: this is fluid... go to the Espruino Download page,Find a Binarysection,select the board, and pick theCutting Edge buildlink - at the bottom of the build(/release) list].> ____ _ | __|___ ___ ___ _ _|_|___ ___ | __|_ -| . | _| | | | | . | |____|___| _|_| |___|_|_|_|___| |_| espruino.com 2v19.123 (c) 2023 G.Williams > 88.02419090270 wifi connecting... 00.74121856689 wifi connected >...and it will be in 2v20 when that is released.
-
used the binary approach and figured that 2.15, 2.17, 2.18 work. So I doubted my earlier confirmation that 2v19 failed. But: it kept failing... So now back to 2v18... (and some chat w/ @Gordon).
I noticed that connection could be made within the range of 8..12 seconds, but failing was always within 10..11 seconds:
2v19 (c) 2021 G.Williams > 42.02763271331 wifi connecting... 52.05555248260 wifi connect error No 'ready' after AT+RST >2v19 (c) 2021 G.Williams > 69.02761077880 wifi connecting... 79.05558586120 wifi connect error No 'ready' after AT+RST >> ____ _ | __|___ ___ ___ _ _|_|___ ___ | __|_ -| . | _| | | | | . | |____|___| _|_| |___|_|_|_|___| |_| espruino.com 2v18 (c) 2021 G.Williams > 00.02708053588 wifi connecting... 08.74545001983 wifi connected >2v18 (c) 2021 G.Williams > 15.02713966369 wifi connecting... 23.73204612731 wifi connected >2v18 (c) 2021 G.Williams > 17.02713966369 wifi connecting... 29.74073886871 wifi connected >Disconnecting from power and reconnecting power, Espruino-Wifi, upload-run test code usually made it 12 seconds... but also got 8 seconds versions...
-
'good' news: 2v01 connects...
> ____ _ | __|___ ___ ___ _ _|_|___ ___ | __|_ -| . | _| | | | | . | |____|___| _|_| |___|_|_|_|___| |_| espruino.com 2v01 (c) 2018 G.Williams > 79.02789402008 wifi connecting... 91.23308467864 wifi connected >Now is the time to find where it went of the rails... ;-)
Espruino makes IoT as easy as 123!