Updating to SDK 1.0

[eliabieri]

Are there plans to update this project to SDK 1.0? Whats are the advantages of the new SDK?

[nodemcu]

currently no, there maybe a sdk 1.0 branch, but will not to master recently. the sdk v1.0 uptate, will cause the memory remain(node.heap()) from 21k to 17k.

[nikolz0]

may be connected modules in user script. Let the user selects the required modules for the script. Then the free memory is the maximum.

[nodemcu]

for now it's not possible to do this in script. but only in C header file, and need build.

[nikolz0]

Hi,

This is a test to check the write in the files:

s1="234567890qwertyuiop[]asdfghjkl;'zxcvbnm,.qwertyuiop[asdfghjkl;qwertyuiop[" for j=1,40 do l = file.list(); for k,v in pairs(l) do print("name:"..k..", size:"..v) end s="tfq"..j..".txt" file.open(s,"w+"); for i=1,1000 do tmr.wdclr(); file.write(s1); end file.close(); end l = file.list(); for k,v in pairs(l) do print("name:"..k..", size:"..v) end print("end"); ------------------------------------- As a result, got the error:

name:tf.lua, size:401 name:tfq8.txt, size:73000 name:tfq6.txt, size:73000 name:tfq4.txt, size:73000 name:tfq11.txt, size:73000 name:tfq10.txt, size:73000 name:tfq17.txt, size:73000 name:tfq19.txt, size:73000 name:tfq13.txt, size:73000 name:tfq18.txt, size:73000 name:tfq15.txt, size:73000 name:tfq7.txt, size:73000 name:tfq1.txt, size:73000 name:tfq21.txt, size:73000 name:tfq20.txt, size:73000 name:tfq16.txt, size:73000 H!ЦФфЉб(

NodeMCU 0.9.5 build 20150318 powered by Lua 5.1.4

Total : 3426401 bytes Used : 1598619 bytes

Remain: 1827782 bytes

After this we have to format ----------------------------------------- This Dev kit, flash memory 4 MB.

Regards, NK

Вторник, 24 марта 2015, 4:16 -07:00 от zeroday notifications@github.com:

for now it's not possible to do this in script. but only in C header file, and need build. — Reply to this email directly or view it on GitHub .

[vowstar]

Confirmed, this is file system bug. We will fix it.

[eyaleb]

As a data point: I am using v1.0.0 (and then b1) since released and it seems OK so far. As for the need to rebuild to remove unused modules, this is what I do. It takes only a few seconds to rebuild (mostly only the final link is done) and then I flash the new bins. The whole cycle is a minute or two.

Naturally, once I had my fingers in the code I started manipulating it to my liking, like adding functions to access the RTC memory (great for dsleep loops).

Also, anyone here knows how difficult it is to squeeze a program into the very little RAM we have, so I plan to move most of the lower level logic of my programs into the C part. I would not be surprised if final commissioned code will be just an SDK app (without lua). Though lua is very nice for development.

[stefan73]

There is now evidence that SDK 1.0.0 brings a very relevant bug fix. The firmware below 1.0.0 is facing severe WLAN disconnect issues. Using my own FW I can see up too 300 dis-/reconnects per day. I guess 4k of heap would be a deal for this bugfix.

[nikolz0]

Hi, I found nodeMCU the following errors: The files adc.c, coap.c, CJSON.c, GPIO.c, I2C.c, mqtt.c, net.c, node.c, ow.c, pwm.c, spi.c, tmr.c, u8g.c, uart.c, wifi.c instead luaL_register must apply LREGISTER, as is done in bit.c, ws2812.c

The files lmathlib.s, LOADLIB.c, lstrlib.c instead luaL_register must apply LREGISTER, as is done in ltablib.c

Eliminating these errors imenshit allow the required amount of heap for LUA.

[eyaleb]

I should correct my earlier comment that "I am using v1.0.0". I now suspect that linking against a newer SDK does not fully use it. Some SDK material seems to be included in the nodemcu-firmware repository (most of lib/*.a are from SDK v0.9.5).

I confirmed that system_rtc_mem_read/write() is buggy in 0.9.5, but good in the 1.0 series. We really should move forward.

[raz123]

@nikolz0, have you actually tried compiling with the modifications that you are suggesting? If so, what was the impact on the heap?

[nikolz0]

I did not do the assembly nodemcu with these changes. I just compared the code with the original elua Perhaps this will increase the heap at 0.5-1 K. Now the minimum allowable value is roughly 6.5 and according to the developers elua should be 5.5.

[raz123]

@nikolz0, I have reviewed your suggestion and compared it to the existing code along with the guide present on this page: http://www.eluaproject.net/doc/v0.9/en_arch_ltr.html

My conclusion is that the way NodeMCU does things is acceptable. Let me explain: there seems to be two ways to go about declaring modules.

A. The traditional way:

LUALIB_API int luaopen_mod( lua_State *L )
{
  luaL_register( L, "mod", mod_map );
  return 1;
}

B. The LTR (Lua Tiny RAM) way:

LUALIB_API int luaopen_mod( lua_State *L )
{
  return 0;
}

While A ensures compatibility, B is used for maximum ram optimization. To see which method to compile, NodeMCU mostly looks at the LUA_OPTIMIZE_MEMORY flag, likeso:

LUALIB_API int luaopen_mod( lua_State *L )
{
#if LUA_OPTIMIZE_MEMORY > 0
  return 0;
#else // #if LUA_OPTIMIZE_MEMORY > 0
  luaL_register( L, "mod", mod_map );
  return 1;
#endif // #if LUA_OPTIMIZE_MEMORY > 0  
}

That being said, the LTR patch that is included in the code base allows one to avoid this check by simply doing the following, which takes care of both cases (optimization enabled or not):

LUALIB_API int luaopen_mod( lua_State *L )
{
  LREGISTER( L, "mod", mod_map ); // note: no more luaL_register, no "return 1"
}

The latter, however, appears a bit less efficient to me. Nevertheless, it is used in some modules such as bit.c, ws2812.c, as you correctly listed.

[jmattsson]

The dev branch has now been upgraded to 1.4.0. Closing this issue.