Hi Sara,
Actually it is not incorrect, because inside the timer start function
the interruption it enabled to call the ISR (the callback function).
Let's use the nRF52 as example, inside setcallback() we have:
/* Save the new callback */
priv->callback = callback;
priv->arg = arg;
if (callback != NULL && priv->started == true)
{
NRF52_TIM_SETISR(priv->tim, nrf52_timer_handler, priv);
NRF52_TIM_ENABLEINT(priv->tim, NRF52_TIMER_INT);
}
But inside nrf52_timer_start() we have it again:
if (priv->callback != NULL)
{
NRF52_TIM_SETISR(priv->tim, nrf52_timer_handler, priv);
NRF52_TIM_ENABLEINT(priv->tim, NRF52_TIMER_INT);
}
So, this way the code will work, no matter the order we call it.
BR,
Alan
On 9/29/20, Sara da Cunha Monteiro de Souza
<saramonteirosouz...@gmail.com> wrote:
> Hi all,
>
> I realized a logic issue in the Timers' Example.
> The ioctl notification is called before the ioctl start in order to set the
> timer callback. The set callback function, in the lower half layer, sets
> the callback and enables the interruption, but to do so, it dependes on 2
> conditions:
>
> 1. It depends on have a non NULL callback.
> 2. It depends on having the timer started previously. And it is verified
> through a variable from the timers' status.
>
> Since the variable is set in the start function, if ioctl notification is
> called before the ioctl start, the callback will never be set.
>
> There is also other issue regarding the stop implementation in the lower
> half layer that I've seen. The stop function usually reset the driver
> status to false to indicate the timer was stopped, but it does not make the
> callback NULL. I am not sure if this was the expected behaviour. Maybe, we
> could set the callback to NULL in the end of stop function.
>
> Regards,
>
> Sara S
>
