ppisa commented on PR #16491:
URL: https://github.com/apache/nuttx/pull/16491#issuecomment-2953952781
@Vajnar thanks for the update.
I would like to know from somebody from Espressif (@tmedicci) what is the
exact clearing condition of the events bits in `PCNT_Ux_STATUS_REG`. If it is
read by `about pcnt_ll_get_event_status()` function then the situation is more
complicated. I interpret the reference manual that it is not cleared by read,
but that it is overwritten, bit sets and cleared during each event occurrence.
Then the actual code should be correct. On the other hand, if the compare and
limit events are close then the HW can be unusable to tract all these events,
because the the second event clears the result of the first one. If the clear
is done at the time of clear of IRQ bit then it is better but there still a
window when the events can be lost but for limits far enough from zero it would
work for extending the range. If the status is clear by read as side effect
then actual code needs update.
To make actual code working on SMP system then the `flags =
spin_lock_irqsave(&unit->lock);` and the `spin_unlock_irqrestore(&unit->lock,
flags);` in the `esp_pcnt_isr_default()` has to be moved out of the loop to
cover all lines in the event processing after
```
pcnt_ll_clear_intr_status(ctx.dev, PCNT_LL_UNIT_WATCH_EVENT(unit_id));
event_status = pcnt_ll_get_event_status(ctx.dev, unit_id);
```
Then the code should be without contention time window with the possible
incorrect result.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
