ppisa commented on code in PR #16491:
URL: https://github.com/apache/nuttx/pull/16491#discussion_r2150725063


##########
arch/risc-v/src/common/espressif/esp_pcnt.c:
##########
@@ -642,8 +646,34 @@ static int esp_pcnt_unit_get_count(struct cap_lowerhalf_s 
*dev, int *ret)
     }
 
   flags = spin_lock_irqsave(&priv->lock);
-  *ret = pcnt_ll_get_count(ctx.dev, priv->unit_id) +
-      priv->accum_value;
+  tmp_count = pcnt_ll_get_count(ctx.dev, priv->unit_id);
+
+  if (priv->config.accum_count)
+    {
+      intr_status = pcnt_ll_get_intr_status(ctx.dev);
+      if (intr_status & PCNT_LL_UNIT_WATCH_EVENT(priv->unit_id))
+        {
+          event_status = pcnt_ll_get_event_status(ctx.dev, priv->unit_id);
+          while (event_status)
+            {
+              int event_id = __builtin_ffs(event_status) - 1;
+              event_status &= (event_status - 1);
+
+              if ((event_id == PCNT_LL_WATCH_EVENT_LOW_LIMIT) && \
+                  (tmp_count >= (priv->config.low_limit / 2)))
+                {
+                  tmp_count += priv->config.low_limit;
+                }
+              else if ((event_id == PCNT_LL_WATCH_EVENT_HIGH_LIMIT) && \
+                       (tmp_count <= (priv->config.high_limit / 2)))
+                {
+                  tmp_count += priv->config.high_limit;
+                }
+            }
+        }
+    }
+
+  *ret = tmp_count + priv->accum_value;

Review Comment:
   I do not see any option to solve problem without checking if we are before 
or after overflow from the position itself. PCNT_Ux_CNT_REG and corresponding 
PCNT_Ux_STATUS_REG are not placed in the single 32-bit aligned word, so there 
is no chance to read them in sync and no chance resolve the problem and race 
time-window. We do not manipulate with IRQ related data and hopefully even with 
bits (if the read side effect of status is checked by somebody with 
insight/sources of the digital design) outside of the IRQ. I not see other way 
then to use count itself to resolve the situation and possibility of so much 
shifted misread even that probability is very low (one crash per month, week) 
is no-go for PCNT use in motor control.



-- 
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

Reply via email to