Yes, arch_timer change the interrupt interval without stopping the timer first
to reduce the timer drift as much as possible. So the
timer driver has to remove the restriction from the code.
> -----Original Message-----
> From: Matias N. <mat...@imap.cc>
> Sent: Friday, September 4, 2020 2:13 AM
> To: dev@nuttx.apache.org
> Subject: Re: supporting tickless and non-tickless using arch_timer/alarm/rtc
>
> Hi Xiang,
> can you confirm that arch_timer.c assumes that the timer resets itself? (as
> if using STM32 autoreload?) It doesn't call
TIMER_STOP()
> on the underlying timer on timer_cancel(). In fact, it simply sets a maximum
> timeout.
> I understand this is because you also need the timer to be running to provide
> up_timer_gettime().
> If this is so, it would be incorrect to do this in
> stm32/nrf52_tim_lowerhalf.c (I'm using it as reference):
>
> static int stm32_settimeout(FAR struct timer_lowerhalf_s *lower, uint32_t
> timeout) {
> FAR struct stm32_lowerhalf_s *priv = (FAR struct stm32_lowerhalf_s *)lower;
> uint64_t maxtimeout;
>
> if (priv->started)
> {
> return -EPERM;
> }
> ...
>
> (nRF52 has the same check on priv->started). This means that the settimeout
> does not succeed.
> On my nrf52_rtc_lowerhalf.c I have removed this check and I get tickless
> working but this would mean the same fix should be
applied
> on other similar places. In principle this is OK because changing the timeout
> while timer is running should not be a problem.
>
> Best,
> Matias
>
> On Thu, Sep 3, 2020, at 12:29, Matias N. wrote:
> > Hi,
> > thanks, I will select TIMER_ARCH from Kconfig for this arch for now. I can
> > create an issue later.
> > I will also try to document these three drivers and link them from the
> > discussion about tickless support.
> >
> > Best,
> > Matias
