cpu/esp8266: change of ETS task handling #10656
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
aabadie
added
Type: enhancement
gschorcht
force-pushed
the
esp8266_ets_handling
branch
from
3fa6ac6 to
404297f
Compare
31 tasks
gschorcht
force-pushed
the
esp8266_ets_handling
branch
from
32ff37b to
e334e82
Compare
|
@aabadie @kaspar030 Is it possible to ask someone to review this PR because it is essential for further changes? |
smlng
suggested changes
Jan 21, 2019
| @@ -143,5 +147,5 @@ else | |||
| export FFLAGS += -p $(PORT) -b $(PROGRAMMER_SPEED) write_flash | |||
| 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.
smlng
approved these changes
Jan 21, 2019
|
tested with board |
smlng
added
CI: ready for build
|
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.
gschorcht
force-pushed
the
esp8266_ets_handling
branch
from
ee4aad9 to
e4b0ace
Compare
|
@smlng Many thanks for reviewing and testing. Rebased and squashed. |
smlng
added
CI: ready for build
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.