Bounce is taken care of with a capacitor. I've not had any false button Push count errors.
Got it. It would not hurt to strengthen your code, and eliminate answering the questions that will always arise if you do not, by adding a check in the ISR.
void buttonPush() {
buttonPushes[buttonPushCount] = millis();
if (++buttonPushCount >= 133) {
buttonPushCounter = 0;
dataOverrun = true;
}
}
Where dataOverrun is a flag you can test when you begin your analysis phase.
Or whatever, you get the idea. There's plenty of time to do the check.
Belt and suspenders. It isn't a good idea to count in everything always going to plan. I for one suspected that you could overrun not thinking that bouncing can add up fast.
a7
Fixed it!
It just needed one more line in the while loop to use the last count variable - something I meant to put in from the start (hence the < rather than <=) but overlooked.
So the void loop() now looks like this:
void loop() {
delay(10000); // period between analysis
calcCount = 0;
if (!buttonPushCount) { // if there haven't been any activations,
buttonPushes[0] = millis(); // set the start time to the current time
} else { // otherwise copy the buttonPushes array to the calcPushes array
while (calcCount < buttonPushCount) {
calcPushes[calcCount] = buttonPushes[calcCount];
calcCount++;
} // while (calcCount < buttonPushCount)
calcPushes[calcCount] = buttonPushes[calcCount]; // copy the last value
buttonPushCount = 0; // reset the array to the start
buttonPushes[0] = calcPushes[calcCount]; // and the time to the last buttonpush time
} // else
} // void loop()
Many thanks to all for your valuable input - that was much appreciated.
I was really pleased that it worked - so I decided to transfer the code to an ESP32, to integrate it with a project I'm working on (more for educational purposes than anything else).
It didn't work! So I stripped it down to the very basics, and it still didn't work! Any ideas?
const byte interruptPin = 2;
volatile int ButtonCount = 0;
void IRAM_ATTR ButtonPress() {
ButtonCount++;
}
void setup() {
Serial.begin(115200);
pinMode(interruptPin, INPUT_PULLUP);
attachInterrupt(interruptPin, ButtonPress, FALLING);
} // void setup()
void loop() {
delay(10000);
Serial.print("Button presses: ");
Serial.println(ButtonCount);
ButtonCount = 0;
} // void loop()
Missing digitalPinToInterrupt(), see attachInterrupt()
I tried both with and without digitalPinToInterrupt(), but ButtonPress stays at 0. I also noticed that when I place the ISR after the setup or loop, I get a Compilation error: 'ButtonPress' was not declared in this scope. Yet, examples I've seen on-line often place the ISR at the bottom.
Make it an ordinary function, not an ISR.
I found it! - I changed the pin to GPIO4 and now it works.
Although documentation states that any pin can be used for an interrupt, I either have a faulty pin or pin 2 isn't really suitable.
Thanks for your help DrDiettrich.
I think that you changed too much without telling us. I'm out.
I changed it after finding out that pin 2 is used for led built-in. Your steering me in directions I hadn't considered really helped. Many thanks.
When you use this volatile multi-byte variable outside the ISR, you need to do so with interrupts off.
You'll see
noInterrupts();
int myCopy = ButtonCount;
ButtonCount = 0;
interrupts();
then use myCopy everywhere.
Or you could make it a byte, like literally the type byte or char (signed char here) or whatever.
It may be working fine now, but this is an error waiting to bite you. See what I did the there?
It's conceivable that your pins are fine, even.
a7
Thanks for that, since the count should never exceed 133, or probably even 45 (depending on what frequency I end up with), I'll use the byte option. One thing I noticed is that the inclusion of IRAM_ATTR caused the issue of where the ISR is placed in the script. Without it it can go towards the end. I'll keep it in though and leave it near the start, that should speed it up.
Makes no difference if the sketch compiles. Zero.
So put it where you want. And this may be the subtle error type of thing you get from the unprotected access.
Now… see if the pin what didn't work now does. You will maybe have fixed the hardware using software, haha.
a7
Unfortunately, nothing from pin 2 still. Pin 4 is fine though, there are plenty for this project.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.