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/12/13 08:57] nickandrew [How is coding for the ESP8266 different to standard Lua?] |
nodemcu-unofficial-faq [2016/05/22 13:57] admin old revision restored |
||
|---|---|---|---|
| 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