Fix broken links and typos in docs (#2600)
This commit is contained in:
galjonsfigur
Marcel Stör
parent
348b73def1
commit
87b3ffa6bd
|
|
@ -14,7 +14,7 @@ NodeMCU firmware developers commit or contribute to the project on GitHub and mi
|
|||
make
|
||||
```
|
||||
|
||||
The default build setup reduces output verbosity to a minimum. The verbositiy level can be increased by setting the `V` environment variable to 1, e.g. with
|
||||
The default build setup reduces output verbosity to a minimum. The verbosity level can be increased by setting the `V` environment variable to 1, e.g. with
|
||||
```
|
||||
V=1 make
|
||||
```
|
||||
|
|
|
|||
|
|
@ -48,13 +48,13 @@ mode is enabled by specifying the `-f`option.
|
|||
|
||||
`luac.cross` supports two separate image formats:
|
||||
|
||||
- **Compact relocatable**. This is selected by the `-f` option. Here the compiler compresses the compiled binary so that image is small for downloading over Wifi/WAN (e.g. a full 64Kb LFS image is compressed down to a 22Kb file.) The LVM processes such image in two passes with the integrity of the image validated on the first, and the LFS itself gets upated on the second. The LVM also checks that the image will fit in the allocated LFS region before loading, but you can also use the `-m` option to throw a compile error if the image is too large, for example `-m 0x10000` will raise an error if the image will not load into a 64Kb regions.
|
||||
- **Compact relocatable**. This is selected by the `-f` option. Here the compiler compresses the compiled binary so that image is small for downloading over Wifi/WAN (e.g. a full 64Kb LFS image is compressed down to a 22Kb file.) The LVM processes such image in two passes with the integrity of the image validated on the first, and the LFS itself gets updated on the second. The LVM also checks that the image will fit in the allocated LFS region before loading, but you can also use the `-m` option to throw a compile error if the image is too large, for example `-m 0x10000` will raise an error if the image will not load into a 64Kb regions.
|
||||
|
||||
- **Absolute**. This is selected by the `-a <baseAddr>` option. Here the compiler fixes all addresses relative to the base address specified. This allows an LFS absolute image to be loaded directly into the ESP flash using a tool such as `esptool.py`.
|
||||
|
||||
These two modes target two separate use cases: the compact relocatable format
|
||||
facilitates simple OTA updates to an LFS based Lua application; the absolute format
|
||||
facilitates factory installation of LFS based applicaitons.
|
||||
facilitates factory installation of LFS based applications.
|
||||
|
||||
Also note that the `app/lua/luac_cross` make and Makefile can be executed to build
|
||||
just the `luac.cross` image. You must first ensure that the following options in
|
||||
|
|
|
|||
|
|
@ -111,7 +111,7 @@ If you need to customize init data then first download the [Espressif SDK 2.2.0]
|
|||
- `0x7fc000` for 8 MB
|
||||
- `0xffc000` for 16 MB, modules like WeMos D1 mini pro
|
||||
|
||||
See "4.1 Non-FOTA Flash Map" and "6.3 RF Initialization Configuration" of the [ESP8266 Getting Started Guide](https://espressif.com/en/support/explore/get-started/esp8266/getting-started-guide) for details on init data addresses and customization.
|
||||
See "4.1 Non-FOTA Flash Map" and "6.3 RF Initialization Configuration" of the [ESP8266 Getting Started Guide](https://www.espressif.com/sites/default/files/documentation/2a-esp8266-sdk_getting_started_guide_en.pdf) for details on init data addresses and customization.
|
||||
|
||||
## Determine flash size
|
||||
|
||||
|
|
|
|||
|
|
@ -36,9 +36,9 @@ You must choose an explicit (non-default) LFS size to enable the use of LFS. Mo
|
|||
|
||||
- For Windows 10 developers, one method of achieving this is to install the [Windows Subsystem for Linux](https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux). The default installation uses the GNU `bash` shell and includes the core GNU utilities. WSL extends the NT kernel to support the direct execution of Linux ELF images, and it can directly run the `luac.cross` and `spiffsimg` that are build as part of the firmware. You will also need the `esptool.py` tool but `python.org` already provides Python releases for Windows. Of course all Windows developers can use the Cygwin environment as this runs on all Windows versions and it also takes up less than ½Gb HDD (WSL takes up around 5Gb).
|
||||
|
||||
- Linux users can just use these tools natively. Windows users can also to do this in a linux VM or use our standard Docker image. Another alternaive is to get yourself a Raspberry Pi or equivalent SBC and use a package like [DietPi](http://www.dietpi.com/) which makes it easy to install the OS, a Webserver and Samba and make the RPi look like a NAS to your PC. It is also straightforward to write a script to automatically recompile a Samba folder after updates and to make the LFS image available on the webservice so that your ESP modules can update themselves OTA using the new `HTTP_OTA.lua` example.
|
||||
- Linux users can just use these tools natively. Windows users can also to do this in a linux VM or use our standard Docker image. Another alternative is to get yourself a Raspberry Pi or equivalent SBC and use a package like [DietPi](http://www.dietpi.com/) which makes it easy to install the OS, a Webserver and Samba and make the RPi look like a NAS to your PC. It is also straightforward to write a script to automatically recompile a Samba folder after updates and to make the LFS image available on the webservice so that your ESP modules can update themselves OTA using the new `HTTP_OTA.lua` example.
|
||||
|
||||
- In principle, only the environment component needed to support applicatin development is `luac.cross`, built by the `app/lua/lua_cross` make. (Some developers might also use the `spiffsimg` exectable, made in the `tools/spifsimg` subdirectory). Both of these components use the host toolchain (that is the compiler and associated utilities), rather than the Xtensa cross-compiler toolchain, so it is therefore straightforward to make under any environment which provides POSIX runtime support, including WSL, MacOS and Cygwin.
|
||||
- In principle, only the environment component needed to support application development is `luac.cross`, built by the `app/lua/lua_cross` make. (Some developers might also use the `spiffsimg` exectable, made in the `tools/spifsimg` subdirectory). Both of these components use the host toolchain (that is the compiler and associated utilities), rather than the Xtensa cross-compiler toolchain, so it is therefore straightforward to make under any environment which provides POSIX runtime support, including WSL, MacOS and Cygwin.
|
||||
|
||||
Most Lua developers seem to start with the [ESPlorer](https://github.com/4refr0nt/ESPlorer) tool, a 'simple to use' IDE that enables beginning Lua developers to get started. ESPlorer can be slow cumbersome for larger ESP application, and it requires a direct UART connection. So many experienced Lua developers switch to a rapid development cycle where they use a development machine to maintain your master Lua source. Going this route will allow you use your favourite program editor and source control, with one of various techniques for compiling the lua on-host and downloading the compiled code to the ESP:
|
||||
|
||||
|
|
@ -49,9 +49,9 @@ Most Lua developers seem to start with the [ESPlorer](https://github.com/4refr0n
|
|||
|
||||
- Another option would be to include the FTP and Telnet modules in the base LFS image and to use telnet and FTP to update your system. (Given that a 64Kb LFS can store thousands of lines of Lua, doing this isn't much of an issue.)
|
||||
|
||||
My current practice is to use a small bootstrap `init.lua` file in SPIFFS to connect to WiFi, and also load the `_init` module from LFS to do all of the actual application initialisation. There is a few sec delay whilst connecting to the Wifi, and this delay also acts as a "just in case" when I am developing, as it is enough to allow me to paste a `file.remove('init.lua')` into the UART if my test applicaiton is stuck into a panic loop, or set up a different development path for debugging.
|
||||
My current practice is to use a small bootstrap `init.lua` file in SPIFFS to connect to WiFi, and also load the `_init` module from LFS to do all of the actual application initialisation. There is a few sec delay whilst connecting to the Wifi, and this delay also acts as a "just in case" when I am developing, as it is enough to allow me to paste a `file.remove('init.lua')` into the UART if my test application is stuck into a panic loop, or set up a different development path for debugging.
|
||||
|
||||
Under rare circumstances, for example a power fail during the flashing process, the flash can be left in a part-written state following a `flashreload()`. The Lua RTS start-up sequence will detect this and take the failsafe opton of resetting the LFS to empty, and if this happens then the LFS `_init` function will be unavailable. Your `init.lua` should therefore not assume that the LFS contains any modules (such as `_init`), and should contain logic to detect if LFS reset has occurred and if necessary reload the LFS again. Calling `node.flashindex("_init")()` directly will result in a panic loop in these circumstances. Therefore first check that `node.flashindex("_init")` returns a function or protect the call, `pcall(node.flashindex("_init"))`, and decode the error status to validate that initialisation was successful.
|
||||
Under rare circumstances, for example a power fail during the flashing process, the flash can be left in a part-written state following a `flashreload()`. The Lua RTS start-up sequence will detect this and take the failsafe option of resetting the LFS to empty, and if this happens then the LFS `_init` function will be unavailable. Your `init.lua` should therefore not assume that the LFS contains any modules (such as `_init`), and should contain logic to detect if LFS reset has occurred and if necessary reload the LFS again. Calling `node.flashindex("_init")()` directly will result in a panic loop in these circumstances. Therefore first check that `node.flashindex("_init")` returns a function or protect the call, `pcall(node.flashindex("_init"))`, and decode the error status to validate that initialisation was successful.
|
||||
|
||||
No doubt some standard usecase / templates will be developed by the community over the next six months.
|
||||
|
||||
|
|
@ -176,7 +176,7 @@ In fact, two *white* flavours are used to support incremental working (so this 3
|
|||
The standard LGC algorithm is quite complex and assumes that all GCObjects are RW so that a flag byte within each object can be updated during the mark and sweep processing. LFS introduces GCObjects that are stored in RO memory and are therefore truly RO.
|
||||
The LFS patch therefore modifies the LGC processing to avoid such updates to GCObjects in RO memory, whilst still maintaining overall object integrity, as any attempt to update their content during LGC will result in the firmware crashing with a memory exception; the remainder of this section provides further detail on how this was achieved. The LGC operates two broad phases: **mark** and **sweep**
|
||||
|
||||
- The **mark** phase walks collectable objects by a recursive walk starting at at the LGC roots. (This is referred to as _traverse_.) Any object that is visited in this walk has its colour flipped from *white* to *grey* to denote that it is in use, and it is relinked into a grey list. The grey list is iteratively processed, removing one grey object at a time. Such objects can reference other objects (e.g. a table has many keys and values which can also be collectable objects), so each one is then also traversed and all objects reachable from it are marked, as above. After an object has been traversed, it's turned from grey to black. The LGC will walks all RW collectable objects, traversing the dependents of each in turn. As RW objects can now refer to RO ones, the traverse routines has additinal tests to skip trying to mark any RO LFS references.
|
||||
- The **mark** phase walks collectable objects by a recursive walk starting at at the LGC roots. (This is referred to as _traverse_.) Any object that is visited in this walk has its colour flipped from *white* to *grey* to denote that it is in use, and it is relinked into a grey list. The grey list is iteratively processed, removing one grey object at a time. Such objects can reference other objects (e.g. a table has many keys and values which can also be collectable objects), so each one is then also traversed and all objects reachable from it are marked, as above. After an object has been traversed, it's turned from grey to black. The LGC will walks all RW collectable objects, traversing the dependents of each in turn. As RW objects can now refer to RO ones, the traverse routines has additional tests to skip trying to mark any RO LFS references.
|
||||
|
||||
- The white flavour is flipped just before entering the **sweep** phase. This phase then loops over all collectable objects. Any objects found with previous white are no longer in use, and so can be freed. The 'current' white are kept; this prevents any new objects created during a paused sweep from being accidentally collected before being marked, but this means that it takes two sweeps to free all unused objects. There are other subtleties introduced in this 3-colour algorithm such as barriers and back-tracking to maintain integrity of the LGC, and these also needed extra rules to handle RO GCObjects correclty, but detailed explanation of these is really outside the scope of this paper.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ This FAQ does not aim to help you to learn to program or even how to program in
|
|||
|
||||
## What has changed since the first version of this FAQ?
|
||||
|
||||
The [NodeMCU company](http://NodeMCU.com/index_en.html) was set up by [Zeroday](zeroday@nodemcu.com) to develop and to market a set of Lua firmware-based development boards which employ the Espressif ESP8266 SoC. The initial development of the firmware was done by Zeroday and a colleague, Vowstar, in-house with the firmware being first open-sourced on Github in late 2014. In mid-2015, Zeroday decided to open the firmware development to a wider group of community developers, so the core group of developers now comprises 6 community developers (including this author), and we are also supported by another dozen or so active contributors, and two NodeMCU originators.
|
||||
The [NodeMCU company](https://www.nodemcu.com/index_en.html) was set up by [Zeroday](https://github.com/nodemcu) to develop and to market a set of Lua firmware-based development boards which employ the Espressif ESP8266 SoC. The initial development of the firmware was done by Zeroday and a colleague, Vowstar, in-house with the firmware being first open-sourced on Github in late 2014. In mid-2015, Zeroday decided to open the firmware development to a wider group of community developers, so the core group of developers now comprises 6 community developers (including this author), and we are also supported by another dozen or so active contributors, and two NodeMCU originators.
|
||||
|
||||
This larger active team has allowed us to address most of the outstanding issues present at the first version of this FAQ. These include:
|
||||
|
||||
|
|
@ -35,13 +35,13 @@ The NodeMCU firmware implements Lua 5.1 over the Espressif SDK for its ESP8266 S
|
|||
- 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/LearningLua) 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 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](https://bbs.espressif.com/viewforum.php?f=27).
|
||||
|
||||
### How is NodeMCU Lua different to standard Lua?
|
||||
|
||||
Whilst the Lua standard distribution includes a stand-alone Lua interpreter, Lua itself is primarily an *extension language* that makes no assumptions about a "main" program: Lua works embedded in a host application to provide a powerful, lightweight scripting language for use within the application. This host application can then invoke functions to execute a piece of Lua code, can write and read Lua variables, and can register C functions to be called by Lua code. Through the use of C functions, Lua can be augmented to cope with a wide range of different domains, thus creating customized programming languages sharing a syntactical framework.
|
||||
|
||||
The ESP8266 was designed and is fabricated in China by [Espressif Systems](http://espressif.com/new-sdk-release/). Espressif have also developed and released a companion software development kit (SDK) to enable developers to build practical IoT applications for the ESP8266. The SDK is made freely available to developers in the form of binary libraries and SDK documentation. However this is in a *closed format*, with no developer access to the source files, so anyone developing ESP8266 applications must rely solely on the SDK API (and the somewhat Spartan SDK API documentation). (Note that for the ESP32, Espressif have moved to an open-source approach for its ESP-IDF.)
|
||||
The ESP8266 was designed and is fabricated in China by [Espressif Systems](https://www.espressif.com/). Espressif have also developed and released a companion software development kit (SDK) to enable developers to build practical IoT applications for the ESP8266. The SDK is made freely available to developers in the form of binary libraries and SDK documentation. However this is in a *closed format*, with no developer access to the source files, so anyone developing ESP8266 applications must rely solely on the SDK API (and the somewhat Spartan SDK API documentation). (Note that for the ESP32, Espressif have moved to an open-source approach for its ESP-IDF.)
|
||||
|
||||
The NodeMCU Lua firmware is an ESP8266 application and must therefore be layered over the ESP8266 SDK. However, the hooks and features of Lua enable it to be seamlessly integrated without losing any of the standard Lua language features. The firmware has replaced some standard Lua modules that don't align well with the SDK structure with ESP8266-specific versions. For example, the standard `io` and `os` libraries don't work, but have been largely replaced by the NodeMCU `node` and `file` libraries. The `debug` and `math` libraries have also been omitted to reduce the runtime footprint (`modulo` can be done via `%`, `power` via `^`). Note that the `io.write()` function described in Lua's [Simple I/O Model](https://www.lua.org/pil/21.1.html) is not replaced by the `file` library. To write to the same serial port that the `print(string)` function uses by default, use `uart.write(0,string)`.
|
||||
|
||||
|
|
@ -289,7 +289,7 @@ Another trick is to poll a spare GPIO input pin in your startup. I do this on my
|
|||
|
||||
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.
|
||||
|
||||
See ["Uploading code" → init.lua](upload.md#initlua) for a very detaild example.
|
||||
See ["Uploading code" → init.lua](upload.md#initlua) for a very detailed example.
|
||||
|
||||
## Compiling and Debugging
|
||||
|
||||
|
|
|
|||
|
|
@ -32,13 +32,13 @@ Function to start HTTP server.
|
|||
#### Notes
|
||||
Callback function has 2 arguments: `req` (request) and `res` (response). The first object holds values:
|
||||
|
||||
- `conn`: `net.server` sub module
|
||||
- `conn`: `net.socket` sub module
|
||||
- `method`: Request method that was used (e.g.`POST` or `GET`)
|
||||
- `url`: Requested URL
|
||||
- `onheader`: value to setup handler function for HTTP headers like `content-type`. Handler function has 3 parameters:
|
||||
|
||||
- `self`: `req` object
|
||||
- `name`: Hearder name
|
||||
- `name`: Header name
|
||||
- `value`: Header value
|
||||
|
||||
- `ondata`: value to setup handler function HTTP data. Handler function has 2 parameters:
|
||||
|
|
|
|||
|
|
@ -148,7 +148,7 @@ Test if a given bit is cleared.
|
|||
- `position` bit position to test
|
||||
|
||||
#### Returns
|
||||
true if the bit at the given position is 0, false othewise
|
||||
true if the bit at the given position is 0, false otherwise
|
||||
|
||||
### Example
|
||||
```lua
|
||||
|
|
|
|||
|
|
@ -108,7 +108,7 @@ Starts readout (turns the sensor into forced mode). After the readout the sensor
|
|||
`bme280.startreadout(delay, callback)`
|
||||
|
||||
#### Parameters
|
||||
- `delay` sets sensor to forced mode and calls the `callback` (if provided) after given number of milliseconds. For 0 the default delay is set to 113ms (sufficient time to perform reading for oversampling settings 16x). For different oversampling setting please refer to [BME280 Final Datasheet - Appendix B: Measurement time and current calculation](http://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BME280_DS001-11.pdf#page=51).
|
||||
- `delay` sets sensor to forced mode and calls the `callback` (if provided) after given number of milliseconds. For 0 the default delay is set to 113ms (sufficient time to perform reading for oversampling settings 16x). For different oversampling setting please refer to [BME280 Final Datasheet - Appendix B: Measurement time and current calculation](https://ae-bst.resource.bosch.com/media/_tech/media/datasheets/BST-BME280-DS002.pdf#page=51).
|
||||
- `callback` if provided it will be invoked after given `delay`. The sensor reading should be finalized by then so.
|
||||
|
||||
#### Returns
|
||||
|
|
@ -128,8 +128,8 @@ Initializes module. Initialization is mandatory before read values.
|
|||
- (optional) `humi_oss` - Controls oversampling of humidity data. Default oversampling is 16x
|
||||
- (optional) `sensor_mode` - Controls the sensor mode of the device. Default sensor more is normal.
|
||||
- (optional) `inactive_duration` - Controls inactive duration in normal mode. Default inactive duration is 20ms.
|
||||
- (optional) `IIR_filter` - Controls the time constant of the IIR filter. Default fitler coefficient is 16.
|
||||
- (optional) `cold_start` - If 0 then the BME280 chip is not initialised. Usefull in a battery operated setup when the ESP deep sleeps and on wakeup needs to initialise the driver (the module) but not the chip itself. The chip was kept powered (sleeping too) and is holding the latest reading that should be fetched quickly before another reading starts (`bme280.startreadout()`). By default the chip is initialised.
|
||||
- (optional) `IIR_filter` - Controls the time constant of the IIR filter. Default filter coefficient is 16.
|
||||
- (optional) `cold_start` - If 0 then the BME280 chip is not initialised. Useful in a battery operated setup when the ESP deep sleeps and on wakeup needs to initialise the driver (the module) but not the chip itself. The chip was kept powered (sleeping too) and is holding the latest reading that should be fetched quickly before another reading starts (`bme280.startreadout()`). By default the chip is initialised.
|
||||
|
||||
|`temp_oss`, `press_oss`, `humi_oss`|Data oversampling|
|
||||
|-----|-----------------|
|
||||
|
|
|
|||
|
|
@ -103,8 +103,8 @@ Initializes module. Initialization is mandatory before read values.
|
|||
- (optional) `humi_oss` - Controls oversampling of humidity data. Default oversampling is 1x
|
||||
- (optional) `heater_temp` -
|
||||
- (optional) `heater_duration` -
|
||||
- (optional) `IIR_filter` - Controls the time constant of the IIR filter. Default fitler coefficient is 31.
|
||||
- (optional) `cold_start` - If 0 then the bme680 chip is not initialised. Usefull in a battery operated setup when the ESP deep sleeps and on wakeup needs to initialise the driver (the module) but not the chip itself. The chip was kept powered (sleeping too) and is holding the latest reading that should be fetched quickly before another reading starts (`bme680.startreadout()`). By default the chip is initialised.
|
||||
- (optional) `IIR_filter` - Controls the time constant of the IIR filter. Default filter coefficient is 31.
|
||||
- (optional) `cold_start` - If 0 then the bme680 chip is not initialised. Useful in a battery operated setup when the ESP deep sleeps and on wakeup needs to initialise the driver (the module) but not the chip itself. The chip was kept powered (sleeping too) and is holding the latest reading that should be fetched quickly before another reading starts (`bme680.startreadout()`). By default the chip is initialised.
|
||||
|
||||
|`temp_oss`, `press_oss`, `humi_oss`|Data oversampling|
|
||||
|-----|-----------------|
|
||||
|
|
|
|||
|
|
@ -170,7 +170,7 @@ none
|
|||
|
||||
## coap.server:var()
|
||||
|
||||
Registers a Lua variable as an endpoint in the server. the variable value then can be retrieved by a client via GET method, represented as an [URI](http://tools.ietf.org/html/rfc7252#section-6) to the client. The endpoint path for varialble is '/v1/v/'.
|
||||
Registers a Lua variable as an endpoint in the server. the variable value then can be retrieved by a client via GET method, represented as an [URI](http://tools.ietf.org/html/rfc7252#section-6) to the client. The endpoint path for variable is '/v1/v/'.
|
||||
|
||||
#### Syntax
|
||||
`coap.server:var(name[, content_type])`
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ Decrypts previously encrypted data.
|
|||
- `algo` the name of a supported encryption algorithm to use
|
||||
- `key` the encryption key as a string; for AES encryption this *MUST* be 16 bytes long
|
||||
- `cipher` the cipher text to decrypt (as obtained from `crypto.encrypt()`)
|
||||
- `iv` the initilization vector, if using AES-CBC; defaults to all-zero if not given
|
||||
- `iv` the initialization vector, if using AES-CBC; defaults to all-zero if not given
|
||||
|
||||
#### Returns
|
||||
The decrypted string.
|
||||
|
|
@ -143,7 +143,7 @@ Compute a [HMAC](https://en.wikipedia.org/wiki/Hash-based_message_authentication
|
|||
- `key` key to use for signing, may be a binary string
|
||||
|
||||
#### Returns
|
||||
A binary string containing the HMAC signature. Use [`crypto.toHex()`](#cryptotohex ) to obtain the textual version.
|
||||
A binary string containing the HMAC signature. Use [`crypto.toHex()`](#cryptotohex) to obtain the textual version.
|
||||
|
||||
#### Example
|
||||
```lua
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# DHT Module
|
||||
| Since | Origin / Contributor | Maintainer | Source |
|
||||
| :----- | :-------------------- | :---------- | :------ |
|
||||
| 2015-06-17 | [RobTillaart](https://github.com/RobTillaart/Arduino/tree/master/libraries/DHTlib) | [Vowstar](https://github.com/vowstar) | [dhtlib](../../../app/dhtlib/)|
|
||||
| 2015-06-17 | [RobTillaart](https://github.com/RobTillaart/Arduino/tree/master/libraries/DHTlib) | [Vowstar](https://github.com/vowstar) | [dhtlib](../../../app/dht/)|
|
||||
|
||||
## Constants
|
||||
Constants for various functions.
|
||||
|
|
|
|||
|
|
@ -397,7 +397,7 @@ end
|
|||
|
||||
!!! Attention
|
||||
|
||||
It is recommended to use only one single model within the application. Concurrent use of both models can yield unpredictable behavior: Closing the default file from basic model will also close the correspoding file object. Closing a file from object model will also close the default file if they are the same file.
|
||||
It is recommended to use only one single model within the application. Concurrent use of both models can yield unpredictable behavior: Closing the default file from basic model will also close the corresponding file object. Closing a file from object model will also close the default file if they are the same file.
|
||||
|
||||
!!! Note
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ Read digital loadcell ADC value.
|
|||
`hx711.read(mode)`
|
||||
|
||||
#### Parameters
|
||||
`mode` ADC mode. This parameter is currently ignored and reserved to ensure backward compatability if support for additional modes is added. Currently only channel A @ 128 gain is supported.
|
||||
`mode` ADC mode. This parameter is currently ignored and reserved to ensure backward compatibility if support for additional modes is added. Currently only channel A @ 128 gain is supported.
|
||||
|
||||
|mode | channel | gain |
|
||||
|-----|---------|------|
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ Gets contents of the dac register and EEPROM.
|
|||
* `1` EEPROM write has completed
|
||||
* `por_state` Power-On-Reset status;
|
||||
* `0` The MCP4725 is performing reset and is not ready.
|
||||
* `1` The MCP4725 has sucessfully performed reset.
|
||||
* `1` The MCP4725 has successfully performed reset.
|
||||
|
||||
#### Example
|
||||
```lua
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ This is passed to the success callback and contains useful information about the
|
|||
|
||||
- `offset_s` This is an optional field and contains the number of seconds that the clock was adjusted. This is only present for large (many second) adjustments. Typically, this is only present on the initial sync call.
|
||||
- `offset_us` This is an optional field (but one of `offset_s` and `offset_us` will always be present). This contains the number of microseconds that the clock was adjusted.
|
||||
- `delay_us` This is the round trip delay to the server in microseconds. Thie setting uncertainty is somewhat less than this value.
|
||||
- `delay_us` This is the round trip delay to the server in microseconds. This setting uncertainty is somewhat less than this value.
|
||||
- `stratum` This is the stratum of the server.
|
||||
- `leap` This contains the leap bits from the NTP protocol. 0 means that no leap second is pending, 1 is a pending extra leap second at the end of the UTC month, and 2 is a pending leap second removal at the end of the UTC month.
|
||||
|
||||
|
|
@ -85,7 +85,7 @@ nil
|
|||
## sntp.getoffset
|
||||
|
||||
Gets the offset between the rtc clock and the NTP time. This value should be subtracted from the rtc time to get the NTP time -- which
|
||||
corresponds to wall clock time. If the offset returned has changed from the pervious call, then there has been a leap second inbetween.
|
||||
corresponds to wall clock time. If the offset returned has changed from the previous call, then there has been a leap second inbetween.
|
||||
|
||||
#### Syntax
|
||||
`offset = sntp.getoffset()`
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ Builds an frame defined by Somfy protocol and sends it to the RF transmitter.
|
|||
- `repeat_count` how many times the command is repeated
|
||||
- `call_back` a function to be called after the command is transmitted. Allows chaining commands to set the blinds to a defined position.
|
||||
|
||||
My original remote is [TELIS 4 MODULIS RTS](https://www.somfy.co.uk/products/1810765/telis-4-modulis-rts). This remote is working with the additional info - additional 56 bits that follow data (shortening the Inter-frame gap). It seems that the scrumbling alhorithm has not been revealed yet.
|
||||
My original remote is [TELIS 4 MODULIS RTS](https://www.somfy.co.uk/products/1810765/telis-4-modulis-rts). This remote is working with the additional info - additional 56 bits that follow data (shortening the Inter-frame gap). It seems that the scrambling algorithm has not been revealed yet.
|
||||
|
||||
When I send the `somfy.DOWN` command, repeating the frame twice (which seems to be the standard for a short button press), i.e. `repeat_count` equal to 2, the blinds go only 1 step down. This corresponds to the movement of the wheel on the original remote. The down button on the original remote sends also `somfy.DOWN` command but the additional info is different and this makes the blinds go full down. Fortunately it seems that repeating the frame 16 times makes the blinds go fully down.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
| 2015-01-16 | [Ibrahim Abd Elkader](https://github.com/iabdalkader) | [Arnim Läuger](https://github.com/devsaurus) | [spi.c](../../../app/modules/spi.c)|
|
||||
|
||||
All transactions for sending and receiving are most-significant-bit first and least-significant last.
|
||||
For technical details of the underlying hardware refer to [metalphreak's ESP8266 HSPI articles](http://d.av.id.au/blog/tag/hspi/).
|
||||
For technical details of the underlying hardware refer to [metalphreak's ESP8266 HSPI articles](https://web.archive.org/web/20180425205107/http://d.av.id.au:80/blog/tag/hspi/).
|
||||
|
||||
!!! note
|
||||
|
||||
|
|
@ -151,7 +151,7 @@ spi.set_clock_div(1, old_div)
|
|||
|
||||
## Low Level Hardware Functions
|
||||
The low level functions provide a hardware-centric API for application
|
||||
scenarios that need to excercise more complex SPI transactions. The
|
||||
scenarios that need to exercise more complex SPI transactions. The
|
||||
programming model is built up around the HW send and receive buffers and SPI
|
||||
transactions are initiated with full control over the hardware features.
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
|
||||
This module offers basic facilities to convert Lua values to and from C structs. Its main functions are `struct.pack`, which packs multiple Lua values into a struct-like string; and `struct.unpack`, which unpacks multiple Lua values from a given struct-like string.
|
||||
|
||||
The first argument to both functions is a *format string*, which describes the layout of the structure. The format string is a sequence of conversion elements, which respect the current endianess and the current alignment requirements. Initially, the current endianess is the machine's native endianness and the current alignment requirement is 1 (meaning no alignment at all). You can change these settings with appropriate directives in the format string.
|
||||
The first argument to both functions is a *format string*, which describes the layout of the structure. The format string is a sequence of conversion elements, which respect the current endianness and the current alignment requirements. Initially, the current endianness is the machine's native endianness and the current alignment requirement is 1 (meaning no alignment at all). You can change these settings with appropriate directives in the format string.
|
||||
|
||||
Note that the float and double conversions are only available with a floating point NodeMCU build.
|
||||
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ can mount two needles from the same axis.
|
|||
|
||||
These motors run off 5V (some may work off 3.3V). They draw under 20mA and are designed to be
|
||||
driven directly from MCU pins. Since the nodemcu runs at 3.3V, a level translator is required.
|
||||
An octal translator like the [74LVC4245A](http://www.nxp.com/products/discretes-and-logic/logic/voltage-level-translators/octal-dual-supply-translating-transceiver-3-state-based-on-pip-74lvc4245a:74LVC4245A) can perfom this translation. It also includes all the
|
||||
An octal translator like the [74LVC4245A](https://www.ti.com/lit/ds/symlink/sn74lvc4245a.pdf) can perform this translation. It also includes all the
|
||||
protection diodes required.
|
||||
|
||||
These motors can be driven off three pins, with `pin2` and `pin3` being the same GPIO pin.
|
||||
|
|
@ -32,7 +32,7 @@ This module does not enforce any range limiting.
|
|||
|
||||
## switec.setup()
|
||||
Initialize the nodemcu to talk to a switec X.27 or compatible instrument stepper motor. The default
|
||||
slew rate is set so that it should work for most motors. Some motors can run at 600 degress per second.
|
||||
slew rate is set so that it should work for most motors. Some motors can run at 600 degrees per second.
|
||||
|
||||
#### Syntax
|
||||
`switec.setup(channel, pin1, pin2, pin3, pin4 [, maxDegPerSec])`
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# u8g2 Module
|
||||
| Since | Origin / Contributor | Maintainer | Source |
|
||||
| :----- | :-------------------- | :---------- | :------ |
|
||||
| 2017-06-02 | [Oli Kraus](https://github.com/olikraus/u8glib), [Arnim Läuger](https://github.com/devsaurus) | [Arnim Läuger](https://github.com/devsaurus) | [u8g2.c](../../../apps/modules/u8g2.c)|
|
||||
| 2017-06-02 | [Oli Kraus](https://github.com/olikraus/u8glib), [Arnim Läuger](https://github.com/devsaurus) | [Arnim Läuger](https://github.com/devsaurus) | [u8g2.c](../../../app/modules/u8g2.c)|
|
||||
|
||||
U8g2 is a graphics library developed at [olikraus/u8g2](https://github.com/olikraus/u8g2) with support for many different displays. It is the successor of [U8glib](https://github.com/olikraus/u8glib) which is not developed any further. Please see [How to port U8g code](https://github.com/olikraus/u8g2/wiki/u8gvsu8g2) for generic porting instructions.
|
||||
|
||||
|
|
@ -482,7 +482,7 @@ Draw a XBM Bitmap.
|
|||
|
||||
See [u8g2 drawXBM()](https://github.com/olikraus/u8g2/wiki/u8g2reference#drawxbm).
|
||||
|
||||
XBM bitmaps are supplied as strings to `drawXBM()`. This off-loads all data handling from the u8g2 module to generic methods for binary files. See [graphics_test.lua](../../../lua_examples/u8glib/u8g_graphics_test.lua).
|
||||
XBM bitmaps are supplied as strings to `drawXBM()`. This off-loads all data handling from the u8g2 module to generic methods for binary files. See [graphics_test.lua](../../../lua_examples/u8g2/graphics_test.lua).
|
||||
|
||||
In contrast to the source code based inclusion of XBMs in upstream u8g2 library, it's required to provide precompiled binary files. This can be performed online with [Online-Utility's Image Converter](http://www.online-utility.org/image_converter.jsp): Convert from XBM to MONO format and upload the binary result.
|
||||
|
||||
|
|
|
|||
|
|
@ -48,13 +48,13 @@ The NodeMCU firmware supports a subset of these:
|
|||
- SSD1351
|
||||
- ST7735
|
||||
|
||||
This integration is based on [v1.5.2](https://github.com/olikraus/Ucglib_Arduino/releases/tag/v1.5.2).
|
||||
This integration is based on version [1.5.2](https://github.com/olikraus/Ucglib_Arduino/releases/tag/1.5.2).
|
||||
|
||||
## Overview
|
||||
|
||||
### SPI Connection
|
||||
|
||||
The HSPI module is used ([more information](http://d.av.id.au/blog/esp8266-hardware-spi-hspi-general-info-and-pinout/)), so certain pins are fixed:
|
||||
The HSPI module is used ([more information](https://web.archive.org/web/20180425221055/http://d.av.id.au:80/blog/esp8266-hardware-spi-hspi-general-info-and-pinout/)), so certain pins are fixed:
|
||||
|
||||
* HSPI CLK = GPIO14
|
||||
* HSPI MOSI = GPIO13
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@
|
|||
|
||||
A websocket *client* module that implements [RFC6455](https://tools.ietf.org/html/rfc6455) (version 13) and provides a simple interface to send and receive messages.
|
||||
|
||||
The implementation supports fragmented messages, automatically respondes to ping requests and periodically pings if the server isn't communicating.
|
||||
The implementation supports fragmented messages, automatically responds to ping requests and periodically pings if the server isn't communicating.
|
||||
|
||||
**SSL/TLS support**
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ ws = nil
|
|||
|
||||
## websocket.client:close()
|
||||
|
||||
Closes a websocket connection. The client issues a close frame and attemtps to gracefully close the websocket.
|
||||
Closes a websocket connection. The client issues a close frame and attempts to gracefully close the websocket.
|
||||
If server doesn't reply, the connection is terminated after a small timeout.
|
||||
|
||||
This function can be called even if the websocket isn't connected.
|
||||
|
|
@ -89,7 +89,7 @@ ws:config({headers={['User-Agent']='NodeMCU'}})
|
|||
|
||||
## websocket.client:connect()
|
||||
|
||||
Attempts to estabilish a websocket connection to the given URL.
|
||||
Attempts to establish a websocket connection to the given URL.
|
||||
|
||||
#### Syntax
|
||||
`websocket:connect(url)`
|
||||
|
|
@ -164,7 +164,7 @@ The status code for the close, if not 0 then it represents an error, as describe
|
|||
| -17 | Server is not switching protocols |
|
||||
| -18 | Connect timeout |
|
||||
| -19 | Server is not responding to health checks nor communicating |
|
||||
| -99 to -999 | Well, something bad has happenned |
|
||||
| -99 to -999 | Well, something bad has happened |
|
||||
|
||||
|
||||
## websocket.client:send()
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# WS2801 Module
|
||||
| Since | Origin / Contributor | Maintainer | Source |
|
||||
| :----- | :-------------------- | :---------- | :------ |
|
||||
| 2015-07-12 | [Espressif example](https://github.com/CHERTS/esp8266-devkit/blob/master/Espressif/examples/EspLightNode/user/ws2801.c), [Konrad Beckmann](https://github.com/kbeckmann) | [Konrad Beckmann](https://github.com/kbeckmann) | [ws2801.c](../../../app/modules/ws2801.c)|
|
||||
| 2015-07-12 | [Espressif example](https://github.com/CHERTS/esp8266-devkit/blob/master/Espressif/examples/ESP8266/EspLightNode/user/ws2801.c), [Konrad Beckmann](https://github.com/kbeckmann) | [Konrad Beckmann](https://github.com/kbeckmann) | [ws2801.c](../../../app/modules/ws2801.c)|
|
||||
|
||||
|
||||
## ws2801.init()
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ handle two led strips at the same time.
|
|||
**WARNING**: In dual mode, you will loose access to the Lua's console
|
||||
through the serial port (it will be reconfigured to support WS2812-like
|
||||
protocol). If you want to keep access to Lua's console, you will have to
|
||||
use an other input channel like a TCP server (see [example](https://github.com/nodemcu/nodemcu-firmware/blob/master/lua_examples/telnet.lua))
|
||||
use an other input channel like a TCP server (see [example](https://github.com/nodemcu/nodemcu-firmware/blob/master/lua_examples/telnet/telnet.lua))
|
||||
|
||||
## ws2812.init()
|
||||
Initialize UART1 and GPIO2, should be called once and before write().
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ xpt2046.setCalibration(198, 1776, 1762, 273)
|
|||
|
||||
|
||||
## xpt2046.setCalibration()
|
||||
Sets the calibration of the display. Calibration values can be optained by using [`xpt2046.getRaw()`](#xpt2046getraw) and read the values in the edges.
|
||||
Sets the calibration of the display. Calibration values can be obtained by using [`xpt2046.getRaw()`](#xpt2046getraw) and read the values in the edges.
|
||||
|
||||
#### Syntax
|
||||
`xpt2046.setCalibration(x1, y1, x2, y2)`
|
||||
|
|
|
|||
|
|
@ -69,4 +69,4 @@ Subdirectories are supported on FAT volumes only.
|
|||
|
||||
## Multiple partitions / multiple cards
|
||||
|
||||
The mapping from logical volumes (eg. `/SD0`) to partitions on an SD card is defined in [`fatfs_config.h`](../../app/include/fatfs_config.h). More volumes can be added to the `VolToPart` array with any combination of physical drive number (aka SS/CS pin) and partition number. Their names have to be added to `_VOLUME_STRS` in [`ffconf.h`](../../app/fatfs/ffconf.h) as well.
|
||||
The mapping from logical volumes (eg. `/SD0`) to partitions on an SD card is defined in [`fatfs_config.h`](../../app/include/fatfs_config.h). More volumes can be added to the `VolToPart` array with any combination of physical drive number (aka SS/CS pin) and partition number. Their names have to be added to `_VOLUME_STRS` in [`ffconf.h`](../../../app/fatfs/ffconf.h) as well.
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ f 880 http/favicon.ico
|
|||
# Technical Details
|
||||
|
||||
The SPIFFS configuration is 4k sectors (the only size supported by the SDK) and 8k blocks. 256 byte pages. Magic is enabled and magic_len is also enabled. This allows the firmware to find the start of the filesystem (and also the size).
|
||||
One of the goals is to make the filsystem more persistent across reflashing of the firmware. However, there are still cases
|
||||
One of the goals is to make the filesystem more persistent across reflashing of the firmware. However, there are still cases
|
||||
where spiffs detects a filesystem and uses it when it isn't valid. If you are getting weirdness with the filesystem, then just reformat it.
|
||||
|
||||
There are two significant sizes of flash -- the 512K and 4M (or bigger).
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
NodeMCU is an open source [Lua](https://www.lua.org/) based firmware for the [ESP8266 WiFi SOC from Espressif](http://espressif.com/en/products/esp8266/) and uses an on-module flash-based [SPIFFS](https://github.com/pellepl/spiffs) file system. NodeMCU is implemented in C and is layered on the [Espressif NON-OS SDK](https://github.com/espressif/ESP8266_NONOS_SDK).
|
||||
|
||||
The firmware was initially developed as is a companion project to the popular ESP8266-based [NodeMCU development modules]((https://github.com/nodemcu/nodemcu-devkit-v1.0)), but the project is now community-supported, and the firmware can now be run on _any_ ESP module.
|
||||
The firmware was initially developed as is a companion project to the popular ESP8266-based [NodeMCU development modules](https://github.com/nodemcu/nodemcu-devkit-v1.0), but the project is now community-supported, and the firmware can now be run on _any_ ESP module.
|
||||
|
||||
→ [Getting Started](en/getting-started.md)
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue