Re: supporting tickless and non-tickless using arch_timer/alarm/rtc
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
Re: max sleep and tickless with no alarm
Actually, I see this in arch_timer.c/arch_alarm.c: # ifndef CONFIG_SCHED_TICKLESS_LIMIT_MAX_SLEEP #error CONFIG_SCHED_TICKLESS_LIMIT_MAX_SLEEP must be set to use CONFIG_SCHED_TICKLESS # endif So I think this is somehow being enforced but it is in a really awkward place. I will open an issue. Best, Matias On Thu, Sep 3, 2020, at 01:09, Matias N. wrote: > Hi, > question related to other e-mail. Looking at how tickless is handled when > SCHED_TICKLESS_ALARM is not defined it seems strange that not specifying > maximum is even possible as it cannot be expected that up_timer_start() will > succeed for arbitrarily long timeouts. In fact, up_timer_start() may fail due > to the underlying timer reporting an error in this case, but this error is > only logged to console and not really handled. On the other hand, if > SCHED_TICKLESS_ALARM I see no reason why sleep should be limited since it is > specified in absolute value in the future. So it seems to me that > CONFIG_SCHED_TICKLESS_LIMIT_MAX_SLEEP should not be an option but instead the > limit be mandatory, and only for when SCHED_TICKLESS_ALARM is not defined. > > Am I thinking this right? > > Best, > Matias
RE: max sleep and tickless with no alarm
Yes, it's better to auto select SCHED_TICKLESS_LIMIT_MAX_SLEEP under config TIMER_ARCH/ALARM_ARCH. > -Original Message- > From: Matias N. > Sent: Friday, September 4, 2020 12:09 AM > To: dev@nuttx.apache.org > Subject: Re: max sleep and tickless with no alarm > > Actually, I see this in arch_timer.c/arch_alarm.c: > > # ifndef CONFIG_SCHED_TICKLESS_LIMIT_MAX_SLEEP > #error CONFIG_SCHED_TICKLESS_LIMIT_MAX_SLEEP must be set to use > CONFIG_SCHED_TICKLESS > # endif > > So I think this is somehow being enforced but it is in a really awkward > place. I will open an issue. > > Best, > Matias > > On Thu, Sep 3, 2020, at 01:09, Matias N. wrote: > > Hi, > > question related to other e-mail. Looking at how tickless is handled when > > SCHED_TICKLESS_ALARM is not defined it seems strange > that not specifying maximum is even possible as it cannot be expected that > up_timer_start() will succeed for arbitrarily long timeouts. > In fact, up_timer_start() may fail due to the underlying timer reporting an > error in this case, but this error is only logged to console and > not really handled. On the other hand, if SCHED_TICKLESS_ALARM I see no > reason why sleep should be limited since it is specified in > absolute value in the future. So it seems to me that > CONFIG_SCHED_TICKLESS_LIMIT_MAX_SLEEP should not be an option but > instead the limit be mandatory, and only for when SCHED_TICKLESS_ALARM is not > defined. > > > > Am I thinking this right? > > > > Best, > > Matias
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
stm32 uart init bug?
I ran into a strange issue with serial init for STM32. If the UART is already enabled/configured, our configuration does not seem to apply. I discovered this because I used a bootloader to flash and run NuttX on the arm/stm32/b-g474e-dpow1 board. The bootloader configs the UART for 115200 baud 8E1. This is how nsh looks if I type 'help' command: nsh> [hp hp usag hp [v] [md>] d smvs unam [ p mbmsp umun mp as mkd pnsuuns basnam dnam hp mkd pd s usp bak ddhdump mhmm d a h k mun md u nsh> [ This is because Even Parity (and possibly other stale config) is still in effect from the bootloader. When I flash and run NuttX without the bootloader, the nsh prompt works correctly with 115200 baud 8N1. Has anyone seen this before?
Re: stm32 uart init bug?
Some IP blocks need to be disabled to modify some registers. David On Thu, Sep 3, 2020, 3:45 PM Nathan Hartman wrote: > I ran into a strange issue with serial init for STM32. If the UART is > already enabled/configured, our configuration does not seem to apply. > > I discovered this because I used a bootloader to flash and run NuttX > on the arm/stm32/b-g474e-dpow1 board. The bootloader configs the UART > for 115200 baud 8E1. > > This is how nsh looks if I type 'help' command: > > nsh> [hp > hp usag hp [v] [md>] > >d smvs unam > [ p mbmsp umun >mp as mkd pnsuuns > basnam dnam hp mkd pd s usp > bak ddhdump mhmm d > a h k mun md u > nsh> [ > > This is because Even Parity (and possibly other stale config) is still > in effect from the bootloader. > > When I flash and run NuttX without the bootloader, the nsh prompt > works correctly with 115200 baud 8N1. > > Has anyone seen this before? >
Re: stm32 uart init bug?
Perhaps: Bit 10PCE: Parity control enableThis bit selects the hardware parity control (generation and detection). When the parity control is enabled, the computedparity is inserted at the MSB position (9th bit if M=1; 8th bit if M=0) and the parity is checked on the received data. This bit is set and cleared by software. Once it is set, PCE is active after the current byte (in reception and in transmission).0: Parity control disabled1: Parity control enabled/*This bitfield can only be writte*//*n when the USART is disabled (U*//*E=0).*/ Bit 9PS: Parity selectionThis bit selects the odd or even parity when theparity generation/detection is enabled (PCE bit set). It is set and cleared by software.The parity is selected after the current byte.0: Even parity1: Odd parityT/*his bitfield can only be writte*//*n when the USART is disabled (U*//*E=0)*/ On 9/3/2020 4:44 PM, Nathan Hartman wrote: I ran into a strange issue with serial init for STM32. If the UART is already enabled/configured, our configuration does not seem to apply. I discovered this because I used a bootloader to flash and run NuttX on the arm/stm32/b-g474e-dpow1 board. The bootloader configs the UART for 115200 baud 8E1. This is how nsh looks if I type 'help' command: nsh> [hp hp usag hp [v] [md>] d smvs unam [ p mbmsp umun mp as mkd pnsuuns basnam dnam hp mkd pd s usp bak ddhdump mhmm d a h k mun md u nsh> [ This is because Even Parity (and possibly other stale config) is still in effect from the bootloader. When I flash and run NuttX without the bootloader, the nsh prompt works correctly with 115200 baud 8N1. Has anyone seen this before?
Re: stm32 uart init bug?
On Thu, Sep 3, 2020 at 7:38 PM Gregory Nutt wrote: > Perhaps: > > Bit 10PCE: Parity control enableThis bit selects the hardware parity > control (generation and detection). When the parity control is enabled, > the computedparity is inserted at the MSB position (9th bit if M=1; 8th > bit if M=0) and the parity is checked on the received data. This bit is > set and cleared by software. Once it is set, PCE is active after the > current byte (in reception and in transmission).0: Parity control > disabled1: Parity control enabled/*This bitfield can only be writte*//*n > when the USART is disabled (U*//*E=0).*/ > > Bit 9PS: Parity selectionThis bit selects the odd or even parity when > theparity generation/detection is enabled (PCE bit set). It is set and > cleared by software.The parity is selected after the current byte.0: > Even parity1: Odd parityT/*his bitfield can only be writte*//*n when the > USART is disabled (U*//*E=0)*/ Yes, that looks like the culprit, in combination with the bootloader not being well behaved. I think we should ensure the USART is disabled before attempting to configure it. This probably was never caught before because it doesn't manifest as long as NuttX starts out of reset, or people who used serial bootloaders were using the more common 8N1 setting, or they were using a more well-behaved bootloader. In any case, I think it's best to ensure that we can configure the UART successfully no matter the initial conditions. I'll try to get a PR tomorrow. It's been a long day. Separately, I need to implement a custom bootloader for various reasons, so I'll make sure it performs a complete teardown before launching NuttX. :-) Thanks for your help, Nathan
