Riot: Feature request: Port for ESP8266

Created on 1 Nov 2017  路  17Comments  路  Source: RIOT-OS/RIOT

I would like to see the ESP8266 board supported as it is quite a popular board
I want to use https://github.com/named-data-iot/ndn-riot on it.
So far I have found these on the mailing list:

  1. https://lists.riot-os.org/pipermail/devel/2016-February/003395.html
    Following suggestion were made:
    a) Read the porting guide
    b) Use C SDK provided for the ESP8266: (https://github.com/espressif/ESP8266_RTOS_SDK (espressif, shady licensing), https://github.com/pfalcon/esp-open-sdk (as much open as possible)).
    Look at FreeRTOS based on esp-open-sdk.
    (Has anybody tried to use the SDK?)

  2. https://www.mail-archive.com/[email protected]/msg00425.html
    WiFi components are proprietary so the potential RIOT benefit is a new board with a new cpu architecture.
    Maybe better to use as external device (Already a pull request for it at: https://github.com/RIOT-OS/RIOT/pull/5898).

  3. https://lists.stillroot.org/pipermail/devel/2015-March/002245.html
    Make ESP8266 an example for an embedded stack (I am not familiar with RIOT enough to understand this discussion - is it different from what's being discussed at point 2 above).

  4. https://lists.riot-os.org/pipermail/devel/2016-April/003825.html
    Some discussion about the ESP chip using custom CPU - countered by the fact that ESP is based on a reasonably popular CPU.

new feature

Most helpful comment

I just want to let the community know that I'm working on an ESP8266 port. I'm doing that at
https://github.com/gschorcht/RIOT-Xtensa-ESP8266. However, before publishing my changes and submitting a pull request, I would like to make some more progress.

Current status (2018-02-23):

  • context saving and restoring (implementing the core's thread inteface) is implemented and tested
  • interrupt handling (the core's irq interface) is implemented and tested
  • GPIO handling module periph_gpio is implemented and tested
  • a small applications like ipc_pingpong with interrups and some I/O is running

Next steps

  • implement perihph_timer module (I'm working on)
  • implement periph_uart module
  • implement periph_spi module
  • implement some networking

Implementation details

I started with two different approaches that are both working til now:

  • bare metal implementation
  • implementation on top of the community SDK esp-open_sdk

Bare metal approach gives more control over the hardware, requires less ressources and fits better RIOT-OS's core implementation approach. Furthermore, it is generic enough that it might run on other Xtensa processors.

Although I really like the bare-metal implementation and would prefer this approach, it is unfortunately necessary to use proprietary SDK components as soon as networks with the proprietary WIFI hardware are needed. Using the SDK is a bit tricky, as it already uses tasks to deal with hardware timers, WIFI hardware, network connections, and so on. One of the two hardware timers is used in the SDK, the other hardware timer is needed for PWM outputs. At the moment, RIOT OS timers are implemented in addition to SDK software timers, resulting in an pure accuracy of 500 us.

All 17 comments

I just want to let the community know that I'm working on an ESP8266 port. I'm doing that at
https://github.com/gschorcht/RIOT-Xtensa-ESP8266. However, before publishing my changes and submitting a pull request, I would like to make some more progress.

Current status (2018-02-23):

  • context saving and restoring (implementing the core's thread inteface) is implemented and tested
  • interrupt handling (the core's irq interface) is implemented and tested
  • GPIO handling module periph_gpio is implemented and tested
  • a small applications like ipc_pingpong with interrups and some I/O is running

Next steps

  • implement perihph_timer module (I'm working on)
  • implement periph_uart module
  • implement periph_spi module
  • implement some networking

Implementation details

I started with two different approaches that are both working til now:

  • bare metal implementation
  • implementation on top of the community SDK esp-open_sdk

Bare metal approach gives more control over the hardware, requires less ressources and fits better RIOT-OS's core implementation approach. Furthermore, it is generic enough that it might run on other Xtensa processors.

Although I really like the bare-metal implementation and would prefer this approach, it is unfortunately necessary to use proprietary SDK components as soon as networks with the proprietary WIFI hardware are needed. Using the SDK is a bit tricky, as it already uses tasks to deal with hardware timers, WIFI hardware, network connections, and so on. One of the two hardware timers is used in the SDK, the other hardware timer is needed for PWM outputs. At the moment, RIOT OS timers are implemented in addition to SDK software timers, resulting in an pure accuracy of 500 us.

@gschorcht great to hear your news about that port! I bet there are thousands of people looking forward to that :-). If you ask for comments about bare-matal vs. SDK, I think it might make sens to put it on the developers mailing list. Maybe it's good to announce it on that list anyway.

@gschorcht Thanks for working on this! Do you have any rough estimate of when one can try this out?

@gschorcht I'm doing that in parallel to my regular business. That means it will take a little longer, maybe a month. Yesterday I implemented the periph_timer module, which needs a bit more testing. Currently I started working on the module periph_spi.

@gschorcht Thank you so much for working on the ports! Is the ESP32 port still in progress? I was thinking of trying to port it myself (as a learning experience and also because I may need the port), but do you think this would be too difficult for a complete beginner to do? (I am both new to RIOT OS and have never done anything like this before)

@peurpdapeurp Please refer https://github.com/gschorcht/RIOT-Xtensa-ESP/wiki/ESP32-port to get more information about the status of the ESP32 port. It is already working quite well and I hope that I can place an initial PR in next few days.

@gschorcht Hello and thank you again for working on the ports! Is there a date estimate for when the ESP32 port may be made public?

@peurpdapeurp I'm tuning the source code a bit to pass automatic source code checks and finalizing some documentation. I hope, I can finish it until this Friday. First, I will upload it to my RIOT fork before I place a PR for merge.

@gschorcht Ah thank you so much! Another question, as it says on the ESP32 port page that implementing Wifi and Bluetooth is a next step, would you be working on this soon as well or would it be something to try implementing myself if I wanted it? Do you think that this is a job too difficult for a beginner?

@peurpdapeurp WiFi and Bluetooth is a big problem. At the moment I am not sure whether it will be possible at all to get them working without ESP-IDF. WiFi and Bluetooth are driven by proprietary libraries that are not documented. Furthermore, these libraries use ESP-IDF functions. ESP-IDF itself is a FreeRTOS port which cannot be used together with RIOT.

I already started to work on a FreeRTOS adaption layer and to re-implement some ESP-IDF functions, but I stopped this attempt for the moment. The main networking technology of RIOT is IEEE802.15.4, so that WiFi doesn't seem to play an important role for the port at the moment. But once the port is working, I will continue the work on WiFi.

@gschorcht Ah I see! Do you think there is anything I could to to help with this effort, being a complete beginner?

Sorry for re-opening this issue but i have a quick problem. @gschorcht

I have just downloaded RIOT-OS and trying to do steps Precompiled Toolchain -

export PATH=$PATH:/opt/esp/esp-open-sdk/xtensa-lx106-elf/bin
export ESP8266_SDK_DIR=/opt/esp/esp-open-sdk/sdk
export ESP8266_NEWLIB_DIR=/opt/esp/toolchain/newlib-xtensa

i have added these steps to my .profile file in linux 64bit.
in gnrc_networking i modified as BOARDS = esp8266-esp-12x
when i wrote terminal sudo make it gave something like " Compilier error could not find xtensa in PATH. aborting "

I couldn't not understand why is this happening did i miss something?

@mmaxus35
What is the output of following commands?

env | grep PATH
which xtensa-lx106-elf-gcc

@gschorcht
output of the env | grep PATH
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
DEFAULTS_PATH=/usr/share/gconf/ubuntu.default.path
PATH=/home/burak/bin:/home/burak/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
MANDATORY_PATH=/usr/share/gconf/ubuntu.mandatory.path

which xtensa-lx106-elf-gcc did not give any output.

@mmaxus35 Obviously, your PATH variable does not contain the path to the toolchain. If you followed the instructions for precompiled toolchain, the toolchain should be installed in /opt/esp and the compiler should reside in /opt/esp/esp-open-sdk/xtensa-lx106-elf/bin. Therefore, your PATH variable has to include /opt/esp/esp-open-sdk/xtensa-lx106-elf/bin to get it working.

Either your .profile is not correct or you did not relogin to get the changes in your .profile effective. Please double check your installation.

XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session0
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
DEFAULTS_PATH=/usr/share/gconf/ubuntu.default.path
PATH=/home/burak/bin:/home/burak/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:

/opt/esp/esp-open-sdk/xtensa-lx106-elf/bin -> Here

MANDATORY_PATH=/usr/share/gconf/ubuntu.mandatory.path
COMPIZ_BIN_PATH=/usr/bin/

and which xtensa gave this output " /opt/esp/esp-open-sdk/xtensa-lx106-elf/bin/xtensa-lx106-elf-gcc
"
However i still get same error
"Compiler xtensa-lx106-elf-gcc is required but not found in PATH. Aborting."

@mmaxus35 This cannot be provided you have done it in the same shell and with same PATH variable.

If which xtensa-lx106-elf-gcc is able to find xtensa-lx106-elf-gcc, the compiler check in $RIOTBASE/Makefile.include line 486 should be able too. Later one does nothing else than to execute xtensa-lx106-elf-gcc -v. If the execution fails, you get the error message

Compiler xtensa-lx106-elf-gcc is required but not found in PATH.  Aborting.

That is, if make ... complains that it cannot find xtensa-lx106-elf-gcc, it is definitely not in your PATH variable that you use for make ....

Since the execution of which xtensa-lx106-elf-gcc delivered the right location, it is clear that the installation was successful and the toolchain is at the right place. Therefore, it has to be a problem with your PATH variable when you call make .... Maybe, you have used different shell windows.

Please try again

which xtensa-lx106-elf-gcc
xtensa-lx106-elf-gcc -v
make -C examples/gnrc_networking

in this order and in the same shell.

BTW, since your problem seems to be an administration problem that has nothing to do with the feature request, please use a separate new issue of type question in future. It is not a good idea to have long discussions about a topic in an issue that is not related to the problem.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

gschorcht picture gschorcht  路  7Comments

hcnhcn012 picture hcnhcn012  路  5Comments

romainvause picture romainvause  路  3Comments

kaspar030 picture kaspar030  路  6Comments

chrysn picture chrysn  路  5Comments