MirrorSave
/
nodemcu-firmware
mirror of https://github.com/nodemcu/nodemcu-firmware.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
nodemcu-firmware/components/platform/Kconfig

146 lines
5.9 KiB
Plaintext
Raw Normal View History

idf4: overhaul to new build system, part 1 of 3 Yet to come: - part 2: dealing with deprecated and removed APIs - part 3: making it actually work again
2021-07-15 08:25:25 +02:00
menu "NodeMCU platform config"
config NODEMCU_NODE_DEBUG
bool "Enable NODE_DBG() output"
default "n"
help
Enable debugging output via NODE_DBG(). This is VERY chatty.
For development/debugging use only.
config NODEMCU_NODE_ERR
bool "Enable NODE_ERR() output"
default "y"
help
Enable error reporting via NODE_ERR().
It is recommended to leave this enabled - if it ever produces
output, something has gone seriously wrong and you probably want
to know about it.
Switch to IDF-provided VFS and standard `io` module. The IDF-provided VFS resolves several issues: - The IDF components having a different view of the (virtual) file system compared to the Lua environment. - RTOS task/thread safety. Our legacy VFS was only ever safe to use from the LVM thread, which limited its usability. Upgrading it would have effectively required a reimplementation of the IDF VFS, which would have been a bigger task with larger on-going maintenance issues. - We're no longer needing to maintain our own SPIFFS component. - We're no longer needing to maintain our own FATFS component. - The legacy of the 8266's lack of standard C interface to the file system is no longer holding us back, meaning that we can use the standard Lua `io` module rather than the cobbled-together swiss army knife also known as the file module. Of course, the downside is that we'll either have to declare a backwards breakage in regard to the file module, or provide a Lua shim for the old functions, where applicable. Also included is some necessary integer type fixups in unrelated code, which apparently had depended on some non-standard types in either the SPIFFS or FATFS headers. A memory leak issue in the sdmmc module was also found and fixed while said module got switched over to the Espressif VFS. Module documentation has been updated to match the new reality (and I discovered in some places it wasn't even matching the old reality).
2021-10-20 12:24:09 +02:00
config NODEMCU_DEFAULT_SPIFFS_LABEL
string "Partition label of SPIFFS to mount as default file system"
default ""
idf4: overhaul to new build system, part 1 of 3 Yet to come: - part 2: dealing with deprecated and removed APIs - part 3: making it actually work again
2021-07-15 08:25:25 +02:00
help
Switch to IDF-provided VFS and standard `io` module. The IDF-provided VFS resolves several issues: - The IDF components having a different view of the (virtual) file system compared to the Lua environment. - RTOS task/thread safety. Our legacy VFS was only ever safe to use from the LVM thread, which limited its usability. Upgrading it would have effectively required a reimplementation of the IDF VFS, which would have been a bigger task with larger on-going maintenance issues. - We're no longer needing to maintain our own SPIFFS component. - We're no longer needing to maintain our own FATFS component. - The legacy of the 8266's lack of standard C interface to the file system is no longer holding us back, meaning that we can use the standard Lua `io` module rather than the cobbled-together swiss army knife also known as the file module. Of course, the downside is that we'll either have to declare a backwards breakage in regard to the file module, or provide a Lua shim for the old functions, where applicable. Also included is some necessary integer type fixups in unrelated code, which apparently had depended on some non-standard types in either the SPIFFS or FATFS headers. A memory leak issue in the sdmmc module was also found and fixed while said module got switched over to the Espressif VFS. Module documentation has been updated to match the new reality (and I discovered in some places it wasn't even matching the old reality).
2021-10-20 12:24:09 +02:00
If there are multiple SPIFFS partitions, this setting can
be used to control which partition gets mounted as the
default file system. Leaving it empty defaults to using
the first SPIFFS partition found.
idf4: overhaul to new build system, part 1 of 3 Yet to come: - part 2: dealing with deprecated and removed APIs - part 3: making it actually work again
2021-07-15 08:25:25 +02:00
Switch to IDF-provided VFS and standard `io` module. The IDF-provided VFS resolves several issues: - The IDF components having a different view of the (virtual) file system compared to the Lua environment. - RTOS task/thread safety. Our legacy VFS was only ever safe to use from the LVM thread, which limited its usability. Upgrading it would have effectively required a reimplementation of the IDF VFS, which would have been a bigger task with larger on-going maintenance issues. - We're no longer needing to maintain our own SPIFFS component. - We're no longer needing to maintain our own FATFS component. - The legacy of the 8266's lack of standard C interface to the file system is no longer holding us back, meaning that we can use the standard Lua `io` module rather than the cobbled-together swiss army knife also known as the file module. Of course, the downside is that we'll either have to declare a backwards breakage in regard to the file module, or provide a Lua shim for the old functions, where applicable. Also included is some necessary integer type fixups in unrelated code, which apparently had depended on some non-standard types in either the SPIFFS or FATFS headers. A memory leak issue in the sdmmc module was also found and fixed while said module got switched over to the Espressif VFS. Module documentation has been updated to match the new reality (and I discovered in some places it wasn't even matching the old reality).
2021-10-20 12:24:09 +02:00
config NODEMCU_MAX_OPEN_FILES
int "Maximum number of open files"
idf4: overhaul to new build system, part 1 of 3 Yet to come: - part 2: dealing with deprecated and removed APIs - part 3: making it actually work again
2021-07-15 08:25:25 +02:00
default 4
help
Switch to IDF-provided VFS and standard `io` module. The IDF-provided VFS resolves several issues: - The IDF components having a different view of the (virtual) file system compared to the Lua environment. - RTOS task/thread safety. Our legacy VFS was only ever safe to use from the LVM thread, which limited its usability. Upgrading it would have effectively required a reimplementation of the IDF VFS, which would have been a bigger task with larger on-going maintenance issues. - We're no longer needing to maintain our own SPIFFS component. - We're no longer needing to maintain our own FATFS component. - The legacy of the 8266's lack of standard C interface to the file system is no longer holding us back, meaning that we can use the standard Lua `io` module rather than the cobbled-together swiss army knife also known as the file module. Of course, the downside is that we'll either have to declare a backwards breakage in regard to the file module, or provide a Lua shim for the old functions, where applicable. Also included is some necessary integer type fixups in unrelated code, which apparently had depended on some non-standard types in either the SPIFFS or FATFS headers. A memory leak issue in the sdmmc module was also found and fixed while said module got switched over to the Espressif VFS. Module documentation has been updated to match the new reality (and I discovered in some places it wasn't even matching the old reality).
2021-10-20 12:24:09 +02:00
This sets the maximum number of open files at the same time.
Technically, it's per file system, but the most common use
case only has a single file system (internal SPIFFS) so in
that case it is the number of concurrent files that can be
opened. Raising this limit will incur some extra memory
overhead.
idf4: overhaul to new build system, part 1 of 3 Yet to come: - part 2: dealing with deprecated and removed APIs - part 3: making it actually work again
2021-07-15 08:25:25 +02:00
config NODEMCU_EMBED_LFS
bool "Embed LFS as part of the NodeMCU firmware"
default "n"
help
The LFS (Lua Flash Store) normally has its own partition entry,
and can can be replaced at will. Optionally, the LFS can instead
be permanently embedded into the NodeMCU firmware image itself.
This can be useful for scenarios where over-the-air firmware
upgrades are needed to also bundle Lua code. The major downside
is that once embedded, the LFS can no longer be changed, as
doing so would break the firmware checksums and signatures and
leave the system unable to boot.
The default option is to not embed the LFS, in which case LFS is
looked for in a partition of type 0xC2 and subtype 0x01.
To embed LFS data into firmware, use:
./tools/embed_lfs.sh /path/to/file1.lua /path/to/file2.lua ...
config NODEMCU_EMBEDDED_LFS_SIZE
hex "Embedded LUA Flash Store size"
default 0x0
depends on NODEMCU_EMBED_LFS
help
Embedded LUA Flash Store size. Set to zero to use an LFS partition
instead of embedding the LFS within the NodeMCU firmware itself.
Grabbed latest spiffs + vfs layer from dev branch. Also included the recent LVM fix. Platform flash layer not yet functional.
2016-09-21 09:51:50 +02:00
Make UART buffer sizes configurable. (#3500) Also corrects assumption about number of UARTs available.
2022-01-26 01:32:24 +01:00
menu "UART buffer size configuration"
config NODEMCU_UART_AT_LEAST_2
bool
default y if IDF_TARGET_ESP32
default y if IDF_TARGET_ESP32S2
default y if IDF_TARGET_ESP32S3
default y if IDF_TARGET_ESP32C3
default y if IDF_TARGET_ESP32H2
config NODEMCU_UART_AT_LEAST_3
bool
default y if IDF_TARGET_ESP32
default y if IDF_TARGET_ESP32S3
config NODEMCU_UART_DRIVER_BUF_SIZE_RX0
int "RX buffer size for UART0"
default 512
help
The rx buffer size to use for UART0.
This is a buffer used to/from the UART ISR. For high-speed scenarios,
it can be very helpful to increase the rx size. The ISR trying
to write to a full rx buffer results in lost data and an error
event posted.
config NODEMCU_UART_DRIVER_BUF_SIZE_TX0
int "TX buffer size for UART0"
default 512
help
The tx buffer size to use for UART0.
This is a buffer used to/from the UART ISR. In some scenarios it
can be helpful to increase the tx size. Writing to a full tx buffer
blocks the calling RTOS task.
config NODEMCU_UART_DRIVER_BUF_SIZE_RX1
int "RX buffer size for UART1"
depends on NODEMCU_UART_AT_LEAST_2
default 512
help
The rx buffer size to use for UART1.
This is a buffer used to/from the UART ISR. For high-speed scenarios,
it can be very helpful to increase the rx size. The ISR trying
to write to a full rx buffer results in lost data and an error
event posted.
config NODEMCU_UART_DRIVER_BUF_SIZE_TX1
int "TX buffer size for UART1"
depends on NODEMCU_UART_AT_LEAST_2
default 512
help
The tx buffer size to use for UART1.
This is a buffer used to/from the UART ISR. In some scenarios it
can be helpful to increase the tx size. Writing to a full tx buffer
blocks the calling RTOS task.
config NODEMCU_UART_DRIVER_BUF_SIZE_RX2
int "RX buffer size for UART2"
depends on NODEMCU_UART_AT_LEAST_3
default 512
help
The rx buffer size to use for UART2.
This is a buffer used to/from the UART ISR. For high-speed scenarios,
it can be very helpful to increase the rx size. The ISR trying
to write to a full rx buffer results in lost data and an error
event posted.
config NODEMCU_UART_DRIVER_BUF_SIZE_TX2
int "TX buffer size for UART2"
depends on NODEMCU_UART_AT_LEAST_3
default 512
help
The tx buffer size to use for UART2.
This is a buffer used to/from the UART ISR. In some scenarios it
can be helpful to increase the tx size. Writing to a full tx buffer
blocks the calling RTOS task.
endmenu
WIP ESP32 IDF port. Currently the UART driver break boot (or at least output).
2016-09-16 10:10:18 +02:00
endmenu