The PR removed the bulk of non-newlib headers from the NodeMCU source base.
app/libc has now been cut down to the bare minimum overrides to shadow the
corresponding functions in the SDK's libc. The old c_xyz.h headerfiles have been
nuked in favour of the standard <xyz.h> headers, with a few exceptions over in
sdk-overrides. Again, shipping a libc.a without headers is a terrible thing to do. We're
still living on a prayer that libc was configured the same was as a default-configured
xtensa gcc toolchain assumes it is. That part I cannot do anything about, unfortunately,
but it's no worse than it has been before.
This enables our source files to compile successfully using the standard header files,
and use the typical malloc()/calloc()/realloc()/free(), the strwhatever()s and
memwhatever()s. These end up, through macro and linker magic, mapped to the
appropriate SDK or ROM functions.
* Rebaseline firmware to non-OS SDK version 3.0
* Note that SDK version 3.0 introduces the concept of a Flash Partition Table(PT). This is located at Flash offset 0x10000 in our firmware build.
* The firmware is now PT aware with both LFS and SPIFFS taking their partition size and location from the PT
* A new tool `tools/nodemcu-partition.py` is now used to initialise these data and can also download LFS and SPIFFS images to these partitions.
- Optimise ROTable accesses and interface
This includes some refinements to the ROTable cache which remove the linker cludges on the CROSS_COMPILE builds. Also keyhole tweaks to some of the Lua VM code to implrove runtimes.
I also noticed some compile time warnings during the build; the change to uz_unzip.c doesn't impact the compiled code, but does remove the compiler warnings.
Use separate names for the integer and float `luac.cross` binaries. Also adds local/lua directory which is already supported by tools makefile to build LFS image.
Added `node.egc.meminfo()` to expose LVM usage (to make the regular
`node.egc.ON_MEM_LIMIT` option usable).
Extended the `node.egc.ON_MEM_LIMIT` option to also take negative limits,
in which case that's taken as a request to keep a certain amount of heap
available for non-Lua use.
* Check the return code of the read function when doing crypto.fhash so that we don't pass negative lengths to the hashing functions
* Fix various assert failures in the LVM arising from rotables. No functional change
* Add the gpio interrupt time to the callback (and pass it from the interrupt handler)
* Get the PC right in the perf module
* Make the headers static in the websocket module
* Fix the documentation
* Add FatFs
* enable BUILD_FATFS for all-module build
* push vfs into rest of firmware
* align maximum filename length
* increase timeout for acmd41 during card initialization
* switch from DOS to Unix path semantics chdrive() is substituted by chdir()
* update to fatfs R.012a incl. patches 1-6
* add callback for rtc provisioning in file
* update docs
AFAIK no one uses the wifi.startsmart() and wifi.stopsmart(). Removing
them frees up an extra 20-25K of Flash to use as filesystem. So I have
added a new config define WIFI_SMART_ENABLE which is enabled by default
so the default functionality is the same, but if this is commented out
then this code is omitted.
I have also removed wofs and upgrade from this build as we no longer
support these.
Module creation & registration now made a lot simpler. In essence,
each module file is now self-contained and only needs a
NODEMCU_MODULE(MYNAME, "myname", myname_map, luaopen_myname);
line to both be automatically recognised by the Lua initialization
as well as honor the LUA_USE_MODULES_MYNAME #define.
As per #810 & #796, only LUA_OPTIMIZE_MEMORY=2 & MIN_OPT_LEVEL=2 are
supported when building. This commit effects that limitation.
With this change modules/auxmods.h no longer needs to be updated for
every new module, nor do module writers need to cater for a hypothetical
LUA_OPTIMIZE_MEMORY < 2 scenario.
When lua assertions are enabled, normal operation results in many:
lobject.c:88: (((t1)->tt) == 4)
lobject.c:88: (((t2)->tt) == 4)
lobject.c:88: (((t1)->tt) == 4)
lobject.c:88: (((t2)->tt) == 4)
lobject.c:88: (((t1)->tt) == 4)
lobject.c:88: (((t2)->tt) == 4)
It comes from using the pvalue() macro for 3 pointer types, where
pvalue() also checks the type of pointer and complains through the
assertion where the type == 4 (TLIGHTUSERDATA).
Use the correct macro according to the type of data being compared
to eliminate this assertion error.
Signed-off-by: Nick Andrew <nick@nick-andrew.net>
Johny Mattsson
Johny Mattsson
Terry Ellison
Philip Gladstone
ziggurat29
sergio
Arnim Läuger
Javier Peletier
galjonsfigur
Nathaniel Wesley Filardo
Gregor Hartmann
philip
Johny Mattsson
Nick Andrew