M5Stack
M5Stack copied to clipboard
m5stack
M5.BtnA.wasPressed() conflicts with WiFi?
It appears that M5.BtnA.wasPressed() will not work properly if the M5Stack is currently connected via WiFi. I can't find any info on this so I'm posting it here to see if anyone knows anything about this and/or can duplicate what I'm seeing.
Is there some sort of resource conflict? It appears that BtnA can not be reliably used if the device is connected via WiFi. The pin appears to become unstable (no pullup/pulldown?) or maybe is being used for some other WiFi related function.
Leave code below as is to see unstable BtnA. Comment out just the thyree WiFi connect lines to see BtnA working as expected:
----- Code Below ---------------
#include <M5Stack.h> #include <WiFi.h>
void setup(){ M5.begin();
// Comment out the next three lines for Button A to work properly
WiFi.begin("SSID", "PWD");
while (WiFi.status() != WL_CONNECTED) {
}
M5.Lcd.println("Ready!"); }
void loop() {
if(M5.BtnA.wasPressed()) M5.Lcd.println("Button A");
M5.update(); }
I've had a similar issue and found out it goes away if you add Wire.begin(); just after M5.begin();
Thanks! But... I just tried your suggestion (in the example code above) and it doesn't appear to make a difference. BtnA is still "unstable"...
it does not help me too :(
I have in loop:
if(M5.BtnA.wasPressed()) {
M5.powerOFF();
}
and m5stack after ~10 sec goes to sleep without pressing any key! I receive on console debug msg from void M5Stack::powerOFF()
Enabling EXT0 wakeup on pins GPIO39
On deep sleep mode.
In M5Stack Community Forum, another user posted that this is an issue which is apparently a bug in the current IDF. Rolling back to a previous IDF apparently resolves it. So its a bug with the current espressif ESP32 arduino IDF: http://forum.m5stack.com/topic/174/m5-btna-waspressed-conflicts-with-wifi
Someone from m5stack team can check this problem?
latest arduino-esp32 github and this example (please change ssid and pass): test_wifi_pin39.zip
when wifi is connected then in main loop buttonA returns random presses without user interaction!
Hey, took me a while with Try&Error to disable ADC, ISR, DAC etc. until I recognized thats only a shit timing issue. A smal delay(10) helps and btnA is reading normal !
void loop() {
delay(10);
if(M5.BtnA.wasPressed()) M5.Lcd.println("Button A");
M5.update();
}
Seems to mitigate the issue in my "real world" sketch as well as my wifi test sketch.
Its a simple work-around, but it costs 10ms. Hopefully it will help someone find the root cause and actually fix it!
Nice! Thanks!
Actually changing the debounce doesn't cost anything as long as you M5.update() somewhere in your loop.
BTW - As I'm finding out - the 10ms delay helps but its not perfect. I'm still getting intermittant fake ButtonA presses every couple of minutes...
I will try a longer delay...
BTW - I don't believe its a debounce issue at all. We are getting ButtonA notifications even if the button is never touched.... (These aren't "duplicate" notifications)
agreed this is only a workaround, it's an ESP-IDF problem, right?
setting the debounce to 30ms is still enough to get a lightning fast response from the buttons
I have no idea why this is set at 5ms in the first place. polling any button pin that fast seems a bit overzealous anyway
Why would debounce have anything to do with a false reading from a button which was NEVER pressed?
Have you confirmed that changing the debounce mitigates the problem that simply enabling WiFi causes? Did you test it with the simple sample script I posted? Specifically, what debounce value/command did you use to mitigate this specific problem?
Why would debounce have anything to do with a false reading from a button which was NEVER pressed?
Because if excessive polling usually causes flakey readings, polling less often mitigates this negative effect. Since the debounce value is the only one that affects polling timing in the M5 library, poking with it seems the obvious first thing to do.
Of course a Serial.println(), a delay(15) or a Wire transaction in the loop will all have the same effect although none of which have anything to do with the real cause of the problem.
Anyway, another "workaround" that has nothing to do with the cause but still affects the results:
in Button.cpp, find Button::read(void) and change pinVal = digitalRead(_pin); to pinVal = analogRead(_pin);
-
Did you test your suggestion with the small posted example sketch to see if it works? What specific command did you use and where did you set it (setup()?)...
-
If your explanation is correct (fast polling times), then why aren't the other buttons (B&C) effected?
Well if your NOT going to test your theory with the sample sketch, tell us what you did to fix the sample sketch, and confirm that it actually works... How much credence should we give your proposed work-around?
You guessed wrong, also I don't care if you give credence to my words as long as it works for me and @0x1abin trusts this as a valid workaround.
Since you refused to test your workaround with the sample code, I did...
Changing the button debounce value in M5Stack.h from 5ms to 30 ms makes no difference for this problem. It just doesn't help...
the workaround that works "permanently" (currently in test for the last 40mn) is as follows:
In Button.cpp, find Button::read(void) and change:
pinVal = digitalRead(_pin); to pinVal = analogRead(_pin);
poke @0x1abin for validity
While changing the debounce delay in M5Stack.h does not seem to have any effect, changing the digitalRead to analogRead in Button.cpp seems to be working...
analogRead() didn't solve the problem for me. I still got wasPressed out of thin air.
Retesting.
I made a mistake before, replacing digitalRead() in the button construction, and not in ::read(). As soon as I corrected that (now analogRead in button::read()), the speaker starts making (loud) noise at the frequency at which wasPressed() is called (1khz). So I had to remove analogRead().
Trying now with DEBOUNCE_MS set to 30...
I mean the workaround is that we changed the debounce and used analogread.
As for the speaker noise, can it be turned off using dacWrite(25, 0);?
I have unsoldered my speaker to test an i2s module so I can't be sure of that.
ok, only DEBOUNCE didn't work as expected.
Fortunately dacWrite() fixes the speaker noise, so I try now with DEBOUNCE 30ms and analogRead() in button::read()...
So I can confirm that setting both DEBOUNCE_MS=30 and replacing digitalRead() with analogRead() in button::read() does solve the problem! Tx!
"...did you also change the debounce value ? @evanevery and I did both"
That's NOT correct. DEBOUNCE did nothing for me. I simply changed the code for AnalogRead. Thats all it required (for me)...
I'm sure that just a short-term mitigating correction. The library code needs to be properly repaired at the real source of the problem. There is no reason why an AnalogRead should need to be used instead of a DigitalRead...