Search results for:

I like to save code to Storage and than require it, this save a big amount of vars.

@MaBe, can you explain the advantages of your scheme over what I'm using? It's quite a bit of additional work.

It is actually linked quite a bit (FAQ,Troubleshooting,Quick start, etc). But where did you look where it wasn't mentioned and I'll get a link added.

Hmmm, my bad. I could swear that typing 'saving' into the search box brought up nothing, but now it does, so I must have been too tired to see it or something... I mainly looked around in the tips&tricks, tutorials, modules, and esp8266 pages.

After being away for a year it's nice to see all the progress on Espruino!

I did struggle for quite some time to update my stuff and to get my code working again under V2.01, so I thought I'd write up a quick how-to so I remember the next time I try to do something :-) Maybe it also helps someone else 'cause very little of this is spelled out anywhere that I could find (the best info is at http://www.espruino.com/Saving but that page is not linked to from any other page on http://www.espruino.com!)

Requirements:

• I have a bunch of apps that are fairly large and must run from flash.
  
• I use local modules.
  
• The apps must run auto-run at boot time.
  
• I prefer CLI over the IDE.
  
  

I couldn't do an OTA update from pre-V2 of Espruino to V2.x due to a changed flash layout (512 vs 1024KB partitions). I have esp-12e modules with 4MB flash, so I installed the official espressif tool https://github.com/espressif/esptool/ and flashed using:

esptool -p /dev/ttyUSB0 write_flash --flash_size 4MB-c1 --flash_mode qio 0 espruino_2v01_esp8266_4mb_combined_4096.­bin

In the IDE I had to set the options SAVE_TO_FLASH to 1 and MODULE_AS_FUNCTION to true. But I don't want to use the IDE...

So I installed the espruino cli:

• Install node.js version 8 (old!), I'm using Linux and untarred the binary archive from the node.js site in /home/sw/node-v8 (non-std location, use any dir you like)
  
• Install espruino using /home/sw/node-v8/bin/npm install espruino
  
  

In order to ensure that I can run the cli using node-v8, I created a little shell script I call espruino-v8:

    #! /bin/bash
export NODEJS_HOME=/home/sw/node-v8/bin
export PATH=$NODEJS_HOME:$PATH
espruino --no-ble --config SAVE_ON_SEND=1 --config MODULE_AS_FUNCTION=true "$@"

To flash an application I have the main file in a projects subdirectory and the modules in a modules subdirectory. I simply require(...) the module in the main file. The flashing command is:

./expruino-v8 -p tcp://esp8266.local:23 -w -m projects/foo.js

The -w option means that espruino stays connected and shows me the console output.

The application uses an onInit() to start and that gets invoked automatically at the end of the upload.

You can use the main UART to attach a peripheral, but it's somewhat tricky. You will get stuff printed on it at boot, so your periph better be able to ignore that. My onInit() function when using a nextion display attached to uart0 contains:

  // change logging so we don't clobber the nextion display on uart0
  esp8266.setLog(3); // log to memory and 2:uart0 3:uart1
  console.log("Bye bye...");
  Serial2.setConsole(false)

The way I use it is to upload the code using telnet, so I see the "Bye bye..." printed via telnet when I run onInit() manually. By setting Serial2 as console the characters get dropped. By not forcing the console to stick to Serial2 I can telnet into the espruino at any time and have the console back. This has worked quite well for me.

Make sure you turn the debug output off. esp8266.setLog(0) or esp8266.logDebug(false)
I use an MCP23008 just fine, but not on gpio0 or gpio2...

dump ends up writing to the UART non-stop at whatever rate the UART cranks stuff out until the WDT hits and then the esp resets. If you can increase the baud rate you may get more.
Unfortunately there is no easy fix.

Mhh, I think some guy on the internet wrote a free book on the esp8266, I think he goes by 'nkolban', you should take a look at his book ;-)
The esp-01 modules have 512KB flash. The flash layout is described in https://github.com/espruino/EspruinoDocs­/blob/master/boards/EspruinoESP8266.md#f­lash-map-and-access as far as I can tell, people, especially beginners are still using these routinely.
On larger modules we could use 1MB. On modules 2MB and up there's a layout that supports OTA with 1MB partitions. This is all described in Espressif's "user guide" or "OTA guide". But it's not just a matter of flipping a switch, there are a whole bunch of places that need changes, so to use that someone would really have to roll up their sleeves and make all the changes and get them reviewed.

Good question, how does your output differ from the travis build? iram1_0_seg I believe is the 32KB of static instruction ram. They actually freed up some space there with SDK2 so I wonder what's going wrong for you. Nothing has changed in that area in Espruino in a while.

Yup, looks like there is a bug when the save size is too big. You are correct about the 3x 4KB pages.

The layout difference between 512KB and greater flash chips is only one 4KB sector, so just ditching 512KB support doesn't instantaneously fix the issue. Someone still has to go through and work out an alternate flash layout and then make all the code and documentation changes. I still see new folks start with esp-01 modules, FWIW.

I'm glad you got it sorted out :-)

No, it had to drop because it never fit. It was in the previous build because someone just changed the max size in the makefile without considering whether there actually is space. So code overlapped the eeprom flash area and other stuff.

I'm running the following code on a string of 8 neopixels. It walks a rainbow of colors. Not seeing any oddity.

var array = [255,255,255, 255,0,0, 0,255,0, 0,0,255, 127,127,127, 0,255,255, 255,0,255, 255,255,0];
function walk() {
  esp.neopixelWrite(D5,array);
  array.push(array.shift());
  array.push(array.shift());
  array.push(array.shift());
}

var esp = require("ESP8266");
pinMode(D5,'output');

setInterval(walk, 500);

can you post what save() prints? there is a marker at the end of the save area IIRC and perhaps the calculation is incorrect and it overwrites it.

Well, maybe the cut-out isn't the biggest improvement. See http://www.espressif.com/sites/default/f­iles/esp-wroom-02_pcb_design_and_module_­placement_guide.pdf page 3 if interested

I created a fresh build using everything in v1.87 plus the latest Espressif SDK v2.0.0 with the latest patch. This build has crypto support but not graphics. Both just don't fit into flash :-(. The esp8266 runs at 160Mhz and Espruino gets 1700 jsvars. The free heap comes out to ~8KB and the build uses lwip_536 so packet buffers aren't as big as they would be otherwise.

I have not done extensive testing, please let me know if I botched something. You can download the build from http://www.espruino.com/binaries/travis/­b3dc05b5378a9182eea44e8c47b15c54e788037d­/espruino_1v87.tve_master_b3dc05b_esp826­6.tgz and I opened a PR for Gordon https://github.com/espruino/Espruino/pul­l/925

If you're compiling using the SDK that comes with the open_sdk toolchain you're gonna have fun... Install the open_sdk without SDK and get & patch the SDK separately. You can also have it simpler by following what in the .travis.yaml file manually...

$(Q)COMPILE=gcc python $(APPGEN_TOOL) expands the $(Q) to an @ if you have verbose off, and COMPILE=gcc is an environment variable that gets set for the python command. The APPGEN_TOOL is a pythoon script that comes with the Espressif SDK and that creates the binary images.

FYI, if you ever do another rev, you might want to consider a cut-out in the PCB above the antenna. It makes a difference. Espressif has a pretty good app note about the antenna stuff with test results and the cut out performs better.

Assuming that the esp8266 and the bootloader support that size flash, then:

0xFFFF00* esp_init_data_default.bin 0xFFFF00* blank.bin

that should be 0xFFC000 esp_init_data_default.bin 0xFFE000 blank.bin

There is no harm in you programming it for a smaller size to test and work your way up.

Interesting! I'm not convinced I want to add docker to my odroid set-ups, but I've thought about it. This is the best article I've seen in terms of explaining how to get docker, thanks!

The current code operates at a little over 300khz, which is quite close to the 400khz max of many devices. It was significantly optimized from the espressif code and all the inner loops were pretty much rewritten. IIRC I tried to make it as fast as I could without exceeding 400khz and still leaving some dials in there to easily turn the speed down to 100khz.

x = {"a":3};
if (x.a) 4; else 5;

run in node.js:

> x = {"a":3};
{ a: 3 }
> if (x.a) 4; else 5;
4
>

run in espruino:

>x = {"a":3};
={ "a": 3 }
>if (x.a) 4; else 5;
=undefined
>

similarly if (x.b) 4; else 5; returns 5 in node.js and undefined in Espruino.

I think the other issue with STM32 platforms is that most of flash has very large pages IIRC and thus my simple scheme where I store one module in one string in flash isn't viable.

A lot of brainpower has been invested in software testing over the past years. Developing software is very different today from a few years ago, IMHO.

What I like about node-red is that for relatively simple things one can compose visually and that can provide a nice overall overview and structure to what ends up being a bit of a distributed application. It's not a place to do the coding, but one to glue things together and establish the overall flow of events & data. In particular for beginners it's nice environment to try things out quickly.

ESP8266.logDebug() and/or ESP8266.setLog() ?

"Don't you know that life has moved to the cloud? What are you dicking around with I/O for?"