Commit Graph

12 Commits

Author SHA1 Message Date
Arnim Läuger 13735b7228
ESP32 precompiled toolchain (#2730)
* remove toolchains submodule

* remove toolchains dir

* download precompiled toolchain from https://github.com/jmattsson/esp-toolchains/releases

* remove toolchain target
delete toolchain with clean target

* avoid bash syntax
2019-04-22 14:45:27 +02:00
tomsci 72d28fa86e Adding qrcodegen module for generating QR Codes (#2543)
* Adding qrcodegen module for generating QR Codes

* Added LUA_MODULE_QRCODEGEN KConfig

* Changed qrcodegen.encodeText() to use an options table

Created common.h with new option table helper fns.

* Reworked http.c to use new common.h options table APIs
2018-11-15 22:17:43 +01:00
Ryan Hartlage d6c593b722 Use esp-mqtt from esp-idf (#2509)
* Use esp-mqtt from esp-idf

* Fix formatting

* Revert changes to u8g2 submodule
2018-10-08 20:58:28 +02:00
devsaurus 45c63a8236 Add ucg module. 2018-10-07 16:31:28 +02:00
Andrew Gough 4207d6c8ad Add espmqtt library + bindings 2018-02-01 21:03:10 +11:00
devsaurus a8ff8f059d Add u8g2 module. 2017-06-13 18:38:09 +02:00
Johny Mattsson fe602d2d7e Removed all currently-unused code & docs.
Heading towards having only ESP32-aware/capable code in this branch.
2016-09-21 13:47:44 +10:00
Johny Mattsson a463d764eb WIP ESP32 IDF port.
Currently the UART driver break boot (or at least output).
2016-09-16 18:11:42 +10:00
Johny Mattsson 6abc1c32f3 Add ESP32 builds to CI, use new toolchains. 2016-06-25 23:18:42 +10:00
Johny Mattsson d33945b68b Moved sdk submodules for easier branch switching. 2016-06-21 18:06:04 +10:00
Johny Mattsson 224788b642 Make NodeMCU compile and link for 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.
2016-06-09 18:40:56 +10:00
Johny Mattsson f3e2a3afd9 Initial pass at switching to RTOS SDK.
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
2016-05-24 16:05:02 +10:00