er driver has to remove the restriction from the code.
>
> > -Original Message-
> > From: Matias N.
> > 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
&
> 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 t
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 t
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
> -Original Message-
> From: Matias N.
> Sent: Thursday, September 3, 2020 6:31 AM
> To: dev@nuttx.apache.org
> Subject: supporting tickless and non-tickless using arch_timer/alarm/rtc
>
> Hi,
> I'm looking into implementing tickless on nRF52 (first using sy
Hi,
I'm looking into implementing tickless on nRF52 (first using systick, since it
is an easy option, and then using a RTC timer, which works while CPU is
asleep). My intention is to use the arch timer driver for this
(drivers/timer/arch_timer.c) since it provides up_mdelay without using a busy
