Use analogReadMilliVolts for esp32 and update hysteresis #635
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
brentru
added a commit
that referenced
this pull request
Oct 3, 2024
tyeth
force-pushed
the
use_analogReadMilliVolts-for-esp32-scaledAnalogRead-false
branch
from
50f1702
to
f7eebe6
Compare
tyeth
force-pushed
the
use_analogReadMilliVolts-for-esp32-scaledAnalogRead-false
branch
from
6129e63
to
e74fb1b
Compare
tyeth
changed the title
|
@brentru this is ready for review |
brentru
requested changes
Oct 15, 2024
| analogInputPin pin) { | ||
| if (currentTime - pin.prvPeriod > pin.period && pin.period != 0L) | ||
| bool Wippersnapper_AnalogIO::timerExpired(long currentTime, analogInputPin pin, | ||
| long periodOffset) { |
There was a problem hiding this comment.
Do we ever pass periodOffset in? When this func. is called on L531, it doesn't seem to include periodOffset.
When would we include periodOffset and why?
There was a problem hiding this comment.
I reuse the function / logic check for the on change delay, passing in 500, on line 381 https://github.com/adafruit/Adafruit_Wippersnapper_Arduino/pull/635/files#diff-4e111e8f7d844aa38d092958262d5b77683072105409145224c36ab513c0109cR381
| // note: on-change requires ADC DEFAULT_HYSTERISIS to check against prv | ||
| // pin value | ||
| uint16_t pinValRaw = getPinValue(_analog_input_pins[i].pinName); | ||
|
|
||
| // All boards ADC values scaled to 16bit, in future we may need to |
There was a problem hiding this comment.
Could you refactor this into a CalculateHysteresis function and call that function here?
tyeth
force-pushed
the
use_analogReadMilliVolts-for-esp32-scaledAnalogRead-false
branch
2 times, most recently
from
07b2512
to
603f0c9
Compare
tyeth
force-pushed
the
use_analogReadMilliVolts-for-esp32-scaledAnalogRead-false
branch
from
603f0c9
to
7b10b13
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For CI assets, testing https://github.com/tyeth/Adafruit_Wippersnapper_Arduino/blob/50f17026832ba9a53d0f919a69b8e9106302fe55/src/components/analogIO/Wippersnapper_AnalogIO.cpp#L90Combined PR including millivolt change and updated hysteresis method:
This PR now switches both periodic and on_change to use the same functions, along with using analogReadMilliVolts for ESP32 based boards.
Also this modifies the on_change event to use a sliding scale of hysteresis. Originally the code awaited a 2% change in the last raw value.
Now the scale is divided into thirds, with the lower third using the default hysteresis value of 2% applied to the whole 16bit max value (65k), which results in less bounce around 0 due to wifi / power fluctuations, the middle third using double that threshold change, and the last third quadruple that default hysteresis (where a 200mV spike was generally observed around 3.1v). There is also a 500ms anti-hammer situation on top of the hysteresis requirement.
Tested with a 10k stemma Potentiometer, and separately with a resistor divider to test stability.
It occurs to me that 500ms might be too long for some people, maybe it can be configurable in the future.