1. 09 Jun, 2016 1 commit
    • Johny Mattsson's avatar
      Make NodeMCU compile and link for ESP32. · 224788b6
      Johny Mattsson authored
      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.
      224788b6
  2. 24 May, 2016 1 commit
    • Johny Mattsson's avatar
      Initial pass at switching to RTOS SDK. · f3e2a3af
      Johny Mattsson authored
      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
      f3e2a3af
  3. 26 Feb, 2016 1 commit
    • TerryE's avatar
      Make the wifi.smart functions options and remove wofs and upgrade · 46ea2aa4
      TerryE authored
      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.
      46ea2aa4
  4. 12 Dec, 2015 2 commits
    • Johny Mattsson's avatar
      d84a24fc
    • Johny Mattsson's avatar
      Cleaned up all uses of INTERNAL_FLASH_START_ADDRESS. · c4e8b04f
      Johny Mattsson authored
      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.
      c4e8b04f
  5. 15 Mar, 2015 2 commits
  6. 11 Feb, 2015 1 commit
  7. 16 Jan, 2015 1 commit
  8. 30 Dec, 2014 1 commit
  9. 22 Dec, 2014 1 commit