* Proof-of-concept multi-type console support via stdio
* Address crashes on linput's use of printf.
On an empty line input, a C3 with UART console would panic while attempting
to output the new Lua prompt. The backtrace shows a xQueueSemaphoreTake
with uxItemSize==0 as the panic cause, deep inside the uart driver, invoked
via vfs_uart and vfs_console layers, from printf.
Similarly, the printf for outputting a backspace/erase sequence would also
trigger a panic.
This workaround (of not mixing fflush() with printf) is likely merely hiding
a deeper issue, but it appears to be consistent. Plus, printf with no args
and a user-supplied format string is a no-no and should be fixed anyway.
* Work around IDF inconsistency with stdout buffering.
* Increase console task stack size.
Seems on Xtensa it ended up not being enough.
* Switch to single-byte console reads.
* Stop cheating and feed Lua from the right context.
* Work around IDF buffering stdout even when told not to, on ACM consoles.
* Initial build support for esp32c6.
Plus fixup of module selection for a variety of targets.
* Update github actions to node 20 versions.
* Update github build to deal with Lua 5.3 being default.
* Address fatal compiler warning.
Newer IDF toolchain is stricter, and we'd apparently failed to build test
the Lua-5.1 path for some time.
* Initial build support for esp32h2.
* Upgrade IDF to v5.1.3
* Fix left-over incorrect type in uzlib.
* Avoid null pointer crashes when debugging startup.
* Workaround for using wifi module on S2 with USB-CDC console.
---------
Co-authored-by: Jade Mattsson <github@frozenlogic.org>
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).
The IDF provides all we need these days, and the old driver was just
needlessly conflicting with the IDF settings and setup.
This also simplifies our uart input path as we no longer need to
duplicate the raw byte handling for when "run_input" is false.
Using the NODEMCU_ namespace prefix makes it obvious that these are not
part of Lua proper (contrast, e.g., LUA_BUILTIN_STRING). Using
"CMODULE" gives us room to differentiate between modules whose
implementation is in C and whose implemenation is in Lua ("LMODULE").
The ESP8266 branch can adopt the same convention when it moves to
Kconfig; see https://github.com/nodemcu/nodemcu-firmware/issues/3130
- implement file.size for spiffs (#1516)
- fix vfs_lseek() result checking in enduser_setup and clarify SPIFFS_lseek() return value (#1570)
- Handle error condition in file.read() (#1599)
Jade Mattsson
Johny Mattsson
Nathaniel Wesley Filardo
devsaurus