ESP32: replaced the mod base circular increment #493
Conversation
|
@runger1101001 @askuric PTAL :) |
of the ADC buffer with a branch based option to avoid the compiler to use a MOD instruction that consumes several cycles. Signed-off-by: Felipe Neves <[email protected]>
uLipe
force-pushed
the
enhance/replace_mod
branch
from
0a23510 to
f5331e0
Compare
|
Oh wow, it's really surprising that the improvement is 5x! I'm curious, how did you test the execution times. If you have a short test program, it might be interesting to have it here somewhere for the future. :D Otherwise LGTM |
|
I assume the improvement is related to just this part of the code, where avoiding the division implied by modulo operator saves a lot compared to a simple compare operation. It might be even more robust to make it a >= comparison though... |
|
Hello folks, just clarifying. Yes the improvement is just related to this section of the code, which avoids the compiler to emit DIV instruction which is very slow. Hmmm that is true the comparison should be @askuric , about measuring the code execution time, this is ESP32 specific, there is a feature on the esp_system component inside of the IDF (where is the Arduino Core runs on top) called cache compensated timer, it uses the machine cycle counter which is cache compensated where you can place them around the code to measure and forward it to the Log system. I can place a code measurement example on the hardware specific section of example for ESP32 if you think it would be useful. |
To happen after the ADC reading to avoid shifting the order of the samples. Signed-off-by: Felipe Neves <[email protected]>
|
@runger1101001 just changed the comparison, also I re-ordered the ADC buffer index increment to happen after the ADC is read it was affecting the order of the phase-currents since the phase a was becoming swapped with second (on 2-phase measurement) and with the c (in 3 phase measurement setup). |
3 participants
The current low side sense of the ESP32 uses a mod based circular buffer increment which may consume some precious cycles, we address this issue by replacing it with the classic branch based circular increment which outspeed the current solution in more than 5 times.