cpu/esp8266: change of ETS task handling #10656
Conversation
3fa6ac6 to
404297f
Compare
32ff37b to
e334e82
Compare
|
@aabadie @kaspar030 Is it possible to ask someone to review this PR because it is essential for further changes? |
| export FFLAGS += -fm $(FLASH_MODE) | ||
| export FFLAGS += 0 $(ELFFILE)-0x00000.bin | ||
| export FFLAGS += 0x10000 $(ELFFILE)-0x10000.bin | ||
| export FFLAGS += 0x10000 $(ELFFILE)-0x10000.bin; esptool.py -p $(PORT) run |
There was a problem hiding this comment.
this looks a bit weird, can you explain. To me this looks like the latter is a necessary POSTFLASH command?
There was a problem hiding this comment.
Yep, it is the comment to reset after flashing. I couldn't figure out any other way to define something like that. RESET variable is not doing that since it requires to call make reset explicitly.
There was a problem hiding this comment.
okay, then leave as is for now. But we should keep this in mind and clean it up later on - meaning: this should be handled properly by the build system.
|
tested with board |
|
please squash |
ETS tasks are now handled by a high priority RIOT thread
Changes of ETS task handling require the context switch by software interrupt. The context switch based on interrupt is therefore enabled by default. Furthermore, the number of priority levels are increased due to the new additional thread.
With the new ETS task handling thread, the stack sizes could be down sized.
During flash write access, the IROM cache cannot be used and is disabled therefore. During that time, ets_post crashes if a functions is called which is not in IRAM. Therefore thread_flags_set must not be called if IROM cache is disabled.
ee4aad9 to
e4b0ace
Compare
|
@smlng Many thanks for reviewing and testing. Rebased and squashed. |
Contribution description
This PR changes the ETS task handling approach when using the Espressif SDK. This new ETS task handling approach is required for the upcoming ESP-NOW netdev driver. In addition, the default thread stack size can be reduced by half to save a lot of memory.
Update The PR is also prerequsit for refactoring in upcoming PR that reduces the code duplication by using some parts of the vendor code for ESP32 and ESP8266.
Background
To use the WiFi interface or software timers with the
esp_sw_timersmodule, functions of the Espressif SDK have be used. For handling hardware interrupts, the SDK internally uses its own priority-based multitasking system, the so-called ETS:ets_postROM function to send an event to the corresponding ETS tasks, which then process the interrupts asynchronously.ets_runto periodically execute all ETS tasks with pending interrupt events in an endless loop. Context switches are not possible in interrupt service routines.If the SDK is used, the ETS tasks with the pending interrupt events must also be processed by the RIOT port. For that purpose, the RIOT port overwrites the ROM functions
ets_runandets_post:ets_postfunction is overridden to receive a call back to the RIOT system in interrupt service routines.ets_runfunction is replaced by functionets_task_run. This function performs the execution of all ETS tasks with pending interrupt events exactly once.Before this PR, function
ets_task_runwas calledThis approach had the disadvantage that context switches based on RIOT priorities were mixed with handling interrupt events in prioritized ETS tasks. This resulted in some stability issues with the WiFi interface and required a lot of memory for the thread stacks.
Changes
The approach introduced with this PR assumes that ETS tasks are only used to handle hardware interrupts and their handling requires therefore always the highest priority. It
ets_postfunction which is called at the end of an ETS interrupt service routine to set the the flag, andets_task_funcwith the highest possible priority whichets_task_runfunction to handle all ETS tasks with pending interrupt events once the flag is set.Further changes with this PR are:
Testing procedure
Compile
tests/shellwith enabledets_sw_timerand flash any ESP8266 board, e.g.,Issues/PRs references
This PR is prerequisite for PRs #9917 and #10792 as well ass refactoring according to issue #10658.