-
• #2
I think it's possible you could reduce the amount of jsvars available in
boards/ESP8266_BOARD.py
as it may be running out of RAM... -
• #3
I know it works ok with the crypto only.
We don't really want to reduce vars as it means smaller actual code too.
I thought I had tried this option with both libs. Do we offer the option of crypto or graphics - it starts to get quite messy!
-
• #4
You're welcome to try and get them using less RAM - to be honest the Graphics lib really shouldn't be using any at all, so I'm not sure what's going on there.
-
• #5
Did some more testingto see what heap and size of bin is doing:
440132 bytes freeHeap = 8648
with USE_GRAPHICS = 1 457860 bytes freeHeap = 7912 --> 736 bytes for graphics
with USE_CRYPTO = 1 455428 bytes freeHeap = 7288 --> 1360 bytes for crypto
with USE_GRAPHICS = 1 USE_CRYPTO = 1 473172 bytes freeHeap = ??
Taking these numbers graphics and crypto would need 2096 bytes of heap, which is (IMHO) a lot -
• #6
I'm confused as to why graphics needs heap space at all... Am I missing something?
-
• #7
USE_GRAPHICS=1 USE_CRYPTO=1 make
process.memory().total;
=1400require("ESP8266").getState();
={
"sdkVersion": "1.5.0",
"cpuFrequency": 160, "freeHeap": 6144, "maxCon": 10,
"flashMap": "4MB:512/512",
"flashKB": 4096,
"flashChip": "0xe0 0x4016"
}my understanding is that loading more code will reduce the freeHeap
-
• #8
So @MaBe has it compiling? @JumJum, are you sure your code really is the latest from GitHub?
why graphics needs heap space at all...
Because ESP8266 :( All constant data gets stored in RAM unless you explicitly tell it otherwise and change the code that accesses it. It's a bit of a nightmare really.
-
• #9
YES : that's what I did: compile, flash and execute
process.memory().total;
result see above -
• #11
Hmmm, thats strange. I copied latest version form github/espruino/Espruino yesterday.
BTW, I'm testing with ESP8266-01
@MaBe is there any place where I could download your compiled firmware for testing ?
Some more info, I got SDK and xtensa this way:
curl -Ls http://s3.voneicken.com/xtensa-lx106-elf.tgx | tar Jxf -
curl -Ls http://s3.voneicken.com/esp_iot_sdk_v1.5.0.tgx | tar Jxf -
One more info, I only get firmware in espruino/build/espruino... in several binary files, there is no .....512k.bin -
• #12
did you build with
RELEASE=1
? -
• #13
Tried with and without RELEASE=1, both cases the same behaviour
I build it this way:export ESP8266_SDK_ROOT=/home/espruino/git/esp_iot_sdk_v1.5.0 export PATH=$PATH:/home/espruino/git/xtensa-lx106-elf/bin/ export PATH=$PATH:/home/espruino/git/gcc-arm-none-eabi-4_8/bin/ cd git cd Espruino ESP8266_BOARD=1 RELEASE=1 make cd
-
• #14
Maybe try
make clean
first? What you're doing looks fine though.But I just tried a build here, and
USE_GRAPHICS=1 USE_CRYPTO=1
are on by default - and it builds just fine.If they're not on by default then you must have an old version of the source code.
-
• #15
Its running now.
But I have no idea where the problem was.
Could it be a mix of different users, permissions, cleaning up and how/where variables are exported.
Sometimes there are strange results, for example looked like board definition (ESP8266_BOARD=1 in my case) has been lost in the middle of a make. Or size changed between to makes from 473KB to 448KB.
Anyway its running right now on my nodejs server.
I tried to compile actual version from Github and failed.
After flashing system did not start anymore.
At the end it turned out, compiling with
USE_GRAPHICS=1 and USE_CRYPTO=1 is the problem.
One of them USE_GRAPHICS or USE_CRYPTO runs fine, at least Espruino starts fine.
Is there anything, option or whatever which solves this problem ?