I love Espruino and bacon! :P
Most recent activity
it would be nice if the Layout automagically knew to redraw
Yes, I was wondering about that. Thinking about even the clock example I feel there might be too many edge cases for us to be able to implement it easily.
Not to be contrarian, but when using a using a g.flip() approach I always have a "screen redraw" function in my code after doing some updates. The Espruino app code is generally so small that hand crafted screen updates seem like the logical thing to do -- so I'm fine with calling a "layout.update()" function.
Yeah that's great! I can already see myself building some menus with something like this ;) And it is more what I had in mind too -- I didn't mean to suggest we should implement a CSS style layout engine. This really hits the "elegant simplicity" zone.
I'm not using bangle.js yet (mostly because I'm stuck in a SEA country with unreliable shipping, though plan on getting one shortly -- maybe version 2? :P), but I feel this would be a real break through issue for Espruino. I often write code with display elements on say an OLED screen (128x64), but then after want to redeploy this code on a 160x128 or 240x240 or 320x240 screen -- you get the idea -- and it's a real pain.
So I'm suggesting it deserves some thought as it's a real opportunity. I like Flexbox and something similar might not be a bad first step!
I'm not sure what it would look like, but lines for example could be expressed in terms of percentage of screen (start at 10% and go to 80%), or text could be positioned at 1/3 of the screen or who knows. I guess this would break a little if aspect ratios changed. Some ST7735's are 128x128, vs 160x128. But even just that would make resolution independent display elements easier.
So this is an ESP8266, let's be clear. Has anyone ACTUALLY been able to increase practical RAM in this device using external i2c or SPI modules? The ESP32 certainly has PSRAM, but that Espressif provides this solution suggests RAM expansion itself is not so straight forward as just wiring up modules. For other Espruino Official boards is it possible? Wouldn't there be required some modifications (or at least an i2c driver for example) to Espruino itself to support it?
Also keep in mind that the original poster said he was "new to this". While uploading individual code modules using Storage is a new and innovative approach to coding in Espruino for sure (and then after say using "eval" to load these modules), it's certainly more complicated.
That said, I'm certainly looking into it, but it's a new way of thinking I find.
It's just an ancillary note, but there is a function to write out your code to flash directly as opposed to storing it in RAM. It's in the Web IDE -> Settings -> Communications -> Save On Send -> "Direct To Flash".
You can experiment with that as it might free up some additional JSVars if you were not already using it.
@Ruprect99 I've had this before a few times and it generally seems to point to some flash corruption?
I find that typing "reset(1) -> save()" (could also be "reset(0)") seems to force some kind of clean up algorithm (flash compacting?). That might resolve it.
But the sure way to deal with it is just to reflash the firmware. Make sure to use the "erase_flash" option in esptool before doing so though, just to ensure you reformat the entire flash address space.
You don't need C to write a display driver for your e-ink display. I had something similar (their 2.13 inch display), but didn't have the chance to to write a proper driver. Unfortunately, because the displays are fragile, it broke in transit during a house move recently.
Gordon has a display driver writen for an SSD1606, it's possible that your display is not too far off and you could adapt it. You'd need to identify the chipset first, then make the modifications.
Wow, that's really impressive! I had been thinking of throwing up a github just like that for the TTGO Watch 2020. You've ever got the unbuffered frame buffer modification for the ST7789V. I'll have a deeper look at this. :)
Were you aware of:
It will disable the BLE functionality on the ESP32. It will also erase all your code. But when you restart the board, it should give you an additional 2K JSVars, so around 4K JSVars total. You can then reflash your program and take advantage of the additional memory space.
Additionally, if you get a board with PSRAM (4MB or 8MB), it will give you up to another 16K JSVars, which will bring your total up to 20K.
Wow, great! I get the pattern now. Thanks for laying it out so clearly -- the changes in github make it really clear. I'll test it out and hopefully you'll see my first module -- one day soon :)