Search results for:

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.

-hfc

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.

Some ideas...
-hfc

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.

-hfc

@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.

https://www.espruino.com/SSD1606

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.

Everything else is Javascript, so it's a matter of "converting" thinking in C to thinking in Javascript.

-=hfc

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. :)

Hi.

Were you aware of:

ESP32.enableBLE(disable)

?

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.

-hfc

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 :)

Also if you look at his actual code at his link, from my impression its almost exactly like the ILI9163 module. So I'm not sure what I would do exactly to make it submissable -- it SEEMS like a module for me already, and works -- though to be fair, I've never made a module before for Espruino. :)

Well its not my work. So I guess we'd have to ask him :)

Jorgen did a driver for the ST7735 a while back. Its in this thread:

http://forum.espruino.com/comments/12347822/

You can require the driver directly via https like this:

pinMode(D5,"output");

D5.set(); // Backlight On

var colorPalette = new Uint16Array([0, 0xF80F, 0x001F, 0xFFFF]);
var spi = new SPI();
spi.setup({mosi:D19 /* sda */, sck:D18 /* scl */});

var g = require("https://espruino.microcosm.app/api/v1/files/a77b4d12f6a3b7587da5a3a70c02dc13ad2a3332.js").connectPaletted(colorPalette, spi, D21 /* DC */, D15 /*CS */, D2 /* RST */, function() {
  g.clear();
  g.setRotation(2);
  g.setColor(1);
  g.drawString("Hello",0,0);
  g.setColor(2);
  g.setFontVector(20);
  g.drawString("TESTING",0,10);
  g.setColor(3);
  g.setFontVector(30);
  g.drawString("TESTING",0,30);
  g.setColor(4);
  g.setFontVector(40);
  g.drawString("TESTING",0,50);
  g.flip();
});

Adjust the pinouts for your setup. I've used it a few times and it seems fine. Gordon was there something you found wrong about it? I noticed it wasn't on the drivers page. Maybe I missed something about it.

The unit I have is labeled SCL and SDA, but as you can see on some forums thats just how its labelled. It is in fact SPI.

Just as an after thought -- the issue might clear up if using a WROOM module with PSRAM. I believe in theory Espruino was updated to support it. The extra memory might be recognized and allocated correctly when doing TLS requests.

HTTPS has been broken for ages no? -- since moving to recent versions of the ESP-IDF. The problem appears to be a lack of available heap memory. Either way there is an open github ticket still for it.

https://github.com/espruino/Espruino/issues/1613

Would be great if it worked -- I'd dig out my ESP32s again.

-hfc

Yeah I got this working finally, so that's good. I've always used qio and dio interchangeably, but on this board dio worked finally. Anyways thanks again! :)

OK good! Thanks for checking that! It might be I just have a board with flakey flash. "storage.compact()" is also not working on it -- triggers a wdt reset -- so that points to flash as well. I'll try a couple of other boards and see what happens.

Cheers,
-=hfc

Hi, I'm just posting this in case anyone else experienced this, but when using v2.04 on some largish code (40K minified down to 20k), I get resets with exccause 3.

ets Jan  8 2013,rst cause:2, boot mode:(3,7)
load 0x40100000, len 2408, room 16
tail 8
chksum 0xe5
load 0x3ffe8000, len 776, room 0
tail 8
chksum 0x84
load 0x3ffe8310, len 632, room 0
tail 8
chksum 0xd8
csum 0xd8
2nd boot version : 1.6
  SPI Speed      : 80MHz
  SPI Mode       : QIO
  SPI Flash Size & Map: 32Mbit(1024KB+1024KB)
jump to run user1 @ 1000
{
  "reason": "exception",
  "exccause": 3, "epc1": 1073799076, "epc2": 0, "epc3": 0, "excvaddr": 1076285788,
  "depc": 0 }
Running onInit()...

This seems to be caused by a LoadStore error -- I found this description to go along with it "Processor internal physical address or data error during load or store".

If I flash back to 2v03, everything is fine. I'm using a totally normal 4MB ESP-12f.

-hfc

Well, finally all our dreams have come true! :)

Great! Thanks :)

Sounds like heap memory is incredibly low! Not sure what the cause of it could be. Did you try downgrading the firmware to 1v97-1v98? These use an earlier version of the Espressif SDK. Maybe could help -- just guessing.

It showed up only recently, but probably is in 1v99 for sure:

http://www.espruino.com/Reference#ESP32

ESP32.enableBLE ⇒

Call type:
ESP32.enableBLE(enable)

Parameters
enable - switches Bluetooth on or off

Description
Switches Bluetooth off/on, removes saved code from Flash, resets the board, and on restart creates jsVars depending on available heap (actual additional 1800)

Note: This is only available in devices with Bluetooth LE capability

Did you turn off bluetooth? It frees up some resources on that version particularly.

ESP32.enableBLE(false)

-=h

Hi -- just curious if support for PSRAM made it in yet. I know there was some discussion of it, but it seemed a bit vague...

These guys are a little cowboy with their IDF, huh?