-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cpu/esp*: Access to scheduler internals #14771
Comments
|
The code is a bit tricky, but it was the only way to get it working with the existing API for ESPs.
Yes, although ESPs are Xtensa cores, the ESP8266 uses the Call0 ABI while ESP32 uses the Window ABI. That's why ESP32 requires special handling on |
The first n lines of the ESP32 Why wouldn't it be possible to just use |
It might work. To be honest, I don't remember exactly why I did it in that way. I only remember that applications that return from the main thread did crash. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions. |
Description
The ESP32 and ESP8266 platform specific code is accessing scheduler internal stuff and writing to it. E.g.
NORETURN void task_exit(void)
is with__XTENSA_CALL0_ABI__
indeed just mapping toNORETURN void sched_task_exit(void)
, but otherwise is handling the task exit internally.IMO, we should make sure that platform specific code is not modifying the scheduler internal state. Instead, a well defined API should be used for interactions between platform specific code and the scheduler. This would allow changing the internals of the scheduler without breaking other stuff
Suggestion
Use existing scheduler API, such as
sched_task_exit()
Replace code writing to
sched_*
by calls to the existing scheduler API. E.g. rewrite thetask_exit()
function to also usesched_task_exit()
even when__XTENSA_CALL0_ABI__
is not used. (Btw: Is there indeed a need to support two different ABIs?)Or would this be infeasible to get the ESP platform working on top of the existing core APIs?
Extend the scheduler API
If indeed the current core APIs are not enough to get the ESP platform spinning, we should IMO just extend the APIs as needed and use that instead.
Versions
Current master
The text was updated successfully, but these errors were encountered: