8000 event/timeout: fixed dependency on ZTIMER_USEC preventing low-power operation · Issue #16891 · RIOT-OS/RIOT · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

event/timeout: fixed dependency on ZTIMER_USEC preventing low-power operation #16891

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.

Sign up for GitHub

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

Jump to bottom
Closed
haukepetersen opened this issue Sep 24, 2021 · 10 comments
Closed

event/timeout: fixed dependency on ZTIMER_USEC preventing low-power operation #16891

haukepetersen opened this issue Sep 24, 2021 · 10 comments
Assignees
@kaspar030 @fjmolinas

Comments

@haukepetersen
Copy link
Contributor

Description

For testing some border router stuff I just wanted to re-flash one of my very-low-power nodes with a current firmware. But it turns out, that with current master I am not able anymore to get my low-power build to work... To recap: key to this build was to get rid of any xtimer and ztimer_usec depencency, as a running periph timer does prevent the Nordic from going to low power...

The reason that is blocking my build now is the usage of event/timeout in gcoap. More precisely: the recent ztimer-enabling of event/timeout (#16505) introduces a fixed dependency to ztimer_usec - leading to gcoap always pulling in and enabling the periph timer...

Possible solution:
The API changes/additions to event/timeout already contain new ztimer-specific functions that let the user decide for the time backend to use. So the problem is the mapping of the existing API functions, which are however always included in the build. The key to solving this problem lies IMHO in separating the ztimer and non-ztimer parts of the event/callback API more strictly: modules using this library should either use only the event_timeout_ztimer_x() API and declare that dependency by using event_timeout_ztimer, or they should use the old, usec-based API, declaraing this by depending on event_timeout. Now it becomes possible to use that module without forcing ZTIMER_USEC into the build...

Steps to reproduce the issue

build anything with gcoap, xtimer or ztimer_usec are always pulled into the build

Expected results

Use event/timeout and gcoap in low-power applications

Actual results

low-power not possible with gcoap at the moment

Versions

master
@haukepetersen haukepetersen mentioned this issue Sep 24, 2021
Closed
@fjmolinas
Copy link
Contributor

The reason that is blocking my build now is the usage of event/timeout in gcoap. More precisely: the recent ztimer-enabling of event/timeout (#16505) introduces a fixed dependency to ztimer_usec - leading to gcoap always pulling in and enabling the periph timer...

I'm not sure how this could be related, that PR just enables ztimer as a backend for event_timeout, but xtimer was a forced dependency before, so there was already a running timer before no? Doesn't this suggest that gcoap is now depending on something using event_timeout which was not the case before?

@fjmolinas fjmolinas mentioned this issue Sep 30, 2021
Merged
@kfessel
Copy link
Con 8000 tributor
kfessel commented Oct 8, 2021

Just pulling ztimer_usec should not prevent power_saving if it isn't in use (has not timer running on it), one reason it might be in use is the uint32 extender for ztimer.

@kfessel kfessel mentioned this issue Oct 8, 2021
Draft
@fjmolinas fjmolinas mentioned this issue Nov 2, 2021
Open
22 tasks
@fjmolinas
Copy link
Contributor

The reason that is blocking my build now is the usage of event/timeout in gcoap. More precisely: the recent ztimer-enabling of event/timeout (#16505) introduces a fixed dependency to ztimer_usec - leading to gcoap always pulling in and enabling the periph timer...

How did you resolve the dependency on usec for observations for gcoap?

@kfessel
Copy link
Contributor
kfessel commented Nov 29, 2021

#17141 might improve on that

@fjmolinas
Copy link
Contributor

#17141 might improve on that

How? AFAIK usec is still required, so I'm wondering if @haukepetersen had patched this part in his branch.

@kfessel
Copy link
Contributor
kfessel commented Nov 29, 2021 •
edited
Loading

these usec uses are just nows -> they will not block power saving (if configured for i don't care for long term usec now values short term is enough)

@fjmolinas
Copy link
Contributor

these usec uses are just nows -> they will not block power saving (if configured for i don't care for long term usec now values short term is enough)

I don't understand, doesn't a running timer block power savings?

@kfessel
Copy link
Contributor
kfessel commented Nov 29, 2021 •
edited
Loading

yes, BUT having ztimer_usec does not mean to have it running.
With pm-layer, if there is no timer on it, the layered pm_mode is unblocked (this may stop the CPU-OSC and hence usecs-clock, which is the reason, that I allways talk about ztimer_now isn't save to use for time meassurements (you need to block the pm in an other way (by default all power modes but idle are blocked keeping usec running).
As soon as you try to meassure time with usec now while nothing else is running on that and u activate pm_layerd you should not think of it as meassure time but time the cpu was in idle or higher.

gcoap with #17141 does not run any timer on ztimer_usec -> will not keep usec running. (it is just running because other thing are done)

Is it save to use for gcoap at that one point (you know the one that is allready mentioned trice in the gcoap-ztimer PR)?

i think so as it is just used to keep track of doublets of packages -> these are send while the cpu is working -> CPU-OSC active

#17229 would be a save alternative for now (create a timer an ask how log it takes for it to expire (and when it expires you may start another one/or not if u do not need it any more)).
#16698 includes some of the issues.
#16969 amplifies the issue for extended timers (atm these are potential power hogs)
(and i would like to worsen it (to improve power saving) (stop every clock that has no timer on it) but atm there is the ztimer64 PR which is traveling the opposite direction (absolute time -> needs the clock allways running -> constant power hog)

This was referenced Jan 28, 2022
Closed
Merged
@kfessel
Copy link
Contributor
kfessel commented Feb 18, 2022

@haukepetersen i think this i fixed by #16958

@haukepetersen
Copy link
Contributor Author

Yes :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@kaspar030 kaspar030

@fjmolinas fjmolinas

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

event/timeout: remove forced ZTIMER_USEC dependency haukepetersen/RIOT
4 participants
@haukepetersen @kfessel @kaspar030 @fjmolinas
2A2E
0