Arduino anyone?

[skotl]

@Chippie you should also add some physical debouncing to the circuit. Given its just a button press a 100nF capacitor to ground on the input pin would suffice. If you do this then I doubt you'd need to do any software debouncing at all.

The problem with having no physical debouncing is that if you decided in the future to change the button presses to be handled in interrupts then you may end in a situation where the processor locks up because all it's time is taken in servicing the interrupt. Software implementation should not be a replacement for good physical design. Software debouncing usually came about because the hardware was fixed and could not be changed in deployment and I feel that people now use it as a replacement when it's not. Electronic debouncing can do much more than prevent spurious events (such as protecting the input pin).

Handling debouce in interrupts is painless as long as the interrupt is doing nothing more than setting the state of the button (i.e. you don't respond to the button press). This is code I use with ESP32 that will also will also work with Arduino (replace the esp.h include with arduino.h):

ButtonHandler.h

//
// Created by Scott# on 11/12/2023.
//

#ifndef BUTTONHANDLER_H
#define BUTTONHANDLER_H

namespace Buttons {

class ButtonHandler {
private:
bool _buttonWasPressed = false;

public:
void begin();
void update();
bool wasPressed();
};

} // Buttons

#endif //BUTTONHANDLER_H

ButtonHandler.cpp

//
// Created by Scott on 11/12/2023.
//

#include "ButtonHandler.h"

#include <cstdint>
#include <esp32-hal-gpio.h>
#include <HardwareSerial.h>
#include <WString.h>
#include <freertos/portmacro.h>
#include <freertos/task.h>

#define BUTTONPIN 13
#define DEBOUNCETIME 10

namespace Buttons
{
volatile int numberOfButtonInterrupts = 0;
volatile bool lastState;
volatile uint32_t debounceTimeout = 0;

portMUX_TYPE mux = portMUX_INITIALIZER_UNLOCKED;

void IRAM_ATTR handleButtonInterrupt()
{
portENTER_CRITICAL_ISR(&mux);
numberOfButtonInterrupts++;
lastState = digitalRead(BUTTONPIN);
debounceTimeout = xTaskGetTickCount(); //version of millis() that works from interrupt
portEXIT_CRITICAL_ISR(&mux);
}

void ButtonHandler::update()
{
uint32_t saveDebounceTimeout;
bool saveLastState;
int save;

portENTER_CRITICAL_ISR(&mux);
// so that value of numberOfButtonInterrupts, lastState are atomic - Critical Section
save = numberOfButtonInterrupts;
saveDebounceTimeout = debounceTimeout;
saveLastState = lastState;
portEXIT_CRITICAL_ISR(&mux); // end of Critical Section

bool currentState = digitalRead(BUTTONPIN);

if ((save != 0) //interrupt has triggered
&& (currentState == saveLastState) // pin is still in the same state as when intr triggered
&& (millis() - saveDebounceTimeout > DEBOUNCETIME))
{
if (currentState == LOW)
{
Serial.printf("Button is pressed and debounced, current tick=%d\n", millis());
}
else
{
Serial.printf("Button is released and debounced, current tick=%d\n", millis());
_buttonWasPressed = true;
}

Serial.printf("Button Interrupt Triggered %d times, current State=%u, time since last trigger %dms\n",
save, currentState, millis() - saveDebounceTimeout);

portENTER_CRITICAL_ISR(&mux); // can't change it unless, atomic - Critical section
numberOfButtonInterrupts = 0; // acknowledge keypress and reset interrupt counter
portEXIT_CRITICAL_ISR(&mux);
}
}

void ButtonHandler::begin()
{
pinMode(BUTTONPIN, INPUT);
pinMode(BUTTONPIN, INPUT_PULLUP);

attachInterrupt(digitalPinToInterrupt(BUTTONPIN), handleButtonInterrupt, CHANGE);
}

bool ButtonHandler::wasPressed()
{
const auto response = _buttonWasPressed;
_buttonWasPressed = false;

return response;
}
} // Buttons

...and consuming it in your main app:

#include <Buttons/ButtonHandler.h>
Buttons::ButtonHandler buttonHandler;

void setup() {
// ... other setup
buttonHandler.begin();
}

void loop() {

if (buttonHandler.wasPressed())
{
display.toggleDisplayMode();
refreshDisplay = true;
}

//... do other stuff
}

 

[skotl]

(on comments)... Ideally it shouldn't need any, however understanding the intent can be incredibly important when you can't reference back to pull requests and test data.

Exactly this. To say that code should never have any comments might only be viable for a single coder shop rather than where a team maintains code, but even then I'd argue that it's a slippery slope to believe that your code and function naming is always going to be crystal clear, even to you, in the future.

Comments may not necessarily describe what the code is doing (and I agree to an extent that well-written code should inform on this) but it absolutely should state why the code is doing what it is. How many people have come across a piece of code, thought "that's terrible and shouldn't do that", ripped it out and then discovered the edge cased that the apparently poor code actually covers.

Think about comment-derived documentation, too - a method that is exposed in an API is normally ///-commented to describe inputs, boundary restrictions, exceptions and behavior and the API documentation is generated directly from the comments. I tend to recommend that all public methods should also have this level of commenting so that consumers are aware of what the black-box is intended to do. Apart from anything else, it saves the consumer having to wade through pages of code to understand what will be achieved.

 

[ajlelectronics]

Exactly this. To say that code should never have any comments might only be viable for a single coder shop rather than where a team maintains code, but even then I'd argue that it's a slippery slope to believe that your code and function naming is always going to be crystal clear, even to you, in the future.

Quite so. I tend to have long breaks between updating my module software versions. I spend the first hour trying to recall how it is supposed to work, despite commenting inline.

 

[Kram]

That was a simple example to counter another simple example... Its not fun typing code on a phone!
Comments can be useful but its an exception rather than on every line. I dont think its worthy of any more discussion here, but I suggest good naming and small functions, grouped in classes allow easy reuse, testing etc.

 

[Chippie]

Handling debouce in interrupts is painless as long as the interrupt is doing nothing more than setting the state of the button (i.e. you don't respond to the button press). This is code I use with ESP32 that will also will also work with Arduino (replace the esp.h include with arduino.h):

ButtonHandler.h



ButtonHandler.cpp




...and consuming it in your main app:

Wow!…..Thanks for taking the time to write this, it’s above my pay grade…I’m just a simple nuts n bolts kinda fiddler when it comes to doing stuff with micro’s …I gave up with PIC micros for this reason and thought Arduino would be easier…

Well I’ll push on with what I have atm, and see where I get to…again thanks!

 

[ajlelectronics]

Wow!…..Thanks for taking the time to write this, it’s above my pay grade…I’m just a simple nuts n bolts kinda fiddler when it comes to doing stuff with micro’s …I gave up with PIC micros for this reason and thought Arduino would be easier…

Well I’ll push on with what I have atm, and see where I get to…again thanks!

I found that writing assembler / machine code for PICs was more logical and easier somehow.

 

[skotl]

Wow!…..Thanks for taking the time to write this, it’s above my pay grade…I’m just a simple nuts n bolts kinda fiddler when it comes to doing stuff with micro’s …I gave up with PIC micros for this reason and thought Arduino would be easier…

Well I’ll push on with what I have atm, and see where I get to…again thanks!

No worries - shout on here or via IM if you need any help with it

 

[skotl]

I found that writing assembler / machine code for PICs was more logical and easier somehow.

I agree but that's partly because PICs are far simpler than SOCs like the Arduino and ESP
Also, being limited to a tiny amount of RAM has unintended benefits as there's less tendency to put in all the bells'n'whistles!

 

[Red'n'Black]

@Chippie you should also add some physical debouncing to the circuit. Given its just a button press a 100nF capacitor to ground on the input pin would suffice. If you do this then I doubt you'd need to do any software debouncing at all.

The problem with having no physical debouncing is that if you decided in the future to change the button presses to be handled in interrupts then you may end in a situation where the processor locks up because all it's time is taken in servicing the interrupt. Software implementation should not be a replacement for good physical design. Software debouncing usually came about because the hardware was fixed and could not be changed in deployment and I feel that people now use it as a replacement when it's not. Electronic debouncing can do much more than prevent spurious events (such as protecting the input pin).

Yes, so long as the pin has hysteresis on the inputs, can't remember if the Arduino does or not. Otherwise the slow edges can give loads of 'phantom edges' within the chip as the voltage goes through the no-mans-land between logic low and logic high. Some micros are definitely worse for this than others, but it's something else you won't find in the chip data sheet.

 

[Red'n'Black]

It's usually better to have external pulls on outputs because the behaviour of the pins on the micro may be undefined at boot. Inputs it doesn't matter as much because you're only going to worry about them after you've initialised all the peripherals.

RC filter will introduce a series R but that will also limit current into the pin. 10k is far too high for a series R, a hundred ohms or less will suffice to limit current to protect the pin. You don't necessarily need to disable the internal pull ups but they're kind of redundancy / superfluous if you have external ones.

It's worse than that. Depending on where the Arduino came from (there are loads of clones knocking about nowadays) it may come pre-loaded with some demo code that blinks LEDs, etc.

The last design I did with one of these was driving a DC motor through an H bridge, so it could be reversed. So four transistors, each driven by an Arduino pin. One thing you must never do is turn both transistors on the same side on together, or the magic smoke escapes. We just plugged the module into our driver board and powered the whole thing on, thinking it would just do nothing until we'd loaded our code onto it. Guess what happened next?

 

[sako243]

Handling debouce in interrupts is painless as long as the interrupt is doing nothing more than setting the state of the button (i.e. you don't respond to the button press). This is code I use with ESP32 that will also will also work with Arduino (replace the esp.h include with arduino.h):

My point wasn't that it's painful to do it's that the mere fact you're firing the interrupt can cause issues.

Imagine a tight control loop on a PID controller where the process variables need to be updated deterministically. If a button is bouncing a lot then the micro has to pause execution, save stack state, jump into the interrupt handler, execute it and then restore state and carry on. Lots of bouncing results in lots of interrupts there's no ifs no buts that just happens. The fact lots of interrupts keep firing means that the main control loop doesn't get executed in a timely manner and bad things happen*. I agree in this trivial case it's not likely an issue but I'm just trying to make sure the OP is aware of the potential consequences and why some hardware decoupling is nearly always a good decision.

* case in point I was heavily involved in the design of a very efficient 3 phase to DC converter. In testing in the lab in Battersea we tripped our lab and also flickered the lights in the opposite building. This was because of a button press (wired in for debug purposes not production) which caused lots of interrupts to fire. As a consequence the PID control loop didn't compute the next value within the time frame that was required (1ms or something like that) and the loop went unstable. The result of which was the cabinet tried to pull a LOT of power. Tripping our building was one thing, the brownout of the building opposite was more impressive because we had a dedicated 3 phase, 400A/phase feed to Battersea substation. We browned out a good chunk of Battersea because of a button press.

 

[sako243]

Just remembered this, I haven't tested this in any way but you should hopefully get the idea of what I mean about looking for the edges of the buttons (as in previous state was high, now it's low).

#include <LiquidCrystal.h>
LiquidCrystal lcd(9, 8, 7, 6, 5, 4);
// Pin definitions
const int PIN_RELAY = 12;
const int PIN_KEY_UP = 3;
const int PIN_KEY_DOWN = 2;
// Global variables
bool previousDownPressed = false;
bool previousUpPressed = false;
int SetPoint = 0;
///////////////////////////////////////////////////////////////////////////////
// Setup and configuration
void configure_gpio( )
{
pinMode( PIN_RELAY, OUTPUT );
pinMode( PIN_KEY_UP, INPUT );
pinMode( PIN_KEY_DOWN, INPUT );
digitalWrite( PIN_KEY_UP, HIGH );
digitalWrite( PIN_KEY_DOWN, HIGH );
digitalWrite( PIN_RELAY, LOW );
}
void configure_lcd( )
{
lcd.begin( 16, 2 );
}
void setup( )
{
configure_gpio( );
configure_lcd( );
delay( 2000 );
// Display start screen
lcd.setCursor( 0, 0 );
lcd.print( "Temp ");
lcd.setCursor( 0, 1 );
lcd.print( "Controlller" );
}
///////////////////////////////////////////////////////////////////////////////
// Helper functions
double readTemperature( )
{
static const double VOLTS_2_DEGREES = ( 5.0 / 1024.0 ) * 100.0; // 10mV per degree
return VOLTS_2_DEGREES * analogRead( A0 );
}
bool isDownPressed( )
{
bool currentKeyPressed = ( digitalRead( PIN_KEY_DOWN) == LOW );
bool pressed = currentKeyPressed && !previousDownPressed;
previousDownPressed = currentKeyPressed;
return pressed;
}
bool isDownPressed( )
{
bool currentKeyPressed = ( digitalRead( PIN_KEY_UP) == LOW );
bool pressed = currentKeyPressed && !previousUpPressed;
previousUpPressed = currentKeyPressed;
return pressed;
}
///////////////////////////////////////////////////////////////////////////////
// Main loop
void loop( )
{
// Display current temperature
double temp = readTemperature( );
lcd.setCursor( 0, 0 );
lcd.print( "Temperature:" );
lcd.print( temp );
// Handle any user interactions
if ( isDownPressed( ) )
{
SetPoint -= 1;
}
if ( isUpPressed( ) )
{
SetPoint += 1;
}
if ( SetPoint < 0 )
{
SetPoint = 0;
}
if ( SetPoint > 150 )
{
SetPoint = 150;
}
// Display set point on UI
lcd.setCursor( 0, 1 );
lcd.print( "Set Point: ");
lcd.print( SetPoint );
lcd.print( "C" );
// Check temperature is in limit
if ( temp > SetPoint )
{
digitalWrite( PIN_RELAY, LOW ); // On
}
else
{
digitalWrite( PIN_RELAY, HIGH ); // Off
}
// 100ms loop cycle
delay( 100 );
}

I wouldn't personally write it like this but I've tried to keep it simpler and easy to understand for others. Then again I wouldn't use the Arduino code for some proper code but it does have it's place (might be using at the moment to de-risk a bit of a project ).