Uart driver currently disabled as it's not (yet) compatible with RTOS.
Running Lua task with excessive stack to avoid smashing it; need to work out
what's using so much stack space.
Changed some flash reading functions to not attempt to drop an entire 4k
flash page onto the stack.
Ensure the task pump doesn't attempt to retrieve from uninitialised queues.
This compiles, links, and starts the RTOS without crashing and burning.
Lua environment does not yet start due to the different task architecture.
Known pain points:
- task implementation needs to be rewritten for RTOS (next up on my TODO)
- secure espconn does not exist, all secure espconn stuff has been #if 0'd
- lwip now built from within the RTOS SDK, but does not appear to include
MDNS support. Investigation needed.
- there is no access to FRC1 NMI, not sure if we ever actually used that
however. Also #if 0'd out for now.
- new timing constraints introduced by the RTOS, all use of ets_delay_us()
and os_delay_us() needs to be reviewed (the tsl2561 driver in particular).
- even more confusion with ets_ vs os_ vs c_ vs non-prefixed versions.
In the long run everything should be switched to non-prefixed versions.
- system_set_os_print() not available, needs to be reimplemented
- all the RTOS rodata is loaded into RAM, as it apparently uses some
constants while the flash isn't mapped, so our exception handler can't
work its magic. This should be narrowed down to the minimum possible
at some point.
- with each task having its own stack in RTOS, we probably need change
flash-page buffers from the stack to the heap in a bunch of places.
A single, shared, page buffer *might* be possible if we limit ourselves
to running NodeMCU in a single task.
- there's a ton of junk in the sdk-overrides now; over time the core code
should be updated to not need those shims
- Stop fighting against the SDK in terms of owning/writing the init_data block.
NodeMCU included a default init_data block because originally the SDK did
not, but by now it's not needed.
- Expose a way to reconfigure the ADC mode from Lua land. With most people
using the cloud builder and not able to change the #define for byte 107
this has been a pain point.
- Less confusion about which init_data has been used. Lua code can now simply
state what mode it wants the ADC to be in, and not worry about the rest of
the init_data complexities such as the init_data changing location due to
flashing with wrong flash_size setting, or doing/not doing a chip-erase
before loading new NodeMCU firmware.
commit 2c7c3fc3985cc32866e8af496abea9971eaee90a
Merge: 9179dae 41022c3
Author: philip <philip@gladstonefamily.net>
Date: Sun Feb 28 14:47:47 2016 -0500
Merge remote-tracking branch 'upstream/dev' into rotary_2
commit 9179dae0824e6b35ad09e5113aacc26dc91692c0
Author: philip <philip@gladstonefamily.net>
Date: Fri Feb 26 20:53:27 2016 -0500
Review comments
commit 67741170e20ccb2b636e701f0664feff2aafbb4c
Author: philip <philip@gladstonefamily.net>
Date: Fri Feb 26 20:59:49 2016 -0500
Squashed commit of the following:
commit 8c9a64731c4a8b9aedda18a399b433b173d2199f
Merge: 085935f 19d3c1d
Author: philip <philip@gladstonefamily.net>
Date: Fri Feb 26 20:58:10 2016 -0500
Merge remote-tracking branch 'upstream/dev' into rotarymod
Conflicts:
app/platform/platform.c
commit 085935fc56986d607ff5e05d1663970331959c34
Author: philip <philip@gladstonefamily.net>
Date: Fri Feb 26 20:53:27 2016 -0500
Review comment
commit 7732fd2d1044f28b8fcf5b0aa0f76d76fe80f449
Author: philip <philip@gladstonefamily.net>
Date: Sat Feb 20 12:10:38 2016 -0500
Module to handle rotary decoders
Eliminate ROTARY_DEBUG
Remove unused file
Eliminate a malloc call
Cleaned up the register code. Now 0x114 bytes
Fix bug with clearing bits in one case
Fix the type in the #define name
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.
As with the last commit this rolls up the follwowing, but include the various
review comments on the PR.
- **Documentation changes**. I've added the taks FAQ as a stub new Extension
developer FAQ, and split the old FAQ into a Lua Developer FAQ and a Hardware
FAQ.
- **Tasking I/F**. New `app/task/Makefile`, `app/task/task.c`,
`app/include/task/task.h` and `app/Makefile` as per previous commit. Cascade
changes to `app/driver/uart.c`, `app/include/driver/uart.h`,
`app/user/user_main.c` and `app/modules/node.c`
- **GPIO Rework** to `app/modules/gpio.c` and `pin_map.[hc]`, `platform.[hc]`
in `app/platform`
- **Other Optimisations** Move the `platform_*_exists()` from
`app/platform/common.c` to static inline declarations in `platform.h` as
this generates faster, smaller code. Move lgc.a routines out of iram0.
There was only one genuine use of this macro, all other places were
using it only as a necessary compensation. While this was fine as long as
it was the first meg of flash which was mapped, it became incorrect and
quite dangerous whenever this assumption did not hold (such as when
running from the second slot in an OTA scenario).
The flash API now uses actual addresses, not translated/mapped
addresses, and the users of this API have been adjusted accordingly.
This makes the flash API work correctly regardless of what flash mapping
is in use.
The old macro is still available under the new name
INTERNAL_FLASH_MAPPED_ADDRESS, and this is used to detect flash writes
where the source is mapped flash (and thus has to be bounced), and to
adjust the _flash_used_end linker symbol when used with
flassh_find_sector() by the filesystem code. The latter usage is not
OTA-proof, but in an OTA scenario the filesystem needs a fixed location
anyway and thus would not use this code path.
With the new SDK soft-wdt it is no longer sufficient to tickle the hardware
watchdog, so all (found) instances have been changed to system_soft_wdt_feed().
When using the flash write API, the flash is unmapped/uncached, and as
such it's not possible to source data directly from flash (e.g. string
literals).