This looks rather hacky to me, and does once more point out the problems of xtimer. Logically, I would rather tend to use the lptim hardware to implement the periph/rtt interface, as the semantics of that interface fit better on the characteristics of the lptim (-> see cpu/stm32l4/periph/rtt_lptim.c). But this does of course not help in practice currently, as xtimer can not make use of that implementation.

For the long term we will have a redone/overworked high level timer system, that can simply utilize the rtt_lptim implementation, so in that context that would be my preferred way.

But for the short term, I see only two options: 'hack' the periph/timer implementation to make use of both tim and lptim hardware uints (as sketched in this PR), or to implement the periph/timer interface using the lptim separately and configure during compile time, which of the two implementations to use. The latter has the advantage of being more clean and straight forward, but it does of course allow only one of the two hardware timer options to be used...

Hi, what status of this issue now? @vincent-d

I did not work on this recently, as it didn't really reached a consensus.

But the LPTIM can be accessed through periph_rtt API.

If one think it still useful to add the support through periph_timer I could spend some time on it. The main goal IMO would be to use the LPTIM as xtimer backend. I also know that there is some work on a replacement for xtimer, but I have no idea what the status is, maybe @haukepetersen or @kaspar030 know.

I also know that there is some work on a replacement for xtimer, but I have no idea what the status is, maybe @haukepetersen or @kaspar030 know.

I have a working prototype here. Soon as the staging tree is in place (or an alternative), I'll PR so we can discuss more visibly. @gebart and @ZetaR60 also have coded towards better timers.

There's already a periph_rtt backend in ztimer, so LPTIM should already be usable with that.

I have a working prototype here. Soon as the staging tree is in place (or an alternative), I'll PR so we can discuss more visibly. @gebart and @ZetaR60 also have coded towards better timers.

@kaspar030, I don't understand why you think having the staging tree is a requirement for this feature. It appears that at least @vincent-d, @gebart, @ZetaR60 (all maintainers) are interested by such a feature and already started to also work on that on their side. They should be enough motivated (and I will) to give help and speed-up the review/merge process. Since it's a core feature, many existing features in RIOT will certainly benefit from it.
Having this feature will also help solving existing problems, especially with LoRa (see #10352, #10442 and others related).

Please open the PR asap!
I think that's long enough that we are waiting for it (I remember having heard about it during the Summit 2017... or maybe in Paris in May 2017).

@kaspar030, I don't understand why you think having the staging tree is a requirement for this feature.

I agree with this. I think it would be beneficial to merge your work directly in the mainline.

Closing this one anyway.

I don't understand why you think having the staging tree is a requirement for this feature.

It is not at all a requirement. I just didn't expect staging/ to be blocked that long, and I think something like ztimer would be quite useful even volatile and / or unpolished, thus ideal for staging/.