@@ -11,8 +11,8 @@ generate the bitstream. It can use UART0 routed to TXD0 as well to
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
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/telnet.lua))
## ws2812.init()
...
...
@@ -191,11 +191,11 @@ Returns the contents of the buffer (the pixel values) as a string. This can then
`buffer:dump()`
#### Returns
A string containing the pixel values.
A string containing the pixel values.
#### Example
```lua
locals=buffer:dump()
locals=buffer:dump()
```
## ws2812.buffer:replace()
...
...
@@ -249,7 +249,7 @@ buffer:mix(192, buffer)
## ws2812.buffer:power()
Computes the total energy requirement for the buffer. This is merely the total sum of all the pixel values (which assumes that each color in each
pixel consumes the same amount of power). A real WS2812 (or WS2811) has three constant current drivers of 20mA -- one for each of R, G and B. The
pulse width modulation will cause the *average* current to scale linearly with pixel value.
pulse width modulation will cause the *average* current to scale linearly with pixel value.
#### Syntax
`buffer:power()`
...
...
@@ -271,7 +271,7 @@ end
```
## ws2812.buffer:fade()
Fade in or out. Defaults to out. Multiply or divide each byte of each led with/by the given value. Useful for a fading effect.
Fade in or out. Defaults to out. Multiply or divide each byte of each led with/by the given value. Useful for a fading effect.
#### Syntax
`buffer:fade(value [, direction])`
...
...
@@ -289,15 +289,15 @@ buffer:fade(2)
buffer:fade(2,ws2812.FADE_IN)
```
## ws2812.buffer:shift()
Shift the content of (a piece of) the buffer in positive or negative direction. This allows simple animation effects. A slice of the buffer can be specified by using the
Shift the content of (a piece of) the buffer in positive or negative direction. This allows simple animation effects. A slice of the buffer can be specified by using the
standard start and end offset Lua notation. Negative values count backwards from the end of the buffer.
#### Syntax
`buffer:shift(value [, mode[, i[, j]]])`
#### Parameters
-`value` number of pixels by which to rotate the buffer. Positive values rotate forwards, negative values backwards.
-`mode` is the shift mode to use. Can be one of `ws2812.SHIFT_LOGICAL` or `ws2812.SHIFT_CIRCULAR`. In case of SHIFT\_LOGICAL, the freed pixels are set to 0 (off). In case of SHIFT\_CIRCULAR, the buffer is treated like a ring buffer, inserting the pixels falling out on one end again on the other end. Defaults to SHIFT\_LOGICAL.
-`value` number of pixels by which to rotate the buffer. Positive values rotate forwards, negative values backwards.
-`mode` is the shift mode to use. Can be one of `ws2812.SHIFT_LOGICAL` or `ws2812.SHIFT_CIRCULAR`. In case of SHIFT\_LOGICAL, the freed pixels are set to 0 (off). In case of SHIFT\_CIRCULAR, the buffer is treated like a ring buffer, inserting the pixels falling out on one end again on the other end. Defaults to SHIFT\_LOGICAL.
-`i` is the first offset in the buffer to be affected. Negative values are permitted and count backwards from the end. Default is 1.
-`j` is the last offset in the buffer to be affected. Negative values are permitted and count backwards from the end. Default is -1.
The NodeMCU project uses the [SPIFFS](https://github.com/pellepl/spiffs)
The NodeMCU project uses the [SPIFFS](https://github.com/pellepl/spiffs)
filesystem to store files in the flash chip. The technical details about how this is configured can be found below, along with various build time options.
# spiffsimg - Manipulate SPI Flash File System disk images
...
...
@@ -13,12 +13,12 @@ NodeMCU uses a SPIFFS filesystem that knows how big it is -- i.e. when you build
image, it must fit into the flash chip, and it cannot be expanded once flashed.
It is important to give the `spiffimg` tool the correct size. You can provide either the `-c` option or both the `-U` and `-S` options.
### Syntax
### Syntax
```
spiffsimg -f <filename>
spiffsimg -f <filename>
[-o <offsetfile>]
[-c <size>]
[-c <size>]
[-S <flashsize>]
[-U <usedsize>]
[-d]
...
...
@@ -76,26 +76,26 @@ The SPIFFS configuration is 4k sectors (the only size supported by the SDK) and
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).
There are two significant sizes of flash -- the 512K and 4M (or bigger).
The file system has to start on a 4k boundary, but since it ends on a much bigger boundary (a 16k boundary), it also starts on an 8k boundary. For the small flash chip, there is
not much spare space, so a newly formatted file system will start as low as possible (to get as much space as possible). For the large flash, the
file system will start on a 64k boundary. A newly formatted file system will start between 64k and 128k from the end of the firmware. This means that the file
system will survive lots of reflashing and at least 64k of firmware growth.
The file system has to start on a 4k boundary, but since it ends on a much bigger boundary (a 16k boundary), it also starts on an 8k boundary. For the small flash chip, there is
not much spare space, so a newly formatted file system will start as low as possible (to get as much space as possible). For the large flash, the
file system will start on a 64k boundary. A newly formatted file system will start between 64k and 128k from the end of the firmware. This means that the file
system will survive lots of reflashing and at least 64k of firmware growth.
The standard build process for the firmware builds the `spiffsimg` tool (found in the `tools/spiffsimg` subdirectory).
The top level Makfile also checks if
there is any data in the `local/fs` directory tree, and it will then copy these files
into the flash disk image. Two images will normally be created -- one for the 512k flash part and the other for the 4M flash part. If the data doesn't
into the flash disk image. Two images will normally be created -- one for the 512k flash part and the other for the 4M flash part. If the data doesn't
fit into the 512k part after the firmware is included, then the file will not be generated.
The disk image file is placed into the `bin` directory and it is named `0x<offset>-<size>.bin` where the offset is the location where it should be
The disk image file is placed into the `bin` directory and it is named `0x<offset>-<size>.bin` where the offset is the location where it should be
flashed, and the size is the size of the flash part. It is quite valid (and quicker) to flash the 512k image into a 4M part. However, there will probably be
limited space in the file system for creating new files.
The default configuration will try and build three different file systems for 512KB, 1MB and 4MB flash sizes. The 1MB size is suitable for the ESP8285. This can be overridden by specifying the FLASHSIZE parameter to the makefile.
If the `local/fs` directory is empty, then no flash images will be created (and the ones from the last build will be removed). The `spiffsimg` tool can
then be used to build an image as required.
If the `local/fs` directory is empty, then no flash images will be created (and the ones from the last build will be removed). The `spiffsimg` tool can
then be used to build an image as required.
If no file system is found during platform boot, then a new file system will be formatted. This can take some time on the first boot.
...
...
@@ -108,8 +108,8 @@ Just place the following define in `user_config.h` or some other file that is in
#define SPIFFS_MAX_FILESYSTEM_SIZE 32768
```
This filesystem size limit only affects the formatting of a file system -- if the firm finds an existing valid filesystem (of any size) it will use that. However, if the
filesystem is reformatted from Lua (using file.format()) then the new file system will obey the size limit.
This filesystem size limit only affects the formatting of a file system -- if the firm finds an existing valid filesystem (of any size) it will use that. However, if the
filesystem is reformatted from Lua (using file.format()) then the new file system will obey the size limit.
There is also an option to control the positioning of the SPIFFS file system:
...
...
@@ -117,7 +117,7 @@ There is also an option to control the positioning of the SPIFFS file system:
#define SPIFFS_FIXED_LOCATION 0x100000
```
This specifies that the SPIFFS filesystem starts at 1Mb from the start of the flash. Unless otherwise specified, it will run to the end of the flash (excluding the 16k of space reserved by the SDK).
This specifies that the SPIFFS filesystem starts at 1Mb from the start of the flash. Unless otherwise specified, it will run to the end of the flash (excluding the 16k of space reserved by the SDK).
There is an option that limits the size of the file system to run up to the next 1MB boundary (minus the 16k for the parameter space). This may be useful when dealing with OTA upgrades.
As with [flashing](flash.md) there are several ways to upload code from your computer to the device.
!!! note
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)`. If the device panics and resets at any time, errors will be written to the serial interface at 115'200 bps.
## Tools
...
...
@@ -56,32 +56,32 @@ function startup()
end
end
-- Define WiFi station event callbacks
wifi_connect_event=function(T)
-- Define WiFi station event callbacks
wifi_connect_event=function(T)
print("Connection to AP("..T.SSID..") established!")
print("Waiting for IP address...")
ifdisconnect_ct~=nilthendisconnect_ct=nilend
ifdisconnect_ct~=nilthendisconnect_ct=nilend
end
wifi_got_ip_event=function(T)
wifi_got_ip_event=function(T)
-- Note: Having an IP address does not mean there is internet access!
-- Internet connectivity can be determined with net.dns.resolve().
-- Internet connectivity can be determined with net.dns.resolve().
print("Wifi connection is ready! IP address is: "..T.IP)
print("Startup will resume momentarily, you have 3 seconds to abort.")
print("Waiting...")
print("Waiting...")
tmr.create():alarm(3000,tmr.ALARM_SINGLE,startup)
end
wifi_disconnect_event=function(T)
ifT.reason==wifi.eventmon.reason.ASSOC_LEAVEthen
ifT.reason==wifi.eventmon.reason.ASSOC_LEAVEthen
--the station has disassociated from a previously connected AP
return
return
end
-- total_tries: how many times the station will attempt to connect to the AP. Should consider AP reboot duration.
localtotal_tries=75
print("\nWiFi connection to AP("..T.SSID..") has failed!")
--There are many possible disconnect reasons, the following iterates through
--There are many possible disconnect reasons, the following iterates through
--the list and returns the string corresponding to the disconnect reason.
If you install Lua on your development PC or Laptop, then you can use a standard `lua` environment to develop PC applications and also use the standard `luac` compiler to syntax check _any_ Lua source code. However because of architectural differences between the ESP8266 chipset with its SDK and a standard PC CPU, the system APIs are different and the binary output from the standard PC `luac` cannot be run on the ESP8266.
If you install Lua on your development PC or Laptop, then you can use a standard `lua` environment to develop PC applications and also use the standard `luac` compiler to syntax check _any_ Lua source code. However because of architectural differences between the ESP8266 chipset with its SDK and a standard PC CPU, the system APIs are different and the binary output from the standard PC `luac` cannot be run on the ESP8266.
To address this issue, the standard NodeMCU make now generates a host executable `lua.cross` (or `lua.cross.int` for integer builds) as well as the firmware binary itself. Compiling source on one platform for use on another is known as _cross-compilation_ and this `luac.cross` compiler allows you to compile Lua source files on your PC for downloading onto ESP8266 in a binary format.