Posted at 2016-09-21 by tve

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.

Posted at 2016-09-21 by Wilberforce

Did you build the sdk from scratch - or use @tve 's tarball used in the Travis file?

I'm doing a build from scratch now to test - will check in the morning...

Posted at 2016-09-21 by Wilberforce

You might need to set the RELEASE=1 so that extra bedbug code does not get added....

Posted at 2016-09-21 by Kolban

Setting RELEASE=1 allowed me to build. I don't know what that means or did or whether that is a permanent change that is required for building.

I built Espruino from the current committed source at the Espruino github repository.
For a compilation environment, I used a Docker image called vowstar/esp8266 (see: https://hub.docker.com/r/vowstar/esp8266/)
I downloaded and installed the SDK 2.0.0 plus Patch1 directly from Espressif.

I'd like to now suggest a discussion topic if I may ...

As I understand it, our common ESP8266s have 1MByte of flash storage. I believe (and I could be wrong here) that our current Espruino builds want to contain our compiled Espruino image to fit within 512K. The reason for this is that the ESP8266s have a technique called "Over The Air" (OTA) flashing ... where one can push a new binary image to an ESP8266 via WiFi. The way this works is to consider an ESP8266 as having "two banks" of 512K instead of one bank of 1024K. At a given time, the ESP8266 runs a program in one bank while the other is unused. Should we wish to reflash an ESP8266, the new program is loaded into the unused bank and ONLY if the transfer completes, will the ESP8266 swap to using the newly loaded bank. If something goes wrong in transfer, we don't end up with a corrupted environment that would (essentially) be a brick.

While this makes absolute sense to me for an industrial/commercial solution which is deployed black box in a consumers house who has no interest or skills in "flashing ESP8266s", I question the need for this in our Espruino project.

If we are starting to over-reach the 512K constraint of an ESP8266 OTA flash size but if we fore-go the ability to use OTA but instead require that the only way to load Espruino onto the ESP8266 is via a serial connection ... I believe that would allow Espruino to grow to 1024K in binary size.

Does this summary sound right?

Would there be interest in providing an Espruino compilation option to allow a build that allowed 1024K images? Is anyone actually using the OTA flashing capability?

I do fully realize that for us developer types, having to upload Espruino via USB/Serial takes time ... for me its about 10-20 seconds as compared to what might be only a few seconds via WiFi.

Posted at 2016-09-21 by tve

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#flash-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.