Go to file
Nathaniel Wesley Filardo dcc1ea2a49 A generic fifo and fifosock wrapper, under telnet and http server (#2650)
* lua_modules/fifo: a generic queue & socket wrapper

One occasionally wants a generic fifo, so here's a plausible
implementation that's reasonably flexible in its usage.

One possible consumer of this is a variant of TerryE's two-level fifo
trick currently in the telnetd example.  Factor that out to fifosock for
more general use.

* lua_examples/telnet: use factored out fifosock

* lua_modules/http: improve implementation

Switch to fifosock for in-order sending and waiting for everything to be
sent before closing.

Fix header callback by moving the invocation of the handler higher

* fifosock: optimistically cork and delay tx

If we just pushed a little bit of data into a fifosock that had idled,
wait a tick (1 ms) before transmitting.  Hopefully, this means that
we let the rest of the system push more data in before we send the first
packet.  But in a high-throughput situation, where we are streaming data
without idling the fifo, there won't be any additional delay and we'll
coalesce during operation as usual.

The fifosocktest mocks up enough of tmr for this to run, but assumes
an arbitrarily slow processor. ;)
2019-02-16 13:51:40 +01:00
.github Adjust docs path 2019-02-05 21:07:21 +01:00
app MQTT: print deprecation message regardless of autoreconnect value (#2668) 2019-02-14 23:32:16 +01:00
bin Update to sdk 2.2 2018-03-13 19:28:11 -04:00
docs A generic fifo and fifosock wrapper, under telnet and http server (#2650) 2019-02-16 13:51:40 +01:00
ld LFS patch updates following review II and testing 2018-06-22 22:29:16 +01:00
local create luac.cross.{integer|float} (#2450) 2018-08-11 18:28:01 +01:00
lua_examples A generic fifo and fifosock wrapper, under telnet and http server (#2650) 2019-02-16 13:51:40 +01:00
lua_modules A generic fifo and fifosock wrapper, under telnet and http server (#2650) 2019-02-16 13:51:40 +01:00
sdk-overrides/include Refactor timer suspend portion of node.sleep (pmsleep) (#2287) 2018-04-13 21:41:14 +02:00
tools set default value for summary var to unbreak standalone builds (#2618) 2019-01-24 21:29:32 +01:00
.gdbinit LFS patch updates following review 2018-04-19 16:27:47 +01:00
.gdbinitlua LFS patch updates following review 2018-04-19 16:27:47 +01:00
.gitignore Download pre-built toolchains (#2545) 2018-12-03 13:24:19 +11:00
.gitmodules Submodulify ucg and update to v1.5.2 (#2503) 2018-10-19 21:18:50 +01:00
.travis.yml Download pre-built toolchains (#2545) 2018-12-03 13:24:19 +11:00
CONTRIBUTING.md Mention GitHub Desktop (#2460) 2018-08-15 10:47:21 +02:00
LICENSE update doc 2014-11-21 00:10:01 +08:00
Makefile Reduce default make verbosity (#2583) 2018-12-09 21:39:43 +01:00
README.md Mention LFS in intro 2018-07-24 23:16:58 +02:00
mkdocs.yml A generic fifo and fifosock wrapper, under telnet and http server (#2650) 2019-02-16 13:51:40 +01:00
rtd-requirements.txt Update comments 2018-06-30 21:50:38 +02:00

README.md

NodeMCU 2.2.1

Join the chat at https://gitter.im/nodemcu/nodemcu-firmware Build Status Documentation Status License

A Lua based firmware for ESP8266 WiFi SOC

NodeMCU is an open source Lua based firmware for the ESP8266 WiFi SOC from Espressif and uses an on-module flash-based SPIFFS file system. NodeMCU is implemented in C and is layered on the Espressif NON-OS SDK.

The firmware was initially developed as is a companion project to the popular ESP8266-based NodeMCU development modules, but the project is now community-supported, and the firmware can now be run on any ESP module.

Summary

  • Easy to program wireless node and/or access point
  • Based on Lua 5.1.4 (without debug & os modules)
  • Asynchronous event-driven programming model
  • more than 65 built-in modules
  • Firmware available with or without floating point support (integer-only uses less memory)
  • Up-to-date documentation at https://nodemcu.readthedocs.io

LFS support

In July 2018 support for a Lua Flash Store (LFS) was introduced. LFS allows Lua code and its associated constant data to be executed directly out of flash-memory; just as the firmware itself is executed. This now enables NodeMCU developers to create Lua applications with up to 256Kb Lua code and read-only constants executing out of flash. All of the RAM is available for read-write data!

Programming Model

The NodeMCU programming model is similar to that of Node.js, only in Lua. It is asynchronous and event-driven. Many functions, therefore, have parameters for callback functions. To give you an idea what a NodeMCU program looks like study the short snippets below. For more extensive examples have a look at the /lua_examples folder in the repository on GitHub.

-- a simple HTTP server
srv = net.createServer(net.TCP)
srv:listen(80, function(conn)
	conn:on("receive", function(sck, payload)
		print(payload)
		sck:send("HTTP/1.0 200 OK\r\nContent-Type: text/html\r\n\r\n<h1> Hello, NodeMCU.</h1>")
	end)
	conn:on("sent", function(sck) sck:close() end)
end)
-- connect to WiFi access point
wifi.setmode(wifi.STATION)
wifi.sta.config{ssid="SSID", pwd="password"}

Documentation

The entire NodeMCU documentation is maintained right in this repository at /docs. The fact that the API documentation is maintained in the same repository as the code that provides the API ensures consistency between the two. With every commit the documentation is rebuilt by Read the Docs and thus transformed from terse Markdown into a nicely browsable HTML site at https://nodemcu.readthedocs.io.

Releases

Due to the ever-growing number of modules available within NodeMCU, pre-built binaries are no longer made available. Use the automated custom firmware build service to get the specific firmware configuration you need, or consult the documentation for other options to build your own firmware.

This project uses two main branches, master and dev. dev is actively worked on and it's also where PRs should be created against. master thus can be considered "stable" even though there are no automated regression tests. The goal is to merge back to master roughly every 2 months. Depending on the current "heat" (issues, PRs) we accept changes to dev for 5-6 weeks and then hold back for 2-3 weeks before the next snap is completed.

A new tag is created every time dev is merged back to master. They are listed in the releases section here on GitHub. Tag names follow the <SDK-version>-master_yyyymmdd pattern.

Support

See https://nodemcu.readthedocs.io/en/master/en/support/.

License

MIT © zeroday/nodemcu.com