Skip to content

RFC: rework of high resolution timer, sleep, and posix clock APIs and subsystems #40099

Open
@cfriedt

Description

@cfriedt

I wanted to reintroduce discussion of a topic that is quite important - namely, HR timer support, improved support for e.g. nanosleep(2) and POSIX clock APIs such as clock_getres(3), clock_gettime(3), et al. This could all probably be collectively defined as "Real Time".

This has been on the agenda for a fairly long time. See e.g. #6498, #19030, #19282, #28542. @pabigot put a lot of effort into moving this forward and I promised that I would help to push it forward as well. I was reminded to start this conversation again with #35703.

Tagging others (please feel free to edit): @cvinayak, @nordic-krch, @andyross, @nashif, @pfalcon, @carlescufi, @stephanosio

I would also like to volunteer to drive most of this work until it is finished, and ideally that would be in v3.0.0. I am fairly fluent in the language of RT but am by no means an expert in all of its nuances in Zephyr, which is why i think it's critical to ensure that we do bring together the right people in this discussion and come to a general consensus before any work is started. Also, let's not be standoffish or judgemental - we're all hoping to improve the current state of timekeeping in Zephyr and the best way to achieve that is through collaboration.

Feel free to edit the topic as needed.

Similar to what was proposed in #19030, I would like to second that we support a number of standard clock sources and mimic the POSIX model. This will simplify testing. We need internal API for managing a collection of clock sources and timers (ideally this would be compile-time const for the most part and involve DT).

While working on nanosleep(2), it became quite evident that busy-waiting is not the best way to achieve accurate delays and that we need to have assistance from hardware - but it should be done in a vendor-neutral way.

The system timer in Zephyr often does not use the highest-res clock source. Some clocks may not have a common source, and can exhibit drift w.r.t. one another even on the same SoC.

Have to run atm, but I just wanted to jot down some notes here. Please feel free to add to this. No rush either - focus will be after v2.7.0 is released.

Metadata

Metadata

Assignees

Labels

Type

Projects

Status

No status

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions