ESP8266 Community Forum

- Tue May 05, 2015 3:05 am #16524 Yes, I understand that, but my post was really for other developers who may want a temporary fix until the proper bugfix gets merged into the standard build.

Please see my Developer FAQ for Q&A on nodeMCU Lua before asking a question here that's already been answered. This and the other official documentation should be your first reference for developing Lua Apps

- Tue May 05, 2015 6:00 am #16544

Yes, I understand that, but my post was really for other developers who may want a temporary fix until the proper bugfix gets merged into the standard build.

My apologies, I thought the post was directed at me.

Now that I think about it ... I didn't even notice that tmr.stop() doesn't clear the function from RAM.

- Tue May 05, 2015 7:10 am #16548 IMO, this dead function issue with these incorrectly coded event completions is probably one of the larger reasons for uncontrolled memory loss. I can across the timer issue because I often use a timer to simplify sequencing and allow the VM to cleardown after each step, but the end state was still losing memory. So I checked the tmr module code and (like you) discovered this lack of clean up. Replacing a lua function reference with a lightweight (i.e. ROM based) one dereference the Lua code chunk and allows it to be reclaimed.

Please see my Developer FAQ for Q&A on nodeMCU Lua before asking a question here that's already been answered. This and the other official documentation should be your first reference for developing Lua Apps

- Wed May 06, 2015 12:38 pm #16721 Moin,

congratulations to the level of understanding you reached!

Thank you for the quick reply.

As you may have noticed I am not a native speaker. So please correct me when I get non idiomatic.

No problem, aside from you saying "Moin"(hello in german?) I hadn't really noticed that you're not a native speaker. In future posts, to avoid confusion I will try to avoid using region specific vocabulary.

It's a form of the northern german "hello".

Thank you very much for this info, the visualization greatly clarifies how the Lua stack and the push and pop functions work and it also inspired me to do a little bit of experimenting on my own, so I found a function to dump the stack and wrote my own function to get some hands on expierence with the stack and figure out how exactly the stack and stack pointers work:

Great idea!

// Lua: mac = wifi.stack()

Is that the famous wifi stack people are talking about. Didn't know that I could be dumped.

Question: Is creating a reference with luaL_ref() in the LUA_REGISTRYINDEX similar to declaring a global C variable containing the entry from the top of the Lua stack, then returning a pointer to that global var(i.e. "lua_pushnumber(L, 100); global_var=lua_tonumber(L, -1); return &global_var;" ) and is luaL_unref() equivalent to setting the global_var to NULL(i.e. "global_var=NULL;"). would these scenarios correct?

Similiar. But (I think) you can have one instance per lua environment ("L") not per program.

Code: Select allif(wifi_scan_succeed == LUA_NOREF) //if variable "wifi_scan_succeed" contains no reference(lua pointer) then...
    return; // since there is no reference ID, return


Yep. Does that have any meaning on lua application code level?

I'm not sure... maybe it verifies that there exists a reference to the user defined callback function and if that fails it returns because there is nothing to process the args passed onto the C callback function by wifi_station_scan.

Yes, you can say so.

Code: Select all      {
        c_memcpy(ssid, bss_link->ssid, 32); //copy contents of "bss_link->ssid " to "ssid"


Be more precise about the semantics. My apologies, right around this point I started rushing to get the post finished since I had been trying to decipher the source all day and was getting frustrated with it so I started leaving out details. anyway the revised version is "//copy 32 characters from "bss_link->ssid " to "ssid" starting from index 0"
Remember how c strings are defined (especially what defines the length of a c string). String length is determined by the trailing"\0", correct?

Yes.

Look at the definition of ssid.
Why does ssid contain a valid c string after this? It's a valid string because it is only copying 32 chars or less from bss_link->ssid leaving the \0 in index 32 (set by c_memset(ssid, 0, 33)) undisturbed?

Yes.

Code: Select all      }
      c_sprintf(temp,"%d,%d,"MACSTR",%d", bss_link->authmode, bss_link->rssi,
                 MAC2STR(bss_link->bssid),bss_link->channel); // copy "authmode, rssi, bssid, channel" values from variable "bss_link" to variable "temp"


"copy" is too unprecise for me.
Here may be dragons.
Based on the format string and parameters given to the function a new string is generated and written to the buffer
defined by temp.
I typically say "print xxx to buffer temp".
Side note: Can the buffer temp overflow? What would happen if it overflows?

Can it overflow: I Believe not, in fact I think the size of the array could be decreased to 32. since if one were to add all the chars from the resulting string it should equal 32 chars, I could be wrong though.

Why 32? Longest %d should be "-2147483647" = 11 bytes * 3 = 33 + other string chars. Better save than sorry.
If you know even less about your parameters there are safe versions of printf e.g. snprintf to avoid buffer overflows.

What would happen if it overflows: As far as I've read an overflow would cause undefined behavior to occur, which could be: nothing at all, change a different variable, cause a segmentation fault,crash the chip, take your car for a joy ride, etc.

Note that the buffer is on the c stack so that will be damaged.

Code: Select all    }
  }
  else //if "STATUS" NOT EQUAL "OK(0)" then...
  {
    lua_pushnil(gL); //push nil value onto stack for pointer "gL"? not sure what exactly this does... maybe this makes sure that nothing is returned to user in case info is old or non-existent.


Yes. It's an important piece, because when next the call is done which expects one parameter
you have to provide that parameter in some form.

Think about what "gL" is used for. It's just the home for the SP.
Why push nil on the stack if we don't have anything? Why don't just leave the stack unchanged?

I'm drawing a blank on this one... maybe push nil so there is no interference with the function put on the stack by "lua_rawgeti()" when the "wifi_scan_done" function is called again, if indeed it is called again.

No thte the necessary parameter of the callback called in next line.

Code: Select all  }
  lua_call(gL, 1, 0); //calls user's callback function???


Consider the state of the lua stack, the definition (http://pgl.yoyo.org/luai/i/lua_call), explain the parameters to lua_call.
If you are confident what function it is:
What type of parameter does it expect?
Can that help you understand the lua_setfield function?
http://pgl.yoyo.org/luai/i/lua_setfield
What do they mean with "t[k] = v" and how is that translated to the state of the lua stack and the parameters of that function when it is called?

first of all, lua_call(Lua_State, # of args passed to function, # of args returned by function). I believe the parameter it expects is a table since the user's function requires a table. as for the lua_setfield function, after reading the links you gave and I found and read THIS, I believe "lua_setfield(gL, -2, ssid)" takes the string pushed onto the stack by "lua_pushstring(gL, temp)" and creates an entry in the table created by "lua_pushstring(gL, temp)", which now resides at index -2 of the Lua stack, with the string contained within the variable "ssid", then pops the value from the top of the stack.

You got it.

Get your modules here:

https://www.banggood.com/custlink/KvGGhGF4wG