Ok. I will open a ticket for this since stm32_tim_lowerhalf has this 
(unnecessary) limitation.

On Fri, Sep 4, 2020, at 06:43, Xiang Xiao wrote:
> 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
> 
> 

Reply via email to