That's true, it uses its own toolchain. But, at least some parts of the source code, e.g., thread and interrupt handling, could be reused. Handling of peripherals like GPIO, UART, SPI, I2C, timers a.s.o. are propably completely different. And, of course ESP32 is a dual core chip.
I will try the port to ESP32 once my ESP8266 port is stable enough. On 13.04.2018 23:54, Hawkboy wrote: > I don't think so. > > ESP32 would need its own port since it uses a different xtensa toolchain... > > > On 12/04/2018 11:56, Mathias Tausig wrote: >> Du you know, if your port will work on the ESP32 (the successor of the >> ESP8266), >> too? >> >> cheers >> Mathias >> >> On Mon, 2018-02-26 at 13:00 +0100, Gunar Schorcht wrote: >>> Hi, >>> >>> I just want to let the community to know that I'm trying an ESP8266 >>> port. At the moment >>> >>> - the core's thread interface is implemented and tested, >>> - the core's irq interface is implemented and tested, >>> - GPIO handling module periph_gpio is implemented and tested, >>> - small applications like ipc_pingpong with interrupts and some I/O are >>> already working. >>> >>> My next steps are to implement perihph_timer module (I'm currently >>> working on), periph_uart module, periph_spi module and some networking. >>> >>> I started with two different approaches that are both working until now >>> >>> - a bare metal implementation, and >>> - an implementation on top of the community SDK esp-open_sdk. >>> >>> I really like the bare-metal implementation and would prefer this >>> approach since it gives more control over the hardware, requires less >>> resources and fits better RIOT-OS's core implementation approach. >>> Furthermore, it is generic enough that it might run on other Xtensa >>> processors. >>> >>> However, once networking using the proprietary WIFI hardware is needed, >>> it becomes unfortunately necessary to use proprietary SDK components. So >>> it seems, that I will continue the SDK approach first. >>> >>> Implementing RIOT-OS on top of the SDK is a bit tricky because the SDK >>> already uses tasks to control the hardware timers, the WIFI hardware, >>> the network connectivity, and so on. Therefore, it is necessary to give >>> away the task control to the SDK from time to time to keep the SDK tasks >>> alive. This is done by reimplementing the ets_run function, which is >>> executed each time before the idle task of the RIOT-OS and after the >>> timer interrupt handling. >>> >>> One of the two hardware timers is used in the SDK, the other hardware >>> timer is needed for PWM outputs. Therefore, RIOT OS timers are >>> implemented as SDK software timers, which results in an pure accuracy of >>> around 500 us. >>> >>> That's the status for now and I hope that it might become interesting >>> for someone. I will publish my changes at >>> https://github.com/gschorcht/RIOT-Xtensa-ESP8266 and submit a pull >>> request once I made some more progress. >>> >>> Regards >>> Gunar >>> >>> >>> _______________________________________________ >>> devel mailing list >>> devel@riot-os.org >>> https://lists.riot-os.org/mailman/listinfo/devel >>> >>> >>> _______________________________________________ >>> devel mailing list >>> devel@riot-os.org >>> https://lists.riot-os.org/mailman/listinfo/devel > > > > _______________________________________________ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > -- Dr. Gunar Schorcht Mission Level Design GmbH Langewiesener Strasse 22 98693 Ilmenau schor...@mldesigner.de Sitz der Gesellschaft: Lohmühlenweg 2 99310 Arnstadt Amtsgericht Jena: HRB 111384 Geschäftsführung: Dipl.-Inf. Tino Jungebloud
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
