nodemcu-unofficial-faq
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Last revision Both sides next revision | ||
|
nodemcu-unofficial-faq [2015/07/22 14:05] terrye |
nodemcu-unofficial-faq [2016/05/22 13:57] admin old revision restored |
||
|---|---|---|---|
| Line 46: | Line 46: | ||
| ==== 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 that 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 [[http://frightanic.com/nodemcu-custom-build/|custom build tool]] that he discusses in [[http://www.esp8266.com/viewtopic.php?f=23&t=3001|this forum topic]]). 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 [[http://frightanic.com/nodemcu-custom-build/|custom build tool]] that he discusses in [[http://www.esp8266.com/viewtopic.php?f=23&t=3001|this forum topic]]). 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. | ||
| Line 73: | Line 73: | ||
| * 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. | * 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 [[#So how is the Lua Registry used and why is this important?|Lua registry]]) to associate application tasks with specific hardware and timer events. These are non-preemptive at an applications level. | * The Lua libraries provide a set of functions for declaring application functions (written in Lua) as callbacks (which are stored in the [[#So how is the Lua Registry used and why is this important?|Lua registry]]) 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. | + | * The Lua libraries work in concert 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. | ||
| Line 111: | Line 111: | ||
| * 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 functions 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. | ||
| Line 335: | Line 335: | ||
| ==== What's the different between DIO and QIO mode? ==== | ==== What's the different between DIO and QIO mode? ==== | ||
| - | <TODO> | + | |
| + | Whether DIO or QIO modes are available depends on the physical connection between the ESP8266 CPU and its onboard flash chip. QIO connects to the flash using 6 pins as compared to DIO's 4, and QIO is twice as fast to read/write as DIO. | ||
| ==== How to use DEVKIT V0.9 on Mac OS X? ==== | ==== How to use DEVKIT V0.9 on Mac OS X? ==== | ||
| <TODO> | <TODO> | ||
| - | ==== How does DEVKIT use DTR and RTS enter download mode? ==== | + | ==== How does DEVKIT use DTR and RTS to enter download mode? ==== |
| <TODO> | <TODO> | ||
nodemcu-unofficial-faq.txt · Last modified: 2017/06/27 00:50 by terrye