The irom0_flash.bin file gets written to offset 0x40000 in flash. Said file
has the following layout
| irom0 | text | data | rodata | chksum |
...so the previous approach of having a _flash_used_end symbol at the end of
the irom0 section no longer gives us an accurate view of how much of the flash
is used.
New driver is a three-way merger between Espressif's esp8266-rtos-sdk example
driver, Espressif's esp32-rtos-sdk not-example driver, and the previous
NodeMCU driver, plus some general clean-ups.
Basic interactivity is now available on the ESP32!
A fair bit of reshuffling with include paths and overrides was necessary, as
the two RTOS SDKs (ESP8266 and ESP32) don't have the same header structure
(or even libraries for that matter). Uses the xtensa-esp108-elf toolchain
to build.
Completely untested beyond linking, as I still can't flash the ESP32 module
I have :( I'd be most surprised if it does anything useful at this point
considering I've spent almost no time on the linker script or UART setup.
Anything using espconn has been ifdef'd out since espconn is not (and
probably will not be) available. Notably this includes the entire net module
as well as coap, mqtt and enduser_setup.
Many (most?) hardware bus drivers and related modules are also ifdef'd
out for now due to hardware differences. Functions surrounding sleep,
rtc and RF modes have also been hit by the ifdef hammer. Grep'ing for
__ESP8266__ and/or FIXME is a quick way of finding these places. With
time I hope all of these will be reinstated.
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).
Johny Mattsson
Johny Mattsson
devsaurus
philip
Terry Ellison
dnc40085
Huang Rui
Johny Mattsson
btsimonh
Vowstar
Bernd Meyer