Upgrade dev120 branch to dev130

[3dot3]

SDK1.30 has some bug fixed for Wifi. Shall dev120 replaced by it?

[TerryE]

I've been going through the issues, and it strikes me that we have had a few more modules released, and there are some nice functional enhancements in or on the way in the firmware core:

• @jmattsson Johny's exception handler to allow us to move const char data into the firmware
• @marcelstoer Marcel's cloud build service
• @TerryE my unofficial FAQ, my luac.cross and my stripdebug patch (last one still awaiting feedback before being released)

But the major gap is that our "current" builds are over an SDK version that is over 6 months old and the current SDK 1.3 fixes a lot of bugs particularly in the TCP stack, so we should really rebaseline the firmware over a current SDK version ASAP. My issue is how do we move this forward and get this done? It'd start working with the dev120 branch and work some of its know issues, but I don't want to cut across anything that zeroday and the other guys in China are working on.

[jmattsson]

Something worth noting is that Espressif released an open source LWIP for sdk 1.3.0: http://bbs.espressif.com/viewtopic.php?f=46&t=951
I'd love to see NodeMCU skip straight to 1.3.0, but I don't have any time to spend on making that happen any time soon, alas.

[TerryE]

I've just rebuild my dev120 for SDK 1.3 and will be looking at some of the memory issues. One thing that is a real pain with the nodemcu build setup is that this forks and makes minor changes to the standard SDK include files for no clear reason. This causes unnecessary regression problems when upgrading SDKs. It would be a lot simpler if the nodemcu build was properly layered on top of the SDK -- that is any additions were in nodemcu-specific files and that the SDK code was left unchanged.

[grahamehorner]

@TerryE I've just started looking at the ESP8266 and NodeMCU; but I would be happy to help with any testing of work on moving to the new SDK.

[grahamehorner]

BTW, I'm looking at creating a set of modules that will allow cloud connectivity to things like Azure blob,table,queue and service bus features.

[TerryE]

Grahame, I see that you do a lot of c# development. How are your old fashioned C skills? Have a look at some of the references in my Unofficial FAQ. If you want to start to get to grips with Lua then the best way is doing some basic builds in a *nix environment. I run Ubuntu 64bit on my laptops, but I still do my nodeMCU stuff in a VM (running 32bit Ubuntu headless server on 14.04-1 LTS). Buy the PiL book, and have a go at doing a small extension. The ELF issues around working in a memory constrained embedded device just add an entire layer of complexity, if you haven't worked on this type of system before, so it's better to take this in chunks.

Drop me an email at my ellisons domain in .org.uk; just drop the E off my username and we can discuss further.

[grahamehorner]

@TerryE Yes, I do a lot of .NET C# development, however I start life as a developer using Lattice C & ASM6800 on the Atari ST & Amiga many moons ago doing; then moving onto the PC x86 C/C++ and beyond ;) My old style Ansii C/C++ skills may be a little rusty but these are re-surfacing as I'm doing a lot of multiplatform bridging code for .NET at present. I have a number of development platforms including Ubuntu 14.04 on the Raspberry PI v2 and pcDuino v3b and running under hyper-v

[rxf992]

days ago I have ported dev130 myself but not really tested yet.
https://github.com/rxf992/nodemcu-firmware/tree/dev130

[TerryE]

I've been looking at the duplicate symbols in the firmware and the boot ROM. There's a lot and some of them are avoidable; some not. There this thread esp8266.com - Reducing firmware code size by using more ROM symbols which was started by @cal101, and which gives a lot of useful background. Essentially the bootrom was compiled with an older version the gcc and the floating point routines aren't quite compatible. Victor, @pvvx, claims to have a working cut down version, but I think that I'll start with the ones that don't conflict like ensuring everything uses the c_strXXX variants which are ROM based and are compatible (except that c_stdio.c doesn't obey its own rules and for example uses strlen() instead of c_strlen())!

[TerryE]

Well I have a floating point version that is working (based on some minimal testing) on an ESP-01 with a minimum library set:

> =node.restart()
> ���p�zH         �z�Zf��S
NodeMCU 1.3.0 build 20150714  powered by Lua 5.1.4
lua: cannot open init.lua
> =node.heap()
41432
> =file.fsinfo()
48945   4016    52961
> 

I had to do some macro magic to remove some of the routines duplicated in the bootROM and the 0x40100000 segment, but at least according to objdump I've got 712 bytes free in .text rather than 20.

More to do. The 48K left in SPIFS / .irom0.text is a concern -- at least fro the 512Kb parts. Add a couple more modules and we won't have any room for a minimal application!

I will have to try an integer build

[eku]

FYI: SDK 1.4.0 is out http://bbs.espressif.com/viewtopic.php?p=3756#p3756
See also pfalcon/esp-open-sdk#91
I suggest to skip 1.3.0.

[eku]

Just to let you know that the toolchain has been updated to SDK 1.4.0 pfalcon/esp-open-sdk@2df0123

[3dot3]

Dev 140 sloved memory leaking issue and less bugs than dev 120. It is best branch for me so far. Thank guys.

[TerryE]

I will be deleting dev120 tomorrow unless any of the committers objects.