Add note about init.lua (#1353)
This commit is contained in:
Marcel Stör
Arnim Läuger
parent
244c6e9db1
commit
b47a56de7a
|
|
@ -14,14 +14,14 @@ This FAQ does not aim to help you to learn to program or even how to program in
|
||||||
|
|
||||||
The NodeMCU firmware implements Lua 5.1 over the Espressif SDK for its ESP8266 SoC and the IoT modules based on this.
|
The NodeMCU firmware implements Lua 5.1 over the Espressif SDK for its ESP8266 SoC and the IoT modules based on this.
|
||||||
|
|
||||||
* The official lua.org **[Lua Language specification](http://www.lua.org/manual/5.1/manual.html)** gives a terse but complete language specification.
|
* The official lua.org **[Lua Language specification](http://www.lua.org/manual/5.1/manual.html)** gives a terse but complete language specification.
|
||||||
* Its [FAQ](http://www.lua.org/faq.html) provides information on Lua availability and licensing issues.
|
* Its [FAQ](http://www.lua.org/faq.html) provides information on Lua availability and licensing issues.
|
||||||
* The **[unofficial Lua FAQ](http://www.luafaq.org/)** provides a lot of useful Q and A content, and is extremely useful for those learning Lua as a second language.
|
* The **[unofficial Lua FAQ](http://www.luafaq.org/)** provides a lot of useful Q and A content, and is extremely useful for those learning Lua as a second language.
|
||||||
* The [Lua User's Wiki](http://lua-users.org/wiki/) gives useful example source and relevant discussion. In particular, its [Lua Learning Lua](http://lua-users.org/wiki/Learning) section is a good place to start learning Lua.
|
* The [Lua User's Wiki](http://lua-users.org/wiki/) gives useful example source and relevant discussion. In particular, its [Lua Learning Lua](http://lua-users.org/wiki/Learning) section is a good place to start learning Lua.
|
||||||
* The best book to learn Lua is *Programming in Lua* by Roberto Ierusalimschy, one of the creators of Lua. It's first edition is available free [online](http://www.lua.org/pil/contents.html) . The second edition was aimed at Lua 5.1, but is out of print. The third edition is still in print and available in paperback. It contains a lot more material and clearly identifies Lua 5.1 vs Lua 5.2 differences. **This third edition is widely available for purchase and probably the best value for money**. References of the format [PiL **n.m**] refer to section **n.m** in this edition.
|
* The best book to learn Lua is *Programming in Lua* by Roberto Ierusalimschy, one of the creators of Lua. It's first edition is available free [online](http://www.lua.org/pil/contents.html) . The second edition was aimed at Lua 5.1, but is out of print. The third edition is still in print and available in paperback. It contains a lot more material and clearly identifies Lua 5.1 vs Lua 5.2 differences. **This third edition is widely available for purchase and probably the best value for money**. References of the format [PiL **n.m**] refer to section **n.m** in this edition.
|
||||||
* The Espressif ESP8266 architecture is closed source, but the Espressif SDK itself is continually being updated so the best way to get the documentation for this is to [google Espressif IoT SDK Programming Guide](https://www.google.co.uk/search?q=Espressif+IoT+SDK+Programming+Guide) or to look at the Espressif [downloads forum](http://bbs.espressif.com/viewforum.php?f=5) .
|
* The Espressif ESP8266 architecture is closed source, but the Espressif SDK itself is continually being updated so the best way to get the documentation for this is to [google Espressif IoT SDK Programming Guide](https://www.google.co.uk/search?q=Espressif+IoT+SDK+Programming+Guide) or to look at the Espressif [downloads forum](http://bbs.espressif.com/viewforum.php?f=5) .
|
||||||
* The **[NodeMCU documentation](http://www.NodeMCU.com/docs/)** is available online. However, please remember that the development team are based in China, and English is a second language, so the documentation needs expanding and be could improved with technical proofing.
|
* The **[NodeMCU documentation](http://www.NodeMCU.com/docs/)** is available online. However, please remember that the development team are based in China, and English is a second language, so the documentation needs expanding and be could improved with technical proofing.
|
||||||
* As with all Open Source projects the source for the NodeMCU firmware is openly available on the [GitHub NodeMCU-firmware](https://github.com/NodeMCU/NodeMCU-firmware) repository.
|
* As with all Open Source projects the source for the NodeMCU firmware is openly available on the [GitHub NodeMCU-firmware](https://github.com/NodeMCU/NodeMCU-firmware) repository.
|
||||||
|
|
||||||
### How is NodeMCU Lua different to standard Lua?
|
### How is NodeMCU Lua different to standard Lua?
|
||||||
|
|
||||||
|
|
@ -41,46 +41,47 @@ The NodeMCU libraries act as C wrappers around registered Lua callback functions
|
||||||
|
|
||||||
### How is coding for the ESP8266 the same as standard Lua?
|
### How is coding for the ESP8266 the same as standard Lua?
|
||||||
|
|
||||||
* This is a fully featured Lua 5.1 implementation so all standard Lua language constructs and data types work.
|
* This is a fully featured Lua 5.1 implementation so all standard Lua language constructs and data types work.
|
||||||
* The main standard Lua libraries -- `core`, `coroutine`, `string` and `table` are implemented.
|
* The main standard Lua libraries -- `core`, `coroutine`, `string` and `table` are implemented.
|
||||||
|
|
||||||
### How is coding for the ESP8266 different to standard Lua?
|
### How is coding for the ESP8266 different to standard Lua?
|
||||||
|
|
||||||
* The ESP8266 use onchip RAM and offchip Flash memory connected using a dedicated SPI interface. Both of these are *very* limited (when compared to systems than most application programmer use). The SDK and the Lua firmware already use the majority of this resource: the later build versions keep adding useful functionality, and unfortunately at an increased RAM and Flash cost, so depending on the build version and the number of modules installed the runtime can have as little as 17KB RAM and 40KB Flash available at an application level. This Flash memory is formatted an made available as a **SPI Flash File System (SPIFFS)** through the `file` library.
|
* The ESP8266 use onchip RAM and offchip Flash memory connected using a dedicated SPI interface. Both of these are *very* limited (when compared to systems than most application programmer use). The SDK and the Lua firmware already use the majority of this resource: the later build versions keep adding useful functionality, and unfortunately at an increased RAM and Flash cost, so depending on the build version and the number of modules installed the runtime can have as little as 17KB RAM and 40KB Flash available at an application level. This Flash memory is formatted an made available as a **SPI Flash File System (SPIFFS)** through the `file` library.
|
||||||
* However, if you choose to use a custom build, for example one which uses integer arithmetic instead of floating point, and which omits libraries that aren't needed for your application, then this can help a lot doubling these available resources. (See Marcel Stör's excellent [custom build tool](http://frightanic.com/NodeMCU-custom-build/) that he discusses in [this forum topic](http://www.esp8266.com/viewtopic.php?f=23&t=3001)). Even so, those developers who are used to dealing in MB or GB of RAM and file systems can easily run out of these resources. Some of the techniques discussed below can go a long way to mitigate this issue.
|
* However, if you choose to use a custom build, for example one which uses integer arithmetic instead of floating point, and which omits libraries that aren't needed for your application, then this can help a lot doubling these available resources. (See Marcel Stör's excellent [custom build tool](http://nodemcu-build.com) that he discusses in [this forum topic](http://www.esp8266.com/viewtopic.php?f=23&t=3001)). Even so, those developers who are used to dealing in MB or GB of RAM and file systems can easily run out of these resources. Some of the techniques discussed below can go a long way to mitigate this issue.
|
||||||
* Current versions of the ESP8266 run the SDK over the native hardware so there is no underlying operating system to capture errors and to provide graceful failure modes, so system or application errors can easily "PANIC" the system causing it to reboot. Error handling has been kept simple to save on the limited code space, and this exacerbates this tendency. Running out of a system resource such as RAM will invariably cause a messy failure and system reboot.
|
* Current versions of the ESP8266 run the SDK over the native hardware so there is no underlying operating system to capture errors and to provide graceful failure modes, so system or application errors can easily "PANIC" the system causing it to reboot. Error handling has been kept simple to save on the limited code space, and this exacerbates this tendency. Running out of a system resource such as RAM will invariably cause a messy failure and system reboot.
|
||||||
* There is currently no `debug` library support. So you have to use 1980s-style "binary-chop" to locate errors and use print statement diagnostics though the systems UART interface. (This omission was largely because of the Flash memory footprint of this library, but there is no reason in principle why we couldn't make this library available in the near future as an custom build option).
|
* There is currently no `debug` library support. So you have to use 1980s-style "binary-chop" to locate errors and use print statement diagnostics though the systems UART interface. (This omission was largely because of the Flash memory footprint of this library, but there is no reason in principle why we couldn't make this library available in the near future as an custom build option).
|
||||||
* The LTR implementation means that you can't easily extend standard libraries as you can in normal Lua, so for example an attempt to define `function table.pack()` will cause a runtime error because you can't write to the global `table`. (Yes, there are standard sand-boxing techniques to achieve the same effect by using metatable based inheritance, but if you try to use this type of approach within a real application, then you will find that you run out of RAM before you implement anything useful.)
|
* The LTR implementation means that you can't easily extend standard libraries as you can in normal Lua, so for example an attempt to define `function table.pack()` will cause a runtime error because you can't write to the global `table`. (Yes, there are standard sand-boxing techniques to achieve the same effect by using metatable based inheritance, but if you try to use this type of approach within a real application, then you will find that you run out of RAM before you implement anything useful.)
|
||||||
* There are standard libraries to provide access to the various hardware options supported by the hardware: WiFi, GPIO, One-wire, I²C, SPI, ADC, PWM, UART, etc.
|
* There are standard libraries to provide access to the various hardware options supported by the hardware: WiFi, GPIO, One-wire, I²C, SPI, ADC, PWM, UART, etc.
|
||||||
* The runtime system runs in interactive-mode. In this mode it first executes any `init.lua` script. It then "listens" to the serial port for input Lua chunks, and executes them once syntactically complete. There is no `luac` or batch support, although automated embedded processing is normally achieved by setting up the necessary event triggers in the `init.lua` script.
|
* The runtime system runs in interactive-mode. In this mode it first executes any `init.lua` script. It then "listens" to the serial port for input Lua chunks, and executes them once syntactically complete. There is no `luac` or batch support, although automated embedded processing is normally achieved by setting up the necessary event triggers in the `init.lua` script.
|
||||||
* The various libraries (`net`, `tmr`, `wifi`, etc.) use the SDK callback mechanism to bind Lua processing to individual events (for example a timer alarm firing). Developers should make full use of these events to keep Lua execution sequences short. *If any individual task takes too long to execute then other queued tasks can time-out and bad things start to happen.*
|
* The various libraries (`net`, `tmr`, `wifi`, etc.) use the SDK callback mechanism to bind Lua processing to individual events (for example a timer alarm firing). Developers should make full use of these events to keep Lua execution sequences short. *If any individual task takes too long to execute then other queued tasks can time-out and bad things start to happen.*
|
||||||
* Non-Lua processing (e.g. network functions) will usually only take place once the current Lua chunk has completed execution. So any network calls should be viewed at an asynchronous request. A common coding mistake is to assume that they are synchronous, that is if two `socket:send()` are on consecutive lines in a Lua programme, then the first has completed by the time the second is executed. This is wrong. Each `socket:send()` request simply queues the send operation for dispatch. Neither will start to process until the Lua code has return to is calling C function. Stacking up such requests in a single Lua task function burns scarce RAM and can trigger a PANIC. This true for timer, network, and other callbacks. It is even the case for actions such as requesting a system restart, as can be seen by the following example:
|
* Non-Lua processing (e.g. network functions) will usually only take place once the current Lua chunk has completed execution. So any network calls should be viewed at an asynchronous request. A common coding mistake is to assume that they are synchronous, that is if two `socket:send()` are on consecutive lines in a Lua programme, then the first has completed by the time the second is executed. This is wrong. Each `socket:send()` request simply queues the send operation for dispatch. Neither will start to process until the Lua code has return to is calling C function. Stacking up such requests in a single Lua task function burns scarce RAM and can trigger a PANIC. This true for timer, network, and other callbacks. It is even the case for actions such as requesting a system restart, as can be seen by the following example:
|
||||||
|
|
||||||
```lua
|
```lua
|
||||||
node.restart(); for i = 1, 20 do print("not quite yet -- ",i); end
|
node.restart(); for i = 1, 20 do print("not quite yet -- ",i); end
|
||||||
```
|
```
|
||||||
* You therefore *have* to implement ESP8266 Lua applications using an event driven approach. You have to understand which SDK API requests schedule asynchronous processing, and which define event actions through Lua callbacks. Yes, such an event-driven approach makes it difficult to develop procedurally structured applications, but it is well suited to developing the sorts of application that you will typically want to implement on an IoT device.
|
|
||||||
|
* You therefore *have* to implement ESP8266 Lua applications using an event driven approach. You have to understand which SDK API requests schedule asynchronous processing, and which define event actions through Lua callbacks. Yes, such an event-driven approach makes it difficult to develop procedurally structured applications, but it is well suited to developing the sorts of application that you will typically want to implement on an IoT device.
|
||||||
|
|
||||||
### So how does the SDK event / tasking system work in Lua?
|
### So how does the SDK event / tasking system work in Lua?
|
||||||
|
|
||||||
* The SDK employs an event-driven and task-oriented architecture for programming at an applications level.
|
* The SDK employs an event-driven and task-oriented architecture for programming at an applications level.
|
||||||
* The SDK uses a startup hook `void user_init(void)`, defined by convention in the C module `user_main.c`, which it invokes on boot. The `user_init()` function can be used to do any initialisation required and to call the necessary timer alarms or other SDK API calls to bind and callback routines to implement the tasks needed in response to any system events.
|
* The SDK uses a startup hook `void user_init(void)`, defined by convention in the C module `user_main.c`, which it invokes on boot. The `user_init()` function can be used to do any initialisation required and to call the necessary timer alarms or other SDK API calls to bind and callback routines to implement the tasks needed in response to any system events.
|
||||||
* The API provides a set of functions for declaring application functions (written in C) as callbacks to associate application tasks with specific hardware and timer events. These are non-preemptive at an applications level.
|
* The API provides a set of functions for declaring application functions (written in C) as callbacks to associate application tasks with specific hardware and timer events. These are non-preemptive at an applications level.
|
||||||
* Whilst the SDK provides a number of interrupt driven device drivers, the hardware architecture severely limits the memory available for these drivers, so writing new device drivers is not a viable options for most developers
|
* Whilst the SDK provides a number of interrupt driven device drivers, the hardware architecture severely limits the memory available for these drivers, so writing new device drivers is not a viable options for most developers
|
||||||
* The SDK interfaces internally with hardware and device drivers to queue pending events.
|
* The SDK interfaces internally with hardware and device drivers to queue pending events.
|
||||||
* The registered callback routines are invoked sequentially with the associated C task running to completion uninterrupted.
|
* The registered callback routines are invoked sequentially with the associated C task running to completion uninterrupted.
|
||||||
* In the case of Lua, these C tasks are typically functions within the Lua runtime library code and these typically act as C wrappers around the corresponding developer-provided Lua callback functions. An example here is the Lua `tmr.alarm(id, interval, repeat, callback)` function. The calls a function in the `tmr` library which registers a C function for this alarm using the SDK, and when this C function is called it then invokes the Lua callback.
|
* In the case of Lua, these C tasks are typically functions within the Lua runtime library code and these typically act as C wrappers around the corresponding developer-provided Lua callback functions. An example here is the Lua `tmr.alarm(id, interval, repeat, callback)` function. The calls a function in the `tmr` library which registers a C function for this alarm using the SDK, and when this C function is called it then invokes the Lua callback.
|
||||||
|
|
||||||
The NodeMCU firmware simply mirrors this structure at a Lua scripting level:
|
The NodeMCU firmware simply mirrors this structure at a Lua scripting level:
|
||||||
* A startup module `init.lua` is invoked on boot. This function module can be used to do any initialisation required and to call the necessary timer alarms or libary calls to bind and callback routines to implement the tasks needed in response to any system events.
|
|
||||||
* The Lua libraries provide a set of functions for declaring application functions (written in Lua) as callbacks (which are stored in the [Lua registry](#so-how-is-the-lua-registry-used-and-why-is-this-important)) to associate application tasks with specific hardware and timer events. These are non-preemptive at an applications level.
|
* A startup module `init.lua` is invoked on boot. This function module can be used to do any initialisation required and to call the necessary timer alarms or library calls to bind and callback routines to implement the tasks needed in response to any system events.
|
||||||
* The Lua libraries work in consort with the SDK to queue pending events and invoke any registered Lua callback routines, which then run to completion uninterrupted.
|
* The Lua libraries provide a set of functions for declaring application functions (written in Lua) as callbacks (which are stored in the [Lua registry](#so-how-is-the-lua-registry-used-and-why-is-this-important)) to associate application tasks with specific hardware and timer events. These are non-preemptive at an applications level* The Lua libraries work in consort with the SDK to queue pending events and invoke any registered Lua callback routines, which then run to completion uninterrupted.
|
||||||
* Excessively long-running Lua functions can therefore cause other system functions and services to timeout, or allocate memory to buffer queued data, which can then trigger either the watchdog timer or memory exhaustion, both of which will ultimately cause the system to reboot.
|
* Excessively long-running Lua functions can therefore cause other system functions and services to timeout, or allocate memory to buffer queued data, which can then trigger either the watchdog timer or memory exhaustion, both of which will ultimately cause the system to reboot.
|
||||||
* By default, the Lua runtime also 'listens' to UART 0, the serial port, in interactive mode and will execute any Lua commands input through this serial port.
|
* By default, the Lua runtime also 'listens' to UART 0, the serial port, in interactive mode and will execute any Lua commands input through this serial port.
|
||||||
|
|
||||||
This event-driven approach is very different to a conventional procedural implementation of Lua.
|
This event-driven approach is very different to a conventional procedural implementation of Lua.
|
||||||
|
|
||||||
Consider a simple telnet example given in `examples/fragment.lua`:
|
Consider the following snippet:
|
||||||
|
|
||||||
```lua
|
```lua
|
||||||
s=net.createServer(net.TCP)
|
s=net.createServer(net.TCP)
|
||||||
|
|
@ -112,12 +113,12 @@ This example defines five Lua functions:
|
||||||
|
|
||||||
`s`, `con_std` and `s_output` are global, and no [upvalues](#why-is-it-importance-to-understand-how-upvalues-are-implemented-when-programming-for-the-esp8266) are used. There is no "correct" order to define these in, but we could reorder this code for clarity (though doing this adds a few extra globals) and define these functions separately one another. However, let us consider how this is executed:
|
`s`, `con_std` and `s_output` are global, and no [upvalues](#why-is-it-importance-to-understand-how-upvalues-are-implemented-when-programming-for-the-esp8266) are used. There is no "correct" order to define these in, but we could reorder this code for clarity (though doing this adds a few extra globals) and define these functions separately one another. However, let us consider how this is executed:
|
||||||
|
|
||||||
* The outer module is compiled including the four internal functions.
|
* The outer module is compiled including the four internal functions.
|
||||||
* `Main` is then assigning the created `net.createServer()` to the global `s`. The `connection listener` closure is created and bound to a temporary variable which is then passed to the `socket.listen()` as an argument. The routine then exits returning control to the firmware.
|
* `Main` is then assigning the created `net.createServer()` to the global `s`. The `connection listener` closure is created and bound to a temporary variable which is then passed to the `socket.listen()` as an argument. The routine then exits returning control to the firmware.
|
||||||
* When another computer connects to port 23, the listener handler retrieves the reference to then connection listener and calls it with the socket parameter. This function then binds the s_output closure to the global `s_output`, and registers this function with the `node.output` hook. Likewise the `on receive` and `on disconnection` are bound to temporary variables which are passed to the respective on handlers. We now have four Lua function registered in the Lua runtime libraries associated with four events. This routine then exits returning control to the firmware.
|
* When another computer connects to port 23, the listener handler retrieves the reference to then connection listener and calls it with the socket parameter. This function then binds the s_output closure to the global `s_output`, and registers this function with the `node.output` hook. Likewise the `on receive` and `on disconnection` are bound to temporary variables which are passed to the respective on handlers. We now have four Lua function registered in the Lua runtime libraries associated with four events. This routine then exits returning control to the firmware.
|
||||||
* When a record is received, the on receive handler within the net library retrieves the reference to the `on receive` Lua function and calls it passing it the record. This routine then passes this to the `node.input()` and exits returning control to the firmware.
|
* When a record is received, the on receive handler within the net library retrieves the reference to the `on receive` Lua function and calls it passing it the record. This routine then passes this to the `node.input()` and exits returning control to the firmware.
|
||||||
* The `node.input` handler polls on an 80 mSec timer alarm. If a compete Lua chunk is available (either via the serial port or node input function), then it executes it and any output is then passed to the `note.output` handler. which calls `s_output` function. Any pending sends are then processed.
|
* The `node.input` handler polls on an 80 mSec timer alarm. If a compete Lua chunk is available (either via the serial port or node input function), then it executes it and any output is then passed to the `note.output` handler. which calls `s_output` function. Any pending sends are then processed.
|
||||||
* This cycle repeats until the other computer disconnects, and `net` library disconnection handler then calls the Lua `on disconnect` handler. This Lua routine dereferences the connected socket and closes the `node.output` hook and exits returning control to the disconnect handler which garbage collects any associated sockets and registered on handlers.
|
* This cycle repeats until the other computer disconnects, and `net` library disconnection handler then calls the Lua `on disconnect` handler. This Lua routine dereferences the connected socket and closes the `node.output` hook and exits returning control to the disconnect handler which garbage collects any associated sockets and registered on handlers.
|
||||||
|
|
||||||
Whilst this is all going on, The SDK can (and often will) schedule other event tasks in between these Lua executions (e.g. to do the actual TCP stack processing). The longest individual Lua execution in this example is only 18 bytecode instructions (in the main routine).
|
Whilst this is all going on, The SDK can (and often will) schedule other event tasks in between these Lua executions (e.g. to do the actual TCP stack processing). The longest individual Lua execution in this example is only 18 bytecode instructions (in the main routine).
|
||||||
|
|
||||||
|
|
@ -141,12 +142,12 @@ SDK Callbacks include:
|
||||||
|
|
||||||
### So how is context passed between Lua event tasks?
|
### So how is context passed between Lua event tasks?
|
||||||
|
|
||||||
* It is important to understand that any event callback task is associated with a single Lua function. This function is executed from the relevant NodeMCU library C code using a `lua_call()`. Even system initialisation which executes the `dofile("init.lua")` can be treated as a special case of this. Each function can invoke other functions and so on, but it must ultimate return control to the C library code.
|
* It is important to understand that any event callback task is associated with a single Lua function. This function is executed from the relevant NodeMCU library C code using a `lua_call()`. Even system initialisation which executes the `dofile("init.lua")` can be treated as a special case of this. Each function can invoke other functions and so on, but it must ultimate return control to the C library code.
|
||||||
* By their very nature Lua `local` variables only exist within the context of an executing Lua function, and so all locals are destroyed between these `lua_call()` actions. *No locals are retained across events*.
|
* By their very nature Lua `local` variables only exist within the context of an executing Lua function, and so all locals are destroyed between these `lua_call()` actions. *No locals are retained across events*.
|
||||||
* So context can only be passed between event routines by one of three mechanisms:
|
* So context can only be passed between event routines by one of three mechanisms:
|
||||||
* **Globals** are by nature globally accessible. Any global will persist until explicitly dereference by reassigning `nil` to it. Globals can be readily enumerated by a `for k,v in pairs(_G) do` so their use is transparent.
|
* **Globals** are by nature globally accessible. Any global will persist until explicitly dereference by reassigning `nil` to it. Globals can be readily enumerated by a `for k,v in pairs(_G) do` so their use is transparent.
|
||||||
* The **File system** is a special case of persistent global, so there is no reason in principle why it can't be used to pass context. However the ESP8266 file system uses flash memory and this has a limited write cycle lifetime, so it is best to avoid using the file system to store frequently changing content except as a mechanism of last resort.
|
* The **File system** is a special case of persistent global, so there is no reason in principle why it can't be used to pass context. However the ESP8266 file system uses flash memory and this has a limited write cycle lifetime, so it is best to avoid using the file system to store frequently changing content except as a mechanism of last resort.
|
||||||
* **Upvalues**. When a function is declared within an outer function, all of the local variables in the outer scope are available to the inner function. Since all functions are stored by reference the scope of the inner function might outlast the scope of the outer function, and the Lua runtime system ensures that any such references persist for the life of any functions that reference it. This standard feature of Lua is known as *closure* and is described in [Pil 6]. Such values are often called *upvalues*. Functions which are global or [[#So how is the Lua Registry used and why is this important?|registered]] callbacks will persist between event routines, and hence any upvalues referenced by them can be used for passing context.
|
* **Upvalues**. When a function is declared within an outer function, all of the local variables in the outer scope are available to the inner function. Since all functions are stored by reference the scope of the inner function might outlast the scope of the outer function, and the Lua runtime system ensures that any such references persist for the life of any functions that reference it. This standard feature of Lua is known as *closure* and is described in [Pil 6]. Such values are often called *upvalues*. Functions which are global or [[#So how is the Lua Registry used and why is this important?|registered]] callbacks will persist between event routines, and hence any upvalues referenced by them can be used for passing context.
|
||||||
|
|
||||||
### So how is the Lua Registry used and why is this important?
|
### So how is the Lua Registry used and why is this important?
|
||||||
|
|
||||||
|
|
@ -165,22 +166,22 @@ One further complication is that some library functions don't correctly derefere
|
||||||
### Can I encapsulate actions such as sending an email in a Lua function?
|
### Can I encapsulate actions such as sending an email in a Lua function?
|
||||||
|
|
||||||
Think about the implications of these last few answers.
|
Think about the implications of these last few answers.
|
||||||
* An action such as composing and sending an email involves a message dialogue with a mail server over TCP. This in turn requires calling multiple API calls to the SDK and your Lua code must return control to the C calling library for this to be scheduled, otherwise these requests will just queue up, you'll run out of RAM and your application will PANIC.
|
* An action such as composing and sending an email involves a message dialogue with a mail server over TCP. This in turn requires calling multiple API calls to the SDK and your Lua code must return control to the C calling library for this to be scheduled, otherwise these requests will just queue up, you'll run out of RAM and your application will PANIC.
|
||||||
* Hence it is simply ***impossible*** to write a Lua module so that you can do something like:
|
* Hence it is simply ***impossible*** to write a Lua module so that you can do something like:
|
||||||
|
|
||||||
```lua
|
```lua
|
||||||
-- prepare message
|
-- prepare message
|
||||||
status = mail.send(to, subject, body)
|
status = mail.send(to, subject, body)
|
||||||
-- move on to next phase of processing.
|
-- move on to next phase of processing.
|
||||||
```
|
```
|
||||||
* But you could code up a event-driven task to do this and pass it a callback to be executed on completion of the mail send, something along the lines of the following. Note that since this involves a lot of asynchronous processing and which therefore won't take place until you've returned control to the calling library C code, you will typically execute this as the last step in a function and therefore this is best done as a tailcall [PiL 6.3].
|
* But you could code up a event-driven task to do this and pass it a callback to be executed on completion of the mail send, something along the lines of the following. Note that since this involves a lot of asynchronous processing and which therefore won't take place until you've returned control to the calling library C code, you will typically execute this as the last step in a function and therefore this is best done as a tailcall [PiL 6.3].
|
||||||
|
|
||||||
```lua
|
```lua
|
||||||
-- prepare message
|
-- prepare message
|
||||||
local ms = require("mail_sender")
|
local ms = require("mail_sender")
|
||||||
return ms.send(to, subject, body, function(status) loadfile("process_next.lua")(status) end)
|
return ms.send(to, subject, body, function(status) loadfile("process_next.lua")(status) end)
|
||||||
```
|
```
|
||||||
* Building an application on the ESP8266 is a bit like threading pearls onto a necklace. Each pearl is an event task which must be small enough to run within its RAM resources and the string is the variable context that links the pearls together.
|
* Building an application on the ESP8266 is a bit like threading pearls onto a necklace. Each pearl is an event task which must be small enough to run within its RAM resources and the string is the variable context that links the pearls together.
|
||||||
|
|
||||||
### When and why should I avoid using tmr.delay()?
|
### When and why should I avoid using tmr.delay()?
|
||||||
|
|
||||||
|
|
@ -196,43 +197,43 @@ The latest SDK includes a caution that if any (callback) task runs for more than
|
||||||
### How do I avoid a PANIC loop in init.lua?
|
### How do I avoid a PANIC loop in init.lua?
|
||||||
|
|
||||||
Most of us have fallen into the trap of creating an `init.lua` that has a bug in it, which then causes the system to reboot and hence gets stuck in a reboot loop. If you haven't then you probably will do so at least once.
|
Most of us have fallen into the trap of creating an `init.lua` that has a bug in it, which then causes the system to reboot and hence gets stuck in a reboot loop. If you haven't then you probably will do so at least once.
|
||||||
* When this happens, the only robust solution is to reflash the firmware.
|
* When this happens, the only robust solution is to reflash the firmware.
|
||||||
* The simplest way to avoid having to do this is to keep the `init.lua` as simple as possible -- say configure the wifi and then start your app using a one-time `tmr.alarm()` after a 2-3 sec delay. This delay is long enough to issue a `file.remove("init.lua")` through the serial port and recover control that way.
|
* The simplest way to avoid having to do this is to keep the `init.lua` as simple as possible -- say configure the wifi and then start your app using a one-time `tmr.alarm()` after a 2-3 sec delay. This delay is long enough to issue a `file.remove("init.lua")` through the serial port and recover control that way.
|
||||||
* Also it is always best to test any new `init.lua` by creating it as `init_test.lua`, say, and manually issuing a `dofile("init_test.lua")` through the serial port, and then only rename it when you are certain it is working as you require.
|
* Also it is always best to test any new `init.lua` by creating it as `init_test.lua`, say, and manually issuing a `dofile("init_test.lua")` through the serial port, and then only rename it when you are certain it is working as you require.
|
||||||
|
|
||||||
## Techniques for Reducing RAM and SPIFFS footprint
|
## Techniques for Reducing RAM and SPIFFS footprint
|
||||||
|
|
||||||
### How do I minimise the footprint of an application?
|
### How do I minimise the footprint of an application?
|
||||||
|
|
||||||
* Perhaps the simplest aspect of reducing the footprint of an application is to get its scope correct. The ESP8266 is an IoT device and not a general purpose system. It is typically used to attach real-world monitors, controls, etc. to an intranet and is therefore designed to implement functions that have limited scope. We commonly come across developers who are trying to treat the ESP8266 as a general purpose device and can't understand why their application can't run.
|
* Perhaps the simplest aspect of reducing the footprint of an application is to get its scope correct. The ESP8266 is an IoT device and not a general purpose system. It is typically used to attach real-world monitors, controls, etc. to an intranet and is therefore designed to implement functions that have limited scope. We commonly come across developers who are trying to treat the ESP8266 as a general purpose device and can't understand why their application can't run.
|
||||||
* The simplest and safest way to use IoT devices is to control them through a dedicated general purpose system on the same network. This could be a low cost system such as a [RaspberryPi (RPi)](https://www.raspberrypi.org/) server, running your custom code or an open source home automation (HA) application. Such systems have orders of magnitude more capacity than the ESP8266, for example the RPi has 2GB RAM and its SD card can be up to 32GB in capacity, and it can support the full range of USB-attached disk drives and other devices. It also runs a fully featured Linux OS, and has a rich selection of applications pre configured for it. There are plenty of alternative systems available in this under $50 price range, as well as proprietary HA systems which can cost 10-50 times more.
|
* The simplest and safest way to use IoT devices is to control them through a dedicated general purpose system on the same network. This could be a low cost system such as a [RaspberryPi (RPi)](https://www.raspberrypi.org/) server, running your custom code or an open source home automation (HA) application. Such systems have orders of magnitude more capacity than the ESP8266, for example the RPi has 2GB RAM and its SD card can be up to 32GB in capacity, and it can support the full range of USB-attached disk drives and other devices. It also runs a fully featured Linux OS, and has a rich selection of applications pre configured for it. There are plenty of alternative systems available in this under $50 price range, as well as proprietary HA systems which can cost 10-50 times more.
|
||||||
* Using a tiered approach where all user access to the ESP8266 is passed through a controlling server means that the end-user interface (or smartphone connector), together with all of the associated validation and security can be implemented on a system designed to have the capacity to do this. This means that you can limit the scope of your ESP8266 application to a limited set of functions being sent to or responding to requests from this system.
|
* Using a tiered approach where all user access to the ESP8266 is passed through a controlling server means that the end-user interface (or smartphone connector), together with all of the associated validation and security can be implemented on a system designed to have the capacity to do this. This means that you can limit the scope of your ESP8266 application to a limited set of functions being sent to or responding to requests from this system.
|
||||||
* *If you are trying to implement a user-interface or HTTP webserver in your ESP8266 then you are really abusing its intended purpose. When it comes to scoping your ESP8266 applications, the adage **K**eep **I**t **S**imple **S**tupid truly applies.*
|
* *If you are trying to implement a user-interface or HTTP webserver in your ESP8266 then you are really abusing its intended purpose. When it comes to scoping your ESP8266 applications, the adage **K**eep **I**t **S**imple **S**tupid truly applies.*
|
||||||
|
|
||||||
### How do I minimise the footprint of an application on the file system
|
### How do I minimise the footprint of an application on the file system
|
||||||
|
|
||||||
* It is possible to write Lua code in a very compact format which is very dense in terms of functionality per KB of source code.
|
* It is possible to write Lua code in a very compact format which is very dense in terms of functionality per KB of source code.
|
||||||
* However if you do this then you will also find it extremely difficult to debug or maintain your application.
|
* However if you do this then you will also find it extremely difficult to debug or maintain your application.
|
||||||
* A good compromise is to use a tool such as [LuaSrcDiet](http://luaforge.net/projects/luasrcdiet/), which you can use to compact production code for downloading to the ESP8266:
|
* A good compromise is to use a tool such as [LuaSrcDiet](http://luaforge.net/projects/luasrcdiet/), which you can use to compact production code for downloading to the ESP8266:
|
||||||
* Keep a master repository of your code on your PC or a cloud-based versioning repository such as [GitHub](https://github.com/)
|
* Keep a master repository of your code on your PC or a cloud-based versioning repository such as [GitHub](https://github.com/)
|
||||||
* Lay it out and comment it for ease of maintenance and debugging
|
* Lay it out and comment it for ease of maintenance and debugging
|
||||||
* Use a package such as [Esplorer](https://github.com/4refr0nt/ESPlorer) to download modules that you are debugging and to test them.
|
* Use a package such as [Esplorer](https://github.com/4refr0nt/ESPlorer) to download modules that you are debugging and to test them.
|
||||||
* Once the code is tested and stable, then compress it using LuaSrcDiet before downloading to the ESP8266. Doing this will reduce the code footprint on the SPIFFS by 2-3x.
|
* Once the code is tested and stable, then compress it using LuaSrcDiet before downloading to the ESP8266. Doing this will reduce the code footprint on the SPIFFS by 2-3x.
|
||||||
* Consider using `node.compile()` to pre-compile any production code. This removes the debug information from the compiled code reducing its size by roughly 40%. (However this is still perhaps 1.5-2x larger than a LuaSrcDiet-compressed source format, so if SPIFFS is tight then you might consider leaving less frequently run modules in Lua format. If you do a compilation, then you should consider removing the Lua source copy from file system as there's little point in keeping both on the ESP8266.
|
* Consider using `node.compile()` to pre-compile any production code. This removes the debug information from the compiled code reducing its size by roughly 40%. (However this is still perhaps 1.5-2x larger than a LuaSrcDiet-compressed source format, so if SPIFFS is tight then you might consider leaving less frequently run modules in Lua format. If you do a compilation, then you should consider removing the Lua source copy from file system as there's little point in keeping both on the ESP8266.
|
||||||
|
|
||||||
### How do I minimise the footprint of running application?
|
### How do I minimise the footprint of running application?
|
||||||
|
|
||||||
* The Lua Garbage collector is very aggressive at scanning and recovering dead resources. It uses an incremental mark-and-sweep strategy which means that any data which is not ultimately referenced back to the Globals table, the Lua registry or in-scope local variables in the current Lua code will be collected.
|
* The Lua Garbage collector is very aggressive at scanning and recovering dead resources. It uses an incremental mark-and-sweep strategy which means that any data which is not ultimately referenced back to the Globals table, the Lua registry or in-scope local variables in the current Lua code will be collected.
|
||||||
* Setting any variable to `nil` dereferences the previous context of that variable. (Note that reference-based variables such as tables, strings and functions can have multiple variables referencing the same object, but once the last reference has been set to `nil`, the collector will recover the storage.
|
* Setting any variable to `nil` dereferences the previous context of that variable. (Note that reference-based variables such as tables, strings and functions can have multiple variables referencing the same object, but once the last reference has been set to `nil`, the collector will recover the storage.
|
||||||
* Unlike other compile-on-load languages such as PHP, Lua compiled code is treated the same way as any other variable type when it comes to garbage collection and can be collected when fully dereferenced, so that the code-space can be reused.
|
* Unlike other compile-on-load languages such as PHP, Lua compiled code is treated the same way as any other variable type when it comes to garbage collection and can be collected when fully dereferenced, so that the code-space can be reused.
|
||||||
* Lua execution is intrinsically divided into separate event tasks with each bound to a Lua callback. This, when coupled with the strong dispose on dereference feature, means that it is very easy to structure your application using an classic technique which dates back to the 1950s known as Overlays.
|
* Lua execution is intrinsically divided into separate event tasks with each bound to a Lua callback. This, when coupled with the strong dispose on dereference feature, means that it is very easy to structure your application using an classic technique which dates back to the 1950s known as Overlays.
|
||||||
* Various approaches can be use to implement this. One is described by DP Whittaker in his [Massive memory optimization: flash functions](http://www.esp8266.com/viewtopic.php?f=19&t=1940) topic. Another is to use *volatile modules*. There are standard Lua templates for creating modules, but the `require()` library function creates a reference for the loaded module in the `package.loaded` table, and this reference prevents the module from being garbage collected. To make a module volatile, you should remove this reference to the loaded module by setting its corresponding entry in `package.loaded` to `nil`. You can't do this in the outermost level of the module (since the reference is only created once execution has returned from the module code), but you can do it in any module function, and typically an initialisation function for the module, as in the following example:
|
* Various approaches can be use to implement this. One is described by DP Whittaker in his [Massive memory optimization: flash functions](http://www.esp8266.com/viewtopic.php?f=19&t=1940) topic. Another is to use *volatile modules*. There are standard Lua templates for creating modules, but the `require()` library function creates a reference for the loaded module in the `package.loaded` table, and this reference prevents the module from being garbage collected. To make a module volatile, you should remove this reference to the loaded module by setting its corresponding entry in `package.loaded` to `nil`. You can't do this in the outermost level of the module (since the reference is only created once execution has returned from the module code), but you can do it in any module function, and typically an initialisation function for the module, as in the following example:
|
||||||
|
|
||||||
```lua
|
```lua
|
||||||
local s=net.createServer(net.TCP)
|
local s=net.createServer(net.TCP)
|
||||||
s:listen(80,function(c) require("connector").init(c) end)
|
s:listen(80,function(c) require("connector").init(c) end)
|
||||||
```
|
```
|
||||||
* **`connector.lua`** would be a standard module pattern except that the `M.init()` routine must include the lines
|
* **`connector.lua`** would be a standard module pattern except that the `M.init()` routine must include the lines
|
||||||
|
|
||||||
```lua
|
```lua
|
||||||
local M, module = {}, ...
|
local M, module = {}, ...
|
||||||
|
|
@ -244,8 +245,8 @@ end
|
||||||
--
|
--
|
||||||
return M
|
return M
|
||||||
```
|
```
|
||||||
* This approach ensures that the module can be fully dereferenced on completion. OK, in this case, this also means that the module has to be reloaded on each TCP connection to port 80; however, loading a compiled module from SPIFFS only takes a few mSec, so surely this is an acceptable overhead if it enables you to break down your application into RAM-sized chunks. Note that `require()` will automatically search for `connector.lc` followed by `connector.lua`, so the code will work for both source and compiled variants.
|
* This approach ensures that the module can be fully dereferenced on completion. OK, in this case, this also means that the module has to be reloaded on each TCP connection to port 80; however, loading a compiled module from SPIFFS only takes a few mSec, so surely this is an acceptable overhead if it enables you to break down your application into RAM-sized chunks. Note that `require()` will automatically search for `connector.lc` followed by `connector.lua`, so the code will work for both source and compiled variants.
|
||||||
* Whilst the general practice is for a module to return a table, [PiL 15.1] suggests that it is sometimes appropriate to return a single function instead as this avoids the memory overhead of an additional table. This pattern would look as follows:
|
* Whilst the general practice is for a module to return a table, [PiL 15.1] suggests that it is sometimes appropriate to return a single function instead as this avoids the memory overhead of an additional table. This pattern would look as follows:
|
||||||
|
|
||||||
```lua
|
```lua
|
||||||
--
|
--
|
||||||
|
|
@ -261,7 +262,7 @@ return function (csocket)
|
||||||
...
|
...
|
||||||
end
|
end
|
||||||
```
|
```
|
||||||
* Also note that you should ***not*** normally code this up listener call as the following because the RAM now has to accommodate both the module which creates the server *and* the connector logic.
|
* Also note that you should ***not*** normally code this up listener call as the following because the RAM now has to accommodate both the module which creates the server *and* the connector logic.
|
||||||
|
|
||||||
```lua
|
```lua
|
||||||
...
|
...
|
||||||
|
|
@ -284,8 +285,8 @@ Note that if you use `require("XXX")` to load your code then this will automatic
|
||||||
|
|
||||||
### How do I get a feel for how much memory my functions use?
|
### How do I get a feel for how much memory my functions use?
|
||||||
|
|
||||||
* You should get an overall understanding of the VM model if you want to make good use of the limited resources available to Lua applications. An essential reference here is [A No Frills Introduction to Lua 5.1 VM Instructions](http://luaforge.net/docman/83/98/ANoFrillsIntroToLua51VMInstructions.pdf) . This explain how the code generator works, how much memory overhead is involved with each table, function, string etc..
|
* You should get an overall understanding of the VM model if you want to make good use of the limited resources available to Lua applications. An essential reference here is [A No Frills Introduction to Lua 5.1 VM Instructions](http://luaforge.net/docman/83/98/ANoFrillsIntroToLua51VMInstructions.pdf) . This explain how the code generator works, how much memory overhead is involved with each table, function, string etc..
|
||||||
* You can't easily get a bytecode listing of your ESP8266 code; however there are two broad options for doing this:
|
* You can't easily get a bytecode listing of your ESP8266 code; however there are two broad options for doing this:
|
||||||
* **Generate a bytecode listing on your development PC**. The Lua 5.1 code generator is basically the same on the PC and on the ESP8266, so whilst it isn't identical, using the standard Lua batch compiler `luac` against your source on your PC with the `-l -s` option will give you a good idea of what your code will generate. The main difference between these two variants is the size_t for ESP8266 is 4 bytes rather than the 8 bytes size_t found on modern 64bit development PCs; and the eLua variants generate different access references for ROM data types. If you want to see what the `string.dump()` version generates then drop the `-s` option to retain the debug information.
|
* **Generate a bytecode listing on your development PC**. The Lua 5.1 code generator is basically the same on the PC and on the ESP8266, so whilst it isn't identical, using the standard Lua batch compiler `luac` against your source on your PC with the `-l -s` option will give you a good idea of what your code will generate. The main difference between these two variants is the size_t for ESP8266 is 4 bytes rather than the 8 bytes size_t found on modern 64bit development PCs; and the eLua variants generate different access references for ROM data types. If you want to see what the `string.dump()` version generates then drop the `-s` option to retain the debug information.
|
||||||
* **Upload your `.lc` files to the PC and disassemble then there**. There are a number of Lua code disassemblers which can list off the compiled code that you application modules will generate, `if` you have a script to upload files from your ESP8266 to your development PC. I use [ChunkSpy](http://luaforge.net/projects/chunkspy/) which can be downloaded [here](http://files.luaforge.net/releases/chunkspy/chunkspy/ChunkSpy-0.9.8/ChunkSpy-0.9.8.zip) , but you will need to apply the following patch so that ChunkSpy understands eLua data types:
|
* **Upload your `.lc` files to the PC and disassemble then there**. There are a number of Lua code disassemblers which can list off the compiled code that you application modules will generate, `if` you have a script to upload files from your ESP8266 to your development PC. I use [ChunkSpy](http://luaforge.net/projects/chunkspy/) which can be downloaded [here](http://files.luaforge.net/releases/chunkspy/chunkspy/ChunkSpy-0.9.8/ChunkSpy-0.9.8.zip) , but you will need to apply the following patch so that ChunkSpy understands eLua data types:
|
||||||
|
|
||||||
|
|
@ -302,8 +303,8 @@ Note that if you use `require("XXX")` to load your code then this will automatic
|
||||||
elseif a == "--interact" then
|
elseif a == "--interact" then
|
||||||
perform = ChunkSpy_Interact
|
perform = ChunkSpy_Interact
|
||||||
```
|
```
|
||||||
* Your other great friend is to use `node.heap()` regularly through your code.
|
* Your other great friend is to use `node.heap()` regularly through your code.
|
||||||
* Use these tools and play with coding approaches to see how many instructions each typical line of code takes in your coding style. The Lua Wiki gives some general optimisation tips, but in general just remember that these focus on optimising for execution speed and you will be interested mainly in optimising for code and variable space as these are what consumes precious RAM.
|
* Use these tools and play with coding approaches to see how many instructions each typical line of code takes in your coding style. The Lua Wiki gives some general optimisation tips, but in general just remember that these focus on optimising for execution speed and you will be interested mainly in optimising for code and variable space as these are what consumes precious RAM.
|
||||||
|
|
||||||
### What is the cost of using functions?
|
### What is the cost of using functions?
|
||||||
|
|
||||||
|
|
@ -331,11 +332,11 @@ Of course you should still use functions to structure your code and encapsulate
|
||||||
|
|
||||||
### What other resources are available?
|
### What other resources are available?
|
||||||
|
|
||||||
* Install lua and luac on your development PC. This is freely available for Windows, Mac and Linux distributions, but we strongly suggest that you use Lua 5.1 to maintain source compatibility with ESP8266 code. This will allow you not only to unit test some modules on your PC in a rich development environment, but you can also use `luac` to generate a bytecode listing of your code and to validate new code syntactically before downloading to the ESP8266. This will also allow you to develop server-side applications and embedded applications in a common language.
|
* Install lua and luac on your development PC. This is freely available for Windows, Mac and Linux distributions, but we strongly suggest that you use Lua 5.1 to maintain source compatibility with ESP8266 code. This will allow you not only to unit test some modules on your PC in a rich development environment, but you can also use `luac` to generate a bytecode listing of your code and to validate new code syntactically before downloading to the ESP8266. This will also allow you to develop server-side applications and embedded applications in a common language.
|
||||||
|
|
||||||
## Firmware and Lua app development
|
## Firmware and Lua app development
|
||||||
|
|
||||||
### How to save memory?
|
### How to save memory?
|
||||||
* The NodeMCU development team recommends that you consider using a tailored firmware build, which only includes the modules that you plan to use before developing any Lua application. Once you have the ability to make and flash custom builds, the you also have the option of moving time sensitive or logic intensive code into your own custom module. Doing this can save a large amount of RAM as C code can be run directly from Flash memory. If you want an easy-to-use intermediate option then why note try the [cloud based NodeMCU custom build service](http://frightanic.com/NodeMCU-custom-build)?.
|
* The NodeMCU development team recommends that you consider using a tailored firmware build, which only includes the modules that you plan to use before developing any Lua application. Once you have the ability to make and flash custom builds, the you also have the option of moving time sensitive or logic intensive code into your own custom module. Doing this can save a large amount of RAM as C code can be run directly from Flash memory. If you want an easy-to-use intermediate option then why note try the [cloud based NodeMCU custom build service](http://frightanic.com/NodeMCU-custom-build)?.
|
||||||
|
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -1,8 +1,10 @@
|
||||||
As with [flashing](flash.md) there are several ways to upload code from your computer to the device.
|
As with [flashing](flash.md) there are several ways to upload code from your computer to the device.
|
||||||
|
|
||||||
Note that the NodeMCU serial interface uses 115200bps at boot time. To change the speed after booting, issue `uart.setup(0,9600,8,0,1,1)`. ESPlorer will do this automatically when changing the speed in the dropdown list. If the device panics and resets at any time, errors will be written to the serial interface at 115200 bps.
|
Note that the NodeMCU serial interface uses 115'200bps at boot time. To change the speed after booting, issue `uart.setup(0,9600,8,0,1,1)`. ESPlorer will do this automatically when changing the speed in the dropdown list. If the device panics and resets at any time, errors will be written to the serial interface at 115'200 bps.
|
||||||
|
|
||||||
# ESPlorer
|
# Tools
|
||||||
|
|
||||||
|
## ESPlorer
|
||||||
|
|
||||||
> The essential multiplatforms tools for any ESP8266 developer from luatool author’s, including Lua for NodeMCU and MicroPython. Also, all AT commands are supported. Requires Java (Standard Edition - SE ver 7 and above) installed.
|
> The essential multiplatforms tools for any ESP8266 developer from luatool author’s, including Lua for NodeMCU and MicroPython. Also, all AT commands are supported. Requires Java (Standard Edition - SE ver 7 and above) installed.
|
||||||
|
|
||||||
|
|
@ -12,7 +14,7 @@ Source: [https://github.com/4refr0nt/ESPlorer](https://github.com/4refr0nt/ESPlo
|
||||||
|
|
||||||
Supported platforms: OS X, Linux, Windows, anything that runs Java
|
Supported platforms: OS X, Linux, Windows, anything that runs Java
|
||||||
|
|
||||||
# nodemcu-uploader.py
|
## nodemcu-uploader.py
|
||||||
|
|
||||||
> A simple tool for uploading files to the filesystem of an ESP8266 running NodeMCU as well as some other useful commands.
|
> A simple tool for uploading files to the filesystem of an ESP8266 running NodeMCU as well as some other useful commands.
|
||||||
|
|
||||||
|
|
@ -20,7 +22,7 @@ Source: [https://github.com/kmpm/nodemcu-uploader](https://github.com/kmpm/nodem
|
||||||
|
|
||||||
Supported platforms: OS X, Linux, Windows, anything that runs Python
|
Supported platforms: OS X, Linux, Windows, anything that runs Python
|
||||||
|
|
||||||
# NodeMCU Studio
|
## NodeMCU Studio
|
||||||
|
|
||||||
> THIS TOOL IS IN REALLY REALLY REALLY REALLY EARLY STAGE!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
> THIS TOOL IS IN REALLY REALLY REALLY REALLY EARLY STAGE!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
||||||
|
|
||||||
|
|
@ -28,7 +30,7 @@ Source: [https://github.com/nodemcu/nodemcu-studio-csharp](https://github.com/no
|
||||||
|
|
||||||
Supported platforms: Windows
|
Supported platforms: Windows
|
||||||
|
|
||||||
# luatool
|
## luatool
|
||||||
|
|
||||||
> Allow easy uploading of any Lua-based script into the ESP8266 flash memory with NodeMcu firmware
|
> Allow easy uploading of any Lua-based script into the ESP8266 flash memory with NodeMcu firmware
|
||||||
|
|
||||||
|
|
@ -36,6 +38,45 @@ Source: [https://github.com/4refr0nt/luatool](https://github.com/4refr0nt/luatoo
|
||||||
|
|
||||||
Supported platforms: OS X, Linux, Windows, anything that runs Python
|
Supported platforms: OS X, Linux, Windows, anything that runs Python
|
||||||
|
|
||||||
|
# init.lua
|
||||||
|
You will see "lua: cannot open init.lua" printed to the serial console when the device boots after it's been freshly flashed. If NodeMCU finds a `init.lua` in the root of the file system it will execute it as part of the boot sequence (standard Lua feature). Hence, your application is initialized and triggered from `init.lua`. Usually you first set up the WiFi connection and only continue once that has been successful.
|
||||||
|
|
||||||
|
Be very careful not to lock yourself out! If there's a bug in your `init.lua` you may be stuck in an infinite reboot loop. It is, therefore, advisable to build a small delay into your startup sequence that would allow you to interrupt the sequence by e.g. deleting or renaming `init.lua` (see also [FAQ](lua-developer-faq.md#how-do-i-avoid-a-panic-loop-in-initlua)). Your `init.lua` is most likely going to be different than the one below but it's a good starting point for customizations:
|
||||||
|
|
||||||
|
```lua
|
||||||
|
-- load credentials, 'SSID' and 'PASSWORD' declared and initialize in there
|
||||||
|
dofile("credentials.lua")
|
||||||
|
|
||||||
|
function startup()
|
||||||
|
if file.open("init.lua") == nil then
|
||||||
|
print("init.lua deleted or renamed")
|
||||||
|
else
|
||||||
|
print("Running")
|
||||||
|
file.close("init.lua")
|
||||||
|
-- the actual application is stored in 'application.lua'
|
||||||
|
-- dofile("application.lua")
|
||||||
|
end
|
||||||
|
end
|
||||||
|
|
||||||
|
print("Connecting to WiFi access point...")
|
||||||
|
wifi.setmode(wifi.STATION)
|
||||||
|
wifi.sta.config(SSID, PASSWORD)
|
||||||
|
wifi.sta.connect()
|
||||||
|
tmr.alarm(1, 1000, 1, function()
|
||||||
|
if wifi.sta.getip() == nil then
|
||||||
|
print("Waiting for IP address...")
|
||||||
|
else
|
||||||
|
tmr.stop(1)
|
||||||
|
print("WiFi connection established, IP address: " .. wifi.sta.getip())
|
||||||
|
print("You have 3 seconds to abort")
|
||||||
|
print("Waiting...")
|
||||||
|
tmr.alarm(0, 3000, 0, startup)
|
||||||
|
end
|
||||||
|
end)
|
||||||
|
```
|
||||||
|
|
||||||
|
Inspired by [https://github.com/ckuehnel/NodeMCU-applications](https://github.com/ckuehnel/NodeMCU-applications)
|
||||||
|
|
||||||
# Compiling Lua on your PC for Uploading
|
# Compiling Lua on your PC for Uploading
|
||||||
|
|
||||||
If you install lua on your development PC or Laptop then you can use the standard Lua
|
If you install lua on your development PC or Laptop then you can use the standard Lua
|
||||||
|
|
|
||||||
|
|
@ -1,521 +0,0 @@
|
||||||
pwm.setup(0,500,50) pwm.setup(1,500,50) pwm.setup(2,500,50)
|
|
||||||
pwm.start(0) pwm.start(1) pwm.start(2)
|
|
||||||
function led(r,g,b) pwm.setduty(0,g) pwm.setduty(1,b) pwm.setduty(2,r) end
|
|
||||||
wifi.sta.autoconnect(1)
|
|
||||||
a=0
|
|
||||||
tmr.alarm( 1000,1,function() if a==0 then a=1 led(50,50,50) else a=0 led(0,0,0) end end)
|
|
||||||
|
|
||||||
sv:on("receive", function(s,c) s:send("<h1> Hello, world.</h1>") print(c) end )
|
|
||||||
|
|
||||||
|
|
||||||
sk=net.createConnection(net.TCP, 0)
|
|
||||||
sk:on("receive", function(sck, c) print(c) end )
|
|
||||||
sk:connect(80,"115.239.210.27")
|
|
||||||
sk:send("GET / HTTP/1.1\r\nHost: 115.239.210.27\r\nConnection: keep-alive\r\nAccept: */*\r\n\r\n")
|
|
||||||
|
|
||||||
sk:connect(80,"192.168.0.66")
|
|
||||||
sk:send("GET / HTTP/1.1\r\nHost: 192.168.0.66\r\nConnection: keep-alive\r\nAccept: */*\r\n\r\n")
|
|
||||||
|
|
||||||
i2c.setup(0,1,0,i2c.SLOW)
|
|
||||||
function read_bmp(addr) i2c.start(0) i2c.address(0,119,i2c.RECEIVER) c=i2c.read(0,1) i2c.stop(0) print(string.byte(c)) end
|
|
||||||
function read_bmp(addr) i2c.start(0) i2c.address(0,119,i2c.TRANSMITTER) i2c.write(0,addr) i2c.stop(0) i2c.start(0) i2c.address(0,119,i2c.RECEIVER) c=i2c.read(0,2) i2c.stop(0) return c end
|
|
||||||
|
|
||||||
s=net.createServer(net.TCP) s:listen(80,function(c) end)
|
|
||||||
ss=net.createServer(net.TCP) ss:listen(80,function(c) end)
|
|
||||||
|
|
||||||
s=net.createServer(net.TCP) s:listen(80,function(c) c:on("receive",function(s,c) print(c) end) end)
|
|
||||||
|
|
||||||
s=net.createServer(net.UDP)
|
|
||||||
s:on("receive",function(s,c) print(c) end)
|
|
||||||
s:listen(5683)
|
|
||||||
|
|
||||||
su=net.createConnection(net.UDP)
|
|
||||||
su:on("receive",function(su,c) print(c) end)
|
|
||||||
su:connect(5683,"192.168.18.101")
|
|
||||||
su:send("hello")
|
|
||||||
|
|
||||||
mm=node.list()
|
|
||||||
for k, v in pairs(mm) do print('file:'..k..' len:'..v) end
|
|
||||||
for k,v in pairs(d) do print("n:"..k..", s:"..v) end
|
|
||||||
|
|
||||||
|
|
||||||
gpio.mode(0,gpio.INT) gpio.trig(0,"down",function(l) print("level="..l) end)
|
|
||||||
|
|
||||||
t0 = 0;
|
|
||||||
function tr0(l) print(tmr.now() - t0) t0 = tmr.now()
|
|
||||||
if l==1 then gpio.trig(0,"down") else gpio.trig(0,"up") end end
|
|
||||||
gpio.mode(0,gpio.INT)
|
|
||||||
gpio.trig(0,"down",tr0)
|
|
||||||
|
|
||||||
|
|
||||||
su=net.createConnection(net.UDP)
|
|
||||||
su:on("receive",function(su,c) print(c) end)
|
|
||||||
su:connect(5001,"114.215.154.114")
|
|
||||||
su:send([[{"type":"signin","name":"nodemcu","password":"123456"}]])
|
|
||||||
|
|
||||||
su:send([[{"type":"signout","name":"nodemcu","password":"123456"}]])
|
|
||||||
|
|
||||||
su:send([[{"type":"connect","from":"nodemcu","to":"JYP","password":"123456"}]])
|
|
||||||
|
|
||||||
su:send("hello world")
|
|
||||||
|
|
||||||
s=net.createServer(net.TCP) s:listen(8008,function(c) c:on("receive",function(s,c) print(c) pcall(loadstring(c)) end) end)
|
|
||||||
|
|
||||||
s=net.createServer(net.TCP) s:listen(8008,function(c) con_std = c function s_output(str) if(con_std~=nil) then con_std:send(str) end end
|
|
||||||
node.output(s_output, 0) c:on("receive",function(c,l) node.input(l) end) c:on("disconnection",function(c) con_std = nil node.output(nil) end) end)
|
|
||||||
|
|
||||||
s=net.createServer(net.TCP)
|
|
||||||
s:listen(23,function(c)
|
|
||||||
con_std = c
|
|
||||||
function s_output(str)
|
|
||||||
if(con_std~=nil)
|
|
||||||
then con_std:send(str)
|
|
||||||
end
|
|
||||||
end
|
|
||||||
node.output(s_output, 0)
|
|
||||||
c:on("receive",function(c,l) node.input(l) end)
|
|
||||||
c:on("disconnection",function(c)
|
|
||||||
con_std = nil
|
|
||||||
node.output(nil)
|
|
||||||
end)
|
|
||||||
end)
|
|
||||||
|
|
||||||
srv=net.createServer(net.TCP) srv:listen(80,function(conn) conn:on("receive",function(conn,payload)
|
|
||||||
print(node.heap()) door="open" if gpio.read(8)==1 then door="open" else door="closed" end
|
|
||||||
conn:send("<h1> Door Sensor. The door is " .. door ..".</h1>") conn:close() end) end)
|
|
||||||
|
|
||||||
srv=net.createServer(net.TCP) srv:listen(80,function(conn) conn:on("receive",function(conn,payload)
|
|
||||||
print(node.heap()) print(adc.read(0)) door="open" if gpio.read(0)==1 then door="open" else door="closed" end
|
|
||||||
conn:send("<h1> Door Sensor. The door is " .. door ..".</h1>") end) conn:on("sent",function(conn) conn:close() end) end)
|
|
||||||
|
|
||||||
srv=net.createServer(net.TCP) srv:listen(80,function(conn)
|
|
||||||
conn:on("receive",function(conn,payload)
|
|
||||||
print(node.heap())
|
|
||||||
door="open"
|
|
||||||
if gpio.read(0)==1 then door="open" else door="closed" end
|
|
||||||
conn:send("<h1> Door Sensor. The door is " .. door ..".</h1>")
|
|
||||||
end)
|
|
||||||
conn:on("sent",function(conn) conn:close() end)
|
|
||||||
end)
|
|
||||||
|
|
||||||
port = 9999
|
|
||||||
hostip = "192.168.1.99"
|
|
||||||
sk=net.createConnection(net.TCP, false)
|
|
||||||
sk:on("receive", function(conn, pl) print(pl) end )
|
|
||||||
sk:connect(port, hostip)
|
|
||||||
|
|
||||||
|
|
||||||
file.remove("init.lua")
|
|
||||||
file.open("init.lua","w")
|
|
||||||
file.writeline([[print("Petes Tester 4")]])
|
|
||||||
file.writeline([[tmr.alarm(5000, 0, function() dofile("thelot.lua") end )]])
|
|
||||||
file.close()
|
|
||||||
|
|
||||||
file.remove("thelot.lua")
|
|
||||||
file.open("thelot.lua","w")
|
|
||||||
file.writeline([[tmr.stop()]])
|
|
||||||
file.writeline([[connecttoap = function (ssid,pw)]])
|
|
||||||
file.writeline([[print(wifi.sta.getip())]])
|
|
||||||
file.writeline([[wifi.setmode(wifi.STATION)]])
|
|
||||||
file.writeline([[tmr.delay(1000000)]])
|
|
||||||
file.writeline([[wifi.sta.config(ssid,pw)]])
|
|
||||||
file.writeline([[tmr.delay(5000000)]])
|
|
||||||
file.writeline([[print("Connected to ",ssid," as ",wifi.sta.getip())]])
|
|
||||||
file.writeline([[end]])
|
|
||||||
file.writeline([[connecttoap("MyHub","0011223344")]])
|
|
||||||
file.close()
|
|
||||||
|
|
||||||
|
|
||||||
s=net.createServer(net.UDP) s:listen(5683) s:on("receive",function(s,c) print(c) s:send("echo:"..c) end)
|
|
||||||
s:on("sent",function(s) print("echo donn") end)
|
|
||||||
|
|
||||||
sk=net.createConnection(net.UDP, 0) sk:on("receive", function(sck, c) print(c) end ) sk:connect(8080,"192.168.0.88")
|
|
||||||
sk:send("GET / HTTP/1.1\r\nHost: 192.168.0.88\r\nConnection: keep-alive\r\nAccept: */*\r\n\r\n")
|
|
||||||
|
|
||||||
srv=net.createServer(net.TCP, 5) srv:listen(80,function(conn) conn:on("receive",function(conn,payload)
|
|
||||||
print(node.heap()) print(adc.read(0)) door="open" if gpio.read(0)==1 then door="open" else door="closed" end
|
|
||||||
conn:send("<h1> Door Sensor. The door is " .. door ..".</h1>") end) end)
|
|
||||||
|
|
||||||
srv=net.createServer(net.TCP)
|
|
||||||
srv:listen(80,function(conn)
|
|
||||||
conn:on("receive",function(conn,payload)
|
|
||||||
print(payload) print(node.heap())
|
|
||||||
conn:send("<h1> Hello, NodeMcu.</h1>")
|
|
||||||
end)
|
|
||||||
conn:on("sent",function(conn) conn:close() end)
|
|
||||||
end)
|
|
||||||
|
|
||||||
|
|
||||||
function startServer()
|
|
||||||
print("WIFI AP connected. Wicon IP:")
|
|
||||||
print(wifi.sta.getip())
|
|
||||||
sv=net.createServer(net.TCP,180)
|
|
||||||
sv:listen(8080,function(conn)
|
|
||||||
print("Wifi console connected.")
|
|
||||||
|
|
||||||
function s_output(str)
|
|
||||||
if(conn~=nil) then
|
|
||||||
conn:send(str)
|
|
||||||
end
|
|
||||||
end
|
|
||||||
node.output(s_output,0)
|
|
||||||
|
|
||||||
conn:on("receive",function(conn,pl)
|
|
||||||
node.input(pl)
|
|
||||||
if (conn==nil) then
|
|
||||||
print("conn is nil")
|
|
||||||
end
|
|
||||||
|
|
||||||
print("hello")
|
|
||||||
|
|
||||||
mycounter=0 srv=net.createServer(net.TCP) srv:listen(80,function(conn) conn:on("receive",function(conn,payload)
|
|
||||||
if string.find(payload,"?myarg=") then mycounter=mycounter+1
|
|
||||||
m="<br/>Value= " .. string.sub(payload,string.find(payload,"?myarg=")+7,string.find(payload,"HTTP")-2) else m="" end
|
|
||||||
conn:send("<h1> Hello, this is Pete's web page.</h1>How are you today.<br/> Count=" .. mycounter .. m .. "Heap=".. node.heap())
|
|
||||||
end) conn:on("sent",function(conn) conn:close() conn = nil end) end)
|
|
||||||
|
|
||||||
srv=net.createServer(net.TCP) srv:listen(80,function(conn) conn:on("receive",function(conn,payload)
|
|
||||||
conn:send("HTTP/1.1 200 OK\r\n") conn:send("Connection: close\r\n\r\n") conn:send("<h1> Hello, NodeMcu.</h1>")
|
|
||||||
print(node.heap()) conn:close() end) end)
|
|
||||||
|
|
||||||
|
|
||||||
conn=net.createConnection(net.TCP)
|
|
||||||
conn:dns("www.nodemcu.com",function(conn,ip) print(ip) print("hell") end)
|
|
||||||
|
|
||||||
function connected(conn) conn:on("receive",function(conn,payload)
|
|
||||||
conn:send("HTTP/1.1 200 OK\r\n") conn:send("Connection: close\r\n\r\n") conn:send("<h1> Hello, NodeMcu.</h1>")
|
|
||||||
print(node.heap()) conn:close() end) end
|
|
||||||
srv=net.createServer(net.TCP)
|
|
||||||
srv:on("connection",function(conn) conn:on("receive",function(conn,payload)
|
|
||||||
conn:send("HTTP/1.1 200 OK\r\n") conn:send("Connection: close\r\n\r\n") conn:send("<h1> Hello, NodeMcu.</h1>")
|
|
||||||
print(node.heap()) conn:close() end) end)
|
|
||||||
srv:listen(80)
|
|
||||||
|
|
||||||
|
|
||||||
-- sieve.lua
|
|
||||||
-- the sieve of Eratosthenes programmed with coroutines
|
|
||||||
-- typical usage: lua -e N=500 sieve.lua | column
|
|
||||||
|
|
||||||
-- generate all the numbers from 2 to n
|
|
||||||
function gen (n) return coroutine.wrap(function () for i=2,n do coroutine.yield(i) end end) end
|
|
||||||
|
|
||||||
-- filter the numbers generated by `g', removing multiples of `p'
|
|
||||||
function filter (p, g) return coroutine.wrap(function () for n in g do if n%p ~= 0 then coroutine.yield(n) end end end) end
|
|
||||||
|
|
||||||
N=N or 500 -- from command line
|
|
||||||
x = gen(N) -- generate primes up to N
|
|
||||||
while 1 do
|
|
||||||
local n = x() -- pick a number until done
|
|
||||||
if n == nil then break end
|
|
||||||
print(n) -- must be a prime number
|
|
||||||
x = filter(n, x) -- now remove its multiples
|
|
||||||
end
|
|
||||||
|
|
||||||
file.remove("mylistener.lua")
|
|
||||||
file.open("mylistener.lua","w")
|
|
||||||
file.writeline([[gpio2 = 9]])
|
|
||||||
file.writeline([[gpio0 = 8]])
|
|
||||||
file.writeline([[gpio.mode(gpio2,gpio.OUTPUT)]])
|
|
||||||
file.writeline([[gpio.write(gpio2,gpio.LOW)]])
|
|
||||||
file.writeline([[gpio.mode(gpio0,gpio.OUTPUT)]])
|
|
||||||
file.writeline([[gpio.write(gpio0,gpio.LOW)]])
|
|
||||||
file.writeline([[l1="0\n"]])
|
|
||||||
file.writeline([[l2="0\n"]])
|
|
||||||
file.writeline([[l3="0\n"]])
|
|
||||||
file.writeline([[l4="0\n"]])
|
|
||||||
file.writeline([[sv=net.createServer(net.TCP, 5) ]])
|
|
||||||
file.writeline([[sv:listen(4000,function(c)]])
|
|
||||||
file.writeline([[c:on("disconnection", function(c) print("Bye") end )]])
|
|
||||||
file.writeline([[c:on("receive", function(sck, pl) ]])
|
|
||||||
-- file.writeline([[print(pl) ]])
|
|
||||||
file.writeline([[if (pl=="GO1\n") then c:send(l1) ]])
|
|
||||||
file.writeline([[elseif pl=="GO2\n" then c:send(l2) ]])
|
|
||||||
file.writeline([[elseif pl=="GO3\n" then c:send(l3) ]])
|
|
||||||
file.writeline([[elseif pl=="GO4\n" then c:send(l4) ]])
|
|
||||||
file.writeline([[elseif pl=="YES1\n" then l1="1\n" c:send("OK\n") gpio.write(gpio2,gpio.HIGH) ]])
|
|
||||||
file.writeline([[elseif pl=="NO1\n" then l1="0\n" c:send("OK\n") gpio.write(gpio2,gpio.LOW) ]])
|
|
||||||
file.writeline([[elseif pl=="YES2\n" then l2="1\n" c:send("OK\n") gpio.write(gpio0,gpio.HIGH) ]])
|
|
||||||
file.writeline([[elseif pl=="NO2\n" then l2="0\n" c:send("OK\n") gpio.write(gpio0,gpio.LOW) ]])
|
|
||||||
file.writeline([[elseif pl=="YES3\n" then l3="1\n" c:send("OK\n") print(node.heap()) ]])
|
|
||||||
file.writeline([[elseif pl=="NO3\n" then l3="0\n" c:send("OK\n") print(node.heap()) ]])
|
|
||||||
file.writeline([[elseif pl=="YES4\n" then l4="1\n" c:send("OK\n") print(node.heap()) ]])
|
|
||||||
file.writeline([[elseif pl=="NO4\n" then l4="0\n" c:send("OK\n") print(node.heap()) ]])
|
|
||||||
file.writeline([[else c:send("0\n") print(node.heap()) ]])
|
|
||||||
file.writeline([[end]])
|
|
||||||
file.writeline([[end)]])
|
|
||||||
file.writeline([[end)]])
|
|
||||||
file.close()
|
|
||||||
|
|
||||||
file.remove("myli.lua") file.open("myli.lua","w")
|
|
||||||
file.writeline([[sv=net.createServer(net.TCP, 5) ]])
|
|
||||||
file.writeline([[sv:listen(4000,function(c)]])
|
|
||||||
file.writeline([[c:on("disconnection", function(c) print("Bye") end )]])
|
|
||||||
--file.writeline([[c:on("sent", function(c) c:close() end )]])
|
|
||||||
file.writeline([[c:on("receive", function(sck, pl) ]])
|
|
||||||
file.writeline([[sck:send("0\n") print(node.heap()) ]])
|
|
||||||
file.writeline([[end)]]) file.writeline([[end)]]) file.close()
|
|
||||||
|
|
||||||
sv=net.createServer(net.TCP, 50) sv:listen(4000,function(c) c:on("disconnection",function(c) print("Bye") end)
|
|
||||||
c:on("receive", function(sck, pl) sck:send("0\n") print(node.heap()) end) end)
|
|
||||||
|
|
||||||
sv=net.createServer(net.TCP, 5) sv:listen(4000,function(c) c:on("disconnection",function(c) print("Bye") end)
|
|
||||||
c:on("receive", function(sck, pl) sck:send("0\n") print(node.heap()) end) c:on("sent", function(sck) sck:close() end) end)
|
|
||||||
|
|
||||||
s=net.createServer(net.UDP)
|
|
||||||
s:on("receive",function(s,c) print(c) end)
|
|
||||||
s:listen(8888)
|
|
||||||
|
|
||||||
print("This is a long long long line to test the memory limit of nodemcu firmware\n")
|
|
||||||
collectgarbage("setmemlimit",8)
|
|
||||||
print(collectgarbage("getmemlimit"))
|
|
||||||
|
|
||||||
tmr.alarm(1,5000,1,function() print("alarm 1") end)
|
|
||||||
tmr.stop(1)
|
|
||||||
|
|
||||||
tmr.alarm(0,1000,1,function() print("alarm 0") end)
|
|
||||||
tmr.stop(0)
|
|
||||||
|
|
||||||
tmr.alarm(2,2000,1,function() print("alarm 2") end)
|
|
||||||
tmr.stop(2)
|
|
||||||
|
|
||||||
tmr.alarm(6,2000,1,function() print("alarm 6") end)
|
|
||||||
tmr.stop(6)
|
|
||||||
|
|
||||||
for k,v in pairs(_G.package.loaded) do print(k) end
|
|
||||||
for k,v in pairs(_G) do print(k) end
|
|
||||||
for k,v in pairs(d) do print("n:"..k..", s:"..v) end
|
|
||||||
|
|
||||||
a="pin=9"
|
|
||||||
t={}
|
|
||||||
for k, v in string.gmatch(a, "(%w+)=(%w+)") do t[k]=v end
|
|
||||||
print(t["pin"])
|
|
||||||
|
|
||||||
function switch() gpio.mode(4,gpio.OUTPUT) gpio.mode(5,gpio.OUTPUT) tmr.delay(1000000) print("hello world") end
|
|
||||||
tmr.alarm(0,10000,0,function () uart.setup(0,9600,8,0,1) end) switch()
|
|
||||||
|
|
||||||
sk=net.createConnection(net.TCP, 0) sk:on("receive", function(sck, c) print(c) end ) sk:connect(80,"www.nodemcu.com") sk:send("GET / HTTP/1.1\r\nHost: www.nodemcu.com\r\nConnection: keep-alive\r\nAccept: */*\r\n\r\n")
|
|
||||||
|
|
||||||
sk=net.createConnection(net.TCP, 0) sk:on("receive", function(sck, c) print(c) end )
|
|
||||||
sk:on("connection", function(sck) sck:send("GET / HTTP/1.1\r\nHost: www.nodemcu.com\r\nConnection: keep-alive\r\nAccept: */*\r\n\r\n") end ) sk:connect(80,"www.nodemcu.com")
|
|
||||||
|
|
||||||
|
|
||||||
sk=net.createConnection(net.TCP, 0) sk:on("receive", function(sck, c) print(c) end ) sk:connect(80,"115.239.210.27")
|
|
||||||
sk:send("GET / HTTP/1.1\r\nHost: 115.239.210.27\r\nConnection: keep-alive\r\nAccept: */*\r\n\r\n")
|
|
||||||
|
|
||||||
sk=net.createConnection(net.TCP, 1) sk:on("receive", function(sck, c) print(c) end )
|
|
||||||
sk:on("connection", function(sck) sck:send("GET / HTTPS/1.1\r\nHost: www.google.com.hk\r\nConnection: keep-alive\r\nAccept: */*\r\n\r\n") end ) sk:connect(443,"173.194.72.199")
|
|
||||||
|
|
||||||
wifi.sta.setip({ip="192.168.18.119",netmask="255.255.255.0",gateway="192.168.18.1"})
|
|
||||||
|
|
||||||
uart.on("data","\r",function(input) if input=="quit\r" then uart.on("data") else print(input) end end, 0)
|
|
||||||
uart.on("data","\n",function(input) if input=="quit\n" then uart.on("data") else print(input) end end, 0)
|
|
||||||
uart.on("data", 5 ,function(input) if input=="quit\r" then uart.on("data") else print(input) end end, 0)
|
|
||||||
uart.on("data", 0 ,function(input) if input=="q" then uart.on("data") else print(input) end end, 0)
|
|
||||||
|
|
||||||
uart.on("data","\r",function(input) if input=="quit" then uart.on("data") else print(input) end end, 1)
|
|
||||||
|
|
||||||
for k, v in pairs(file.list()) do print('file:'..k..' len:'..v) end
|
|
||||||
|
|
||||||
m=mqtt.Client()
|
|
||||||
m:connect("192.168.18.101",1883)
|
|
||||||
m:subscribe("/topic",0,function(m) print("sub done") end)
|
|
||||||
m:on("message",function(m,t,pl) print(t..":") if pl~=nil then print(pl) end end )
|
|
||||||
m:publish("/topic","hello",0,0)
|
|
||||||
|
|
||||||
uart.setup(0,9600,8,0,1,0)
|
|
||||||
sv=net.createServer(net.TCP, 60)
|
|
||||||
global_c = nil
|
|
||||||
sv:listen(9999, function(c)
|
|
||||||
if global_c~=nil then
|
|
||||||
global_c:close()
|
|
||||||
end
|
|
||||||
global_c=c
|
|
||||||
c:on("receive",function(sck,pl) uart.write(0,pl) end)
|
|
||||||
end)
|
|
||||||
|
|
||||||
uart.on("data",4, function(data)
|
|
||||||
if global_c~=nil then
|
|
||||||
global_c:send(data)
|
|
||||||
end
|
|
||||||
end, 0)
|
|
||||||
|
|
||||||
file.open("hello.lua","w+")
|
|
||||||
file.writeline([[print("hello nodemcu")]])
|
|
||||||
file.writeline([[print(node.heap())]])
|
|
||||||
file.close()
|
|
||||||
|
|
||||||
node.compile("hello.lua")
|
|
||||||
dofile("hello.lua")
|
|
||||||
dofile("hello.lc")
|
|
||||||
|
|
||||||
-- use copper addon for firefox
|
|
||||||
cs=coap.Server()
|
|
||||||
cs:listen(5683)
|
|
||||||
|
|
||||||
myvar=1
|
|
||||||
cs:var("myvar") -- get coap://192.168.18.103:5683/v1/v/myvar will return the value of myvar: 1
|
|
||||||
|
|
||||||
-- function should tack one string, return one string.
|
|
||||||
function myfun(payload)
|
|
||||||
print("myfun called")
|
|
||||||
respond = "hello"
|
|
||||||
return respond
|
|
||||||
end
|
|
||||||
cs:func("myfun") -- post coap://192.168.18.103:5683/v1/f/myfun will call myfun
|
|
||||||
|
|
||||||
cc = coap.Client()
|
|
||||||
cc:get(coap.CON, "coap://192.168.18.100:5683/.well-known/core")
|
|
||||||
cc:post(coap.NON, "coap://192.168.18.100:5683/", "Hello")
|
|
||||||
|
|
||||||
|
|
||||||
file.open("test1.txt", "a+") for i = 1, 100*1000 do file.write("x") end file.close() print("Done.")
|
|
||||||
for n,s in pairs(file.list()) do print(n.." size: "..s) end
|
|
||||||
file.remove("test1.txt")
|
|
||||||
for n,s in pairs(file.list()) do print(n.." size: "..s) end
|
|
||||||
file.open("test2.txt", "a+") for i = 1, 1*1000 do file.write("x") end file.close() print("Done.")
|
|
||||||
|
|
||||||
|
|
||||||
function TestDNSLeak()
|
|
||||||
c=net.createConnection(net.TCP, 0)
|
|
||||||
c:connect(80, "bad-name.tlddfdf")
|
|
||||||
tmr.alarm(1, 3000, 0, function() print("hack socket close, MEM: "..node.heap()) c:close() end) -- socket timeout hack
|
|
||||||
print("MEM: "..node.heap())
|
|
||||||
end
|
|
||||||
|
|
||||||
v="abc%0D%0Adef"
|
|
||||||
print(string.gsub(v, "%%(%x%x)", function(x) return string.char(tonumber(x, 16)) end))
|
|
||||||
|
|
||||||
function ex(x) string.find("abc%0Ddef","bc") return 's' end
|
|
||||||
string.gsub("abc%0Ddef", "%%(%x%x)", ex)
|
|
||||||
|
|
||||||
function ex(x) string.char(35) return 's' end
|
|
||||||
string.gsub("abc%0Ddef", "%%(%x%x)", ex) print("hello")
|
|
||||||
|
|
||||||
function ex(x) string.lower('Ab') return 's' end
|
|
||||||
string.gsub("abc%0Ddef", "%%(%x%x)", ex) print("hello")
|
|
||||||
|
|
||||||
v="abc%0D%0Adef"
|
|
||||||
pcall(function() print(string.gsub(v, "%%(%x%x)", function(x) return string.char(tonumber(x, 16)) end)) end)
|
|
||||||
|
|
||||||
mosca -v | bunyan
|
|
||||||
|
|
||||||
m=mqtt.Client()
|
|
||||||
m:connect("192.168.18.88",1883)
|
|
||||||
topic={}
|
|
||||||
topic["/topic1"]=0
|
|
||||||
topic["/topic2"]=0
|
|
||||||
m:subscribe(topic,function(m) print("sub done") end)
|
|
||||||
m:on("message",function(m,t,pl) print(t..":") if pl~=nil then print(pl) end end )
|
|
||||||
m:publish("/topic1","hello",0,0)
|
|
||||||
m:publish("/topic3","hello",0,0) m:publish("/topic4","hello",0,0)
|
|
||||||
|
|
||||||
m=mqtt.Client()
|
|
||||||
m:connect("192.168.18.88",1883)
|
|
||||||
m:subscribe("/topic1",0,function(m) print("sub done") end)
|
|
||||||
m:subscribe("/topic2",0,function(m) print("sub done") end)
|
|
||||||
m:on("message",function(m,t,pl) print(t..":") if pl~=nil then print(pl) end end )
|
|
||||||
m:publish("/topic1","hello",0,0)
|
|
||||||
m:publish("/topic3","hello",0,0) m:publish("/topic4","hello",0,0)
|
|
||||||
m:publish("/topic1","hello1",0,0) m:publish("/topic2","hello2",0,0)
|
|
||||||
m:publish("/topic1","hello",1,0)
|
|
||||||
m:subscribe("/topic3",0,function(m) print("sub done") end)
|
|
||||||
m:publish("/topic3","hello3",2,0)
|
|
||||||
|
|
||||||
m=mqtt.Client()
|
|
||||||
m:connect("192.168.18.88",1883, function(con) print("connected hello") end)
|
|
||||||
|
|
||||||
m=mqtt.Client()
|
|
||||||
m:on("connect",function(m) print("connection") end )
|
|
||||||
m:connect("192.168.18.88",1883)
|
|
||||||
m:on("offline",function(m) print("disconnection") end )
|
|
||||||
|
|
||||||
m=mqtt.Client()
|
|
||||||
m:on("connect",function(m) print("connection "..node.heap()) end )
|
|
||||||
m:on("offline", function(conn)
|
|
||||||
if conn == nil then print("conn is nil") end
|
|
||||||
print("Reconnect to broker...")
|
|
||||||
print(node.heap())
|
|
||||||
conn:connect("192.168.18.88",1883,0,1)
|
|
||||||
end)
|
|
||||||
m:connect("192.168.18.88",1883,0,1)
|
|
||||||
|
|
||||||
m=mqtt.Client()
|
|
||||||
m:on("connect",function(m) print("connection "..node.heap()) end )
|
|
||||||
m:on("offline", function(conn)
|
|
||||||
if conn == nil then print("conn is nil") end
|
|
||||||
print("Reconnect to broker...")
|
|
||||||
print(node.heap())
|
|
||||||
conn:connect("192.168.18.88",1883)
|
|
||||||
end)
|
|
||||||
m:connect("192.168.18.88",1883)
|
|
||||||
|
|
||||||
m:close()
|
|
||||||
|
|
||||||
m=mqtt.Client()
|
|
||||||
m:connect("192.168.18.88",1883)
|
|
||||||
m:on("message",function(m,t,pl) print(t..":") if pl~=nil then print(pl) end end )
|
|
||||||
m:subscribe("/topic1",0,function(m) print("sub done") end)
|
|
||||||
m:publish("/topic1","hello3",2,0) m:publish("/topic1","hello2",2,0)
|
|
||||||
m:publish("/topic1","hello3",0,0) m:publish("/topic1","hello2",2,0)
|
|
||||||
|
|
||||||
m:subscribe("/topic2",2,function(m) print("sub done") end)
|
|
||||||
m:publish("/topic2","hello3",0,0) m:publish("/topic2","hello2",2,0)
|
|
||||||
|
|
||||||
m=mqtt.Client()
|
|
||||||
m:on("connect",function(m)
|
|
||||||
print("connection "..node.heap())
|
|
||||||
m:subscribe("/topic1",0,function(m) print("sub done") end)
|
|
||||||
m:publish("/topic1","hello3",0,0) m:publish("/topic1","hello2",2,0)
|
|
||||||
end )
|
|
||||||
m:on("offline", function(conn)
|
|
||||||
print("disconnect to broker...")
|
|
||||||
print(node.heap())
|
|
||||||
end)
|
|
||||||
m:connect("192.168.18.88",1883,0,1)
|
|
||||||
|
|
||||||
-- serout( pin, firstLevel, delay_table, [repeatNum] )
|
|
||||||
gpio.mode(1,gpio.OUTPUT,gpio.PULLUP)
|
|
||||||
gpio.serout(1,1,{30,30,60,60,30,30}) -- serial one byte, b10110010
|
|
||||||
gpio.serout(1,1,{30,70},8) -- serial 30% pwm 10k, lasts 8 cycles
|
|
||||||
gpio.serout(1,1,{3,7},8) -- serial 30% pwm 100k, lasts 8 cycles
|
|
||||||
gpio.serout(1,1,{0,0},8) -- serial 50% pwm as fast as possible, lasts 8 cycles
|
|
||||||
|
|
||||||
gpio.mode(1,gpio.OUTPUT,gpio.PULLUP)
|
|
||||||
gpio.serout(1,0,{20,10,10,20,10,10,10,100}) -- sim uart one byte 0x5A at about 100kbps
|
|
||||||
|
|
||||||
gpio.serout(1,1,{8,18},8) -- serial 30% pwm 38k, lasts 8 cycles
|
|
||||||
|
|
||||||
-- Lua: mqtt.Client(clientid, keepalive, user, pass)
|
|
||||||
-- test with cloudmqtt.com
|
|
||||||
m_dis={}
|
|
||||||
function dispatch(m,t,pl)
|
|
||||||
if pl~=nil and m_dis[t] then
|
|
||||||
m_dis[t](pl)
|
|
||||||
end
|
|
||||||
end
|
|
||||||
function topic1func(pl)
|
|
||||||
print("get1: "..pl)
|
|
||||||
end
|
|
||||||
function topic2func(pl)
|
|
||||||
print("get2: "..pl)
|
|
||||||
end
|
|
||||||
m_dis["/topic1"]=topic1func
|
|
||||||
m_dis["/topic2"]=topic2func
|
|
||||||
m=mqtt.Client("nodemcu1",60,"test","test123")
|
|
||||||
m:on("connect",function(m)
|
|
||||||
print("connection "..node.heap())
|
|
||||||
m:subscribe("/topic1",0,function(m) print("sub done") end)
|
|
||||||
m:subscribe("/topic2",0,function(m) print("sub done") end)
|
|
||||||
m:publish("/topic1","hello",0,0) m:publish("/topic2","world",0,0)
|
|
||||||
end )
|
|
||||||
m:on("offline", function(conn)
|
|
||||||
print("disconnect to broker...")
|
|
||||||
print(node.heap())
|
|
||||||
end)
|
|
||||||
m:on("message",dispatch )
|
|
||||||
m:connect("m11.cloudmqtt.com",11214,0,1)
|
|
||||||
-- Lua: mqtt:connect( host, port, secure, auto_reconnect, function(client) )
|
|
||||||
|
|
||||||
tmr.alarm(0,10000,1,function() local pl = "time: "..tmr.time()
|
|
||||||
m:publish("/topic1",pl,0,0)
|
|
||||||
end)
|
|
||||||
|
|
@ -1,18 +0,0 @@
|
||||||
--init.lua, something like this
|
|
||||||
countdown = 3
|
|
||||||
tmr.alarm(0,1000,1,function()
|
|
||||||
print(countdown)
|
|
||||||
countdown = countdown-1
|
|
||||||
if countdown<1 then
|
|
||||||
tmr.stop(0)
|
|
||||||
countdown = nil
|
|
||||||
local s,err
|
|
||||||
if file.open("user.lc") then
|
|
||||||
file.close()
|
|
||||||
s,err = pcall(function() dofile("user.lc") end)
|
|
||||||
else
|
|
||||||
s,err = pcall(function() dofile("user.lua") end)
|
|
||||||
end
|
|
||||||
if not s then print(err) end
|
|
||||||
end
|
|
||||||
end)
|
|
||||||
|
|
@ -1 +0,0 @@
|
||||||
print("hello NodeMCU")
|
|
||||||
Loading…
Reference in New Issue