Most recent activity
-
A Very Merry Christmas and Happy New Year to you, Gordon! - A well deserved break.
-
Looks pretty neat!
-
Very neat - and inspiring! ...especially the extra control and connectivity.
-
Obviously missed the announcement... great move to add these power drivers onto the board, and a nice name for the product. As a plug-and-play, it is a leap-up from wire-and-play. Had to order a Jolt.js right awa, incl. a backup.
-
I see the value of firing on press when there is no other option and I understand also the issue of double press because of timing and queuing of the events. For that reason - and especially on app / context switch - repeat has to be disabled and the new context (app) has to arm the button again the way the app expects.
-
I'm not so sure if that is the only (or good) way to give the impression to be (more) responsive.
Why? If something 'goes off' on the press event, you cannot 'go back'. To still support long presses requires two different contexts and the awareness of them - action starts either on press or on release. To be aware of which context is active requires a visual cue.
My solution to give feedback - visual cue - to the user that the press has happen / is noticed - and I think it is all about that - can be conveyed differently, for example with a quick change / flash of a half circle or oval next to button.
The case of press event starts something is still a valid case, thinking about the cursor keys on a key board or the special character - character w/ diacritics - in pop-up. The response to such a press would be passing callback that is then called over and over on a configurable interval until release. Double press in rapid fashion is could be integrated as well in the event.
In the beginning when I had to use a single button interface vs a two - left and right - button interface, it created some relearning pain, but the value of dealing with just a track pad - position irrelevant - made up for a lot of it.
When building the UI - https://www.espruino.com/ui - visuals at https://forum.espruino.com/conversations/292990/ - I had to handle the touch this way... on touch a visual cue is give to the user about it: an element fence or border shows as a white rectangle, which goes away on un-touch (for speed sake redrawn in same place in background color... all on a 'big', 262K color serially connected - thus slow - display. On other occasions I was trying to save and restore, but that took ages, see https://forum.espruino.com/comments/11906513/. With Bangle2's limited color depth and speed, it should not be that a big issue to save the few pixels around the button and flip the around and then restore, or some other kind 'flash', noticeable by the user.
This kind of a visual cue could be a 'OS' level integrated option. It would also have to handle app-redraws of the area, so than on release the correct display is restored in this area.
Side note: touch screen vs. (single) button is not that much difference: touch is just setting the focus before treating the touch (or release), and w/ button, the select happens in a different way. Without touch there are two modes: navigation and (data) entry/edit mode. In navigation mode, a short press unselects current element and selects next element, a longer press switches into the entry and would also be either directly the return to navigation mode or to a (popup-) menu, that even allows a cancel / restore (and other - app - options). A single button UI needs absolute consistency in behavior for a 'happy' - not confused and giving up - user.
-
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.
Espruino makes IoT as easy as 123!