Sometimes the interrupt responds late.

[vahithosan]

Hi. I made a circuit made with esp32. It controls Nema 34 (stepper motor). If it receives a signal from the start sensor, the motor starts. If it receives a signal from the stop sensor, the motor stops. I used rmt to drive the stepper motor with pulses. Also, according to the set speed, the motor accelerates and decelerates ramped. Step motor controls the label machine.

main_0823.zip

I run the sensor inputs with pin.irq.
I use timer for motor ramp. It accelerates with 10ms interval steps. It has a maximum of 10 steps.
I use RMT for step motor pulse train

MicroPython v1.22.0-preview.208.gb5449b0f0.dirty on 2023-12-04; Generic ESP32 module with ESP32
Type "help()" for more information.

I have an interesting problem. At every 36th motor stop signal, the motor stop is delayed. It works about 300-500ms more than it should. I tried with pwm instead of rmt to see if maybe it is conflicting with rmt, spi or irq. The result is the same again

I don't know how to find error.

There was no such problem before.

I couldn't compile with the previous esp-idf version4.4.2, I saw this error:

Traceback (most recent call last):
File "/home/nart/Masaüstü/MP_118_442/micropython/esp-idf/tools/idf_tools.py", line 1860, in
main(sys.argv[1:])
File "/home/nart/Masaüstü/MP_118_442/micropython/esp-idf/tools/idf_tools.py", line 1856, in main
action_func(args)
File "/home/nart/Masaüstü/MP_118_442/micropython/esp-idf/tools/idf_tools.py", line 1423, in action_install
targets = clean_targets(args.targets)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/nart/Masaüstü/MP_118_442/micropython/esp-idf/tools/idf_tools.py", line 1085, in clean_targets
export_targets_to_idf_env_json(targets_from_tools_json)
File "/home/nart/Masaüstü/MP_118_442/micropython/esp-idf/tools/idf_tools.py", line 1053, in export_targets_to_idf_env_json
targets = list(set(targets + get_user_defined_targets()))
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/nart/Masaüstü/MP_118_442/micropython/esp-idf/tools/idf_tools.py", line 1099, in get_user_defined_targets
if env == idf_env_json['idfSelectedId']:
~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
KeyError: 'idfSelectedId'

[vahithosan]

Update.

I found the reason for the time drift. It happens when writing a json file.

sayac.json:

{
    "adet_say": 0,
    "total_say": 0,
}

Test file:

import time
import ujson

def sayac1Guncelle():
    with open('sayac.json', 'w') as sayacDosya:
        ujson.dump(sayac, sayacDosya)


for i in range(100):
    start = time.ticks_ms() # get millisecond counter
    sayac1Guncelle()
    delta = time.ticks_diff(time.ticks_ms(), start) # compute time difference
    print(i," ",delta)
    time.sleep(0.5)

Output:

No:   Elapsed Time
0   15
1   10
2   10
3   10
4   10
5   10
6   10
7   10
8   10
9   10
10   10
11   10
12   10
13   10
14   10
15   420
16   10
17   10
18   10
19   10
20   10
21   10
22   10
23   10
24   10
25   10
26   10
27   10
28   10
29   10
30   10
31   10
32   10
33   10
34   10
35   10
36   10
37   10
38   10
39   10
40   10
41   10
42   10
43   10
44   10
45   10
46   10
47   10
48   10
49   10
50   10
51   10
52   10
53   10
54   10
55   10
56   430
57   10
58   10
59   10
60   10
61   10
62   10
63   10
64   10
65   10
66   10
67   10
68   10
69   10
70   10
71   10
72   10
73   20
74   10
75   10
76   10
77   10
78   10
79   10
80   10
81   10
82   10
83   10
84   10
85   10
86   10
87   10
88   10
89   10
90   10
91   10
92   10
93   10
94   10
95   10
96   10
97   430
98   10
99   10

[andrewleech]

Ah yes, there's been a couple of other recent discussions about slow file writes, it's a really common trap on all embedded platforms.

For work projects I'll often write data / logs to a large ram buffer during processing, then just write that buffer to file once the unit is idle. You lose that data if the board crashes though, and it doesn't help if the unit is never idle.
.
Alternatively you can use faster storage like SD card that won't interrupt the code for as long.

[peterhinch]

Or use chips such as EEPROM or FRAM with this repo. Flash has the merit of huge capacity with the drawback of long block erase times.