Hi Thomas, > Also, a clear and falsifiable problem statement should be given.
could you elaborate on what you mean by a problem statement being falsifiable? Do you want to be able to check that a given problem cannot be solved by existing features? > This should IMO address the question, why timer problems cannot be fixed by > simply repairing the xtimer (+ underlying HW abstractions). The mayor issue is that the API uses a fixed 1 µs resolution. As an uint32_t in 1 µs resolution would overflow after ~72 minutes, an uint64_t is needed as a direct consequence. This in turn results in the use of 64 bit arithmetic, which is very ill suited on IoT devices, especially on 8 bit and 16 bit platforms. Additionally, an API using 1µs resolution can be best implemented with fast timer hardware. But those usually prevent any power saving modes. This is very ill suited for the huge majority of IoT scenarios. Simply changing xtimer to use an RTT instead would solve the power saving issue. But RTTs usually operate at frequencies in the range of 1kHz - 32.678kHz. A base unit of 1µs makes very little sense in that case. And I'm aware of places in RIOT that depend on xtimer having a resolution in the order of microseconds; those would just break. All those issues are direct consequences of the use of a fixed 1 µs resolution. Allowing callers to specify the timer resolution would fix these. But that requires an API change. (All that reasoning is part of the wiki page already.) Kind regards, Marian On Mon, 9 Dec 2019 18:48:39 +0100 "Thomas C. Schmidt" <t.schm...@haw-hamburg.de> wrote: > Hi, > > if this is a "problem statement and design document", then concise and > measurable requirements on power management should go into the > corresponding section. > > Also, a clear and falsifiable problem statement should be given. This > should IMO address the question, why timer problems cannot be fixed by > simply repairing the xtimer (+ underlying HW abstractions). > > A long list of ztimer promises appears rather unessential and confusing. > > Thomas > > On 09/12/2019 17:45, Kaspar Schleiser wrote: > > Hi, > > > > On 12/9/19 4:52 PM, Kaspar Schleiser wrote: > >> Hi Robert, > >> > >> On 12/9/19 4:25 PM, Robert Hartung wrote: > >>> Do we need to put any thoughts in power management / low_power / > >>> integration with pm_layered? Or are the possible issues addreses / > >>> already talked about? > >> > >> Yes and yes. ;) > >> > >> I'll my thoughts so far. > > > > I've added this to the wiki page: > > > > # Power management considerations > > - currently, ztimer is pm_layered agnostic. If a timer is set on a > > periph_timer, this would probably not prevent sleep (timer would not > > trigger), whereas if a ztimer is set on a rtt, it would behave as > > expected (timer hardware keeps running in sleep, timer isr wakes up MCU). > > > > - (TODO) if a timeout has been set (e.g., `ztimer_set(clock, timeout)`), > > the backend device blocks sleeping if necessary. IMO this is the minimum > > requirement, but still needs to be implemented. > > > > - Idea: we specify that by convention, ZTIMER_MSEC (and ZTIMER_SEC) > > *keep running in sleep mode*, whereas ZTIMER_USEC stops when the MCU > > enters sleep (unless a timeout is scheduled). This is current behaviour > > *if* ZTIMER_USEC is using periph_timer as backend and ZTIMER_MSEC is > > using RTT/RTC. > > > > This would mean that `before = ztimer_now(clock); do something; diff = > > ztimer_now(clock) - before;` only works if either `do_something` does > > not schedule away the thread causing sleep *or* a clock is used that > > runs in sleep mode. > > > > - the behaviour could be accessible either through defines > > (ZTIMER_USEC_LPM_MODE or ZTIMER_USEC_DEEPSLEEP ...), *or* be made part > > of the ztimer API > > > > - in addition, we could add functions to explicitly tell the clocks to > > stay available until released, e.g., `ztimer_acquire(clock); before = > > ztimer_now(clock); do something; diff = ztimer_now(clock) - before; > > ztimer_release(clock);`. > > Once the "if timer is scheduled, don't sleep" is implemented, this > > could also be worked around by: > > `ztimer_set(clock, dummy, 0xffffffff); ...; ztimer_cancel(clock, > > dummy);` > > > > > > Feedback appreciated! > > > > Kaspar > > _______________________________________________ > > devel mailing list > > devel@riot-os.org > > https://lists.riot-os.org/mailman/listinfo/devel > > >
pgp9YsMqnufSk.pgp
Description: OpenPGP digital signature
_______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
