Hi Marian,
On 09/12/2019 20:06, Marian Buschsieweke wrote:
Also, a clear and falsifiable problem statement should be given.
could you elaborate on what you mean by a problem statement being falsifiable?
"falsifiable" is a standard principle in science: It is sometimes
difficult to verify a statement, if application contexts cannot be
exhaustively enumerated ("It never rains in California"). Falsification
is often simpler, since only a counter-example is needed. A statement
that is neither verifiable nor falsifiable is useless for rigorous
argumentation.
"RIOT needs an easy to use, efficient and flexible timer system" is such
a poster child of a non-arguable statement and may move to the introduction.
Regarding xtimer:
If the current 1 us resolution in the API is the key problem, then this
should be stated clearly in the problem statement so that it can be
questioned and discussed.
Best,
Thomas
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
--
Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group 20099 Hamburg, Germany °
° http://inet.haw-hamburg.de/members/schmidt Fon: +49-40-42875-8452 °
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
