Add and update Timer requirements #75
Conversation
There was a problem hiding this comment.
I left a couple of comments and suggestions with the proposed changes.
There are only a couple of additional things I want to mention here>
- The function where the application can query the next expiry time in systicks is not covered.
- Do we need to specify how users can influence a timer's resolution (in ns/ms/whatever) ?
- For the thread syncing functionality do we need to allow for more than one thread that can synchronize with a given timer?
| <<< | ||
| USER_STORY: >>> | ||
| As a Zephyr RTOS user, I want to be able to track the passed real time in the OS with a dedicated hardware counter and interrupt. | ||
| The Zephyr RTOS shall provide a mechanism to define and initialize a timer at run time. |
There was a problem hiding this comment.
suggestion:
| The Zephyr RTOS shall provide a mechanism to define and initialize a timer at run time. | |
| The Zephyr RTOS shall provide a mechanism to define and initialize timers at run time. |
| TITLE: Call functions in interrupt context | ||
| TITLE: Timer definition at compile time | ||
| STATEMENT: >>> | ||
| The Zephyr RTOS shall provide a mechanism to define and initialize a timer at compile time. |
There was a problem hiding this comment.
suggestion:
| The Zephyr RTOS shall provide a mechanism to define and initialize a timer at compile time. | |
| The Zephyr RTOS shall provide a mechanism to define and initialize timers at compile time. |
There was a problem hiding this comment.
** nitpick **:
A technically more precise term is probably static initialization
| STATUS: Draft | ||
| TYPE: Functional | ||
| COMPONENT: Timers | ||
| TITLE: Timer remaining expiration system tick time |
There was a problem hiding this comment.
suggestion:
| TITLE: Timer remaining expiration system tick time | |
| TITLE: Provide timer remaining expiration time in units of system ticks |
| STATUS: Draft | ||
| TYPE: Functional | ||
| COMPONENT: Timers | ||
| TITLE: Timer remaining expiration time |
There was a problem hiding this comment.
suggestion:
| TITLE: Timer remaining expiration time | |
| TITLE: Provide timer remaining expiration time in milliseconds |
| COMPONENT: Timers | ||
| TITLE: Timer remaining expiration time | ||
| STATEMENT: >>> | ||
| The Zephyr RTOS shall provide a mechanism to get the timer remaining until expiration time in milliseconds. |
There was a problem hiding this comment.
suggestion:
| The Zephyr RTOS shall provide a mechanism to get the timer remaining until expiration time in milliseconds. | |
| The Zephyr RTOS shall provide a mechanism to get the timer's remaining time until its next expiry in milliseconds. |
simhein
force-pushed
the
timers_req
branch
2 times, most recently
from
7861f70
to
bffab9a
Compare
Added.
I think that could be specified but i don't see it here for the feature timer. because it don't give options to influence a timers resolution.
Yes that is the way it is implemented as far as I see. |
docs/system_requirements/index.sdoc
Outdated
| COMPONENT: Timers | ||
| TITLE: Timers time base | ||
| STATEMENT: >>> | ||
| The Timers of the Zephyr RTOS shall use the kernel's system clock to measure time. |
There was a problem hiding this comment.
This is a design decision. Just not clear why a timer implementation shall be restricted to the system clock. A justification for this descision would be helpful.
There was a problem hiding this comment.
This is a design decision. Just not clear why a timer implementation shall be restricted to the system clock. A justification for this descision would be helpful.
Ok so removing the requirement here would be the best way? And the justification should be done in the design itself your should we do it on this level?
Add new Timers system requirements. Remove user story from the system requirements. Update description and titels of the existing requirements to fit better to the guidelines. Signed-off-by: Simon Hein <[email protected]>
Add new timers requirements on the software level Remove the user stories from the existing requirements. Remove obsolete requirements and rephrase existing ones. Signed-off-by: Simon Hein <[email protected]>
| COMPONENT: Timers | ||
| TITLE: Timer expire when thread synchronization is used | ||
| STATEMENT: >>> | ||
| When the thread synchronization mechanism is used, the thread shall be blocked until the timer expires. |
There was a problem hiding this comment.
For me the API as we have it today in Zephyr is not ideal, e.g. the behaviour is somewhat ambiguous. Say, two threads synchronize on a given timer of which only one thread will be readied when the timer expires. But which of these two threads will that be? And is it deterministically always the same?
For me this boils down to poor semantics in the read status operation as it resets the status field as a side-effect.
That all said, probably not much we can do about it right now as we are trying to capture the RQTs as per the API as it is. Still, I wonder if for a functionally safe RTOS this needs changing first. Probably worth a discussion in a wider group.
| COMPONENT: Timers | ||
| TITLE: Timer thread synchronization status reset | ||
| STATEMENT: >>> | ||
| When the thread synchronization mechanism is used, the status of the timer shall be reset. |
There was a problem hiding this comment.
Perhaps it's different views on semantics, I'd expect that syncing a thread on a timer should not affect the timer itself, since otherwise the operation will behave differently for the first and the following threads trying to sync at the same time. The current implementation in https://github.com/zephyrproject-rtos/zephyr/blob/911abc33e68b81c0490fa4b32a93d7d726640b73/kernel/timer.c#L295 resets the timer's status field after the timer expired and the first thread waiting for the timer runs again over this line. From the timer's perspective this happens at an arbitrary point in time as the (now running) thread might have spend an unspecified amount of time in the ready queue.
Not saying this is false per se, just that I am not really getting it yet, why things are the way they are.
Add new Timers system requirements.
Remove user story from the system requirements.
Add new software timers requirements.
Regenerate the software requirements UIDs