I'm trying to write this program where anytime a sensor is triggered I want to have a delay of lets say 3 seconds then do some action, that should be very simple.
Ideally it should go (sensor triggered) 3... 2... 1... (Do Something), what I'm struggling with is the scenario where countdown begins 3... 2... (sensor triggered again) 1... (Do Something) , now that's where things fall apart because I need another delay to begin the countdown from 3 concurrently but I don't know how to achieve that. I wish I could post that part of the code but the entire thing is linked together. Is there a way to do this with a simple C code or does this need advanced techniques ?
There are many ways:
Use threads. The sensor thread will read the sensor and the sleep for 3 seconds.
Use not blocking delays
unsigned getTick(void); // for example 1000 ticks per second
vooid foo(void)
{
unsigned sensor1StartTime = 0;
while(1)
{
if(!sensor1StartTime || (getTick() - sensor1StartTime >= 3000))
{
handleSensor1(); // it will be executed every ~three seconds
sensor1StartTime = getTick();
}
// do something else
// "something else" will not be blocked by delay.
}
}
Whenever a sensor triggers, start a thread, delay (do your count down) and do some thing (whatever you want to do) inside the thread function.
Related
I came across this code by Ganssle regarding switch debouncing. The code seems pretty efficient, and the few questions I have maybe very obvious, but I would appreciate clarification.
Why does he check 10 msec for button press and 100 msec for button release. Can't he just check 10 msec for press and release?
Is polling this function every 5 msec from main the most effecient way to execute it or should I check for an interrupt in the pin and when there is a interrupt change the pin to GPI and go into the polling routine and after we deduce the value switch the pin back to interrupt mode?
#define CHECK_MSEC 5 // Read hardware every 5 msec
#define PRESS_MSEC 10 // Stable time before registering pressed
#define RELEASE_MSEC 100 // Stable time before registering released
// This function reads the key state from the hardware.
extern bool_t RawKeyPressed();
// This holds the debounced state of the key.
bool_t DebouncedKeyPress = false;
// Service routine called every CHECK_MSEC to
// debounce both edges
void DebounceSwitch1(bool_t *Key_changed, bool_t *Key_pressed)
{
static uint8_t Count = RELEASE_MSEC / CHECK_MSEC;
bool_t RawState;
*Key_changed = false;
*Key_pressed = DebouncedKeyPress;
RawState = RawKeyPressed();
if (RawState == DebouncedKeyPress) {
// Set the timer which will allow a change from the current state.
if (DebouncedKeyPress) Count = RELEASE_MSEC / CHECK_MSEC;
else Count = PRESS_MSEC / CHECK_MSEC;
} else {
// Key has changed - wait for new state to become stable.
if (--Count == 0) {
// Timer expired - accept the change.
DebouncedKeyPress = RawState;
*Key_changed=true;
*Key_pressed=DebouncedKeyPress;
// And reset the timer.
if (DebouncedKeyPress) Count = RELEASE_MSEC / CHECK_MSEC;
else Count = PRESS_MSEC / CHECK_MSEC;
}
}
}
Why does he check 10 msec for button press and 100 msec for button release.
As the blog post says, "Respond instantly to user input." and "A 100ms delay is quite noticeable".
So, the main reason seems to be to emphasize that the make-debounce should be kept short so that the make is registered "immediately" by human sense, and that the break debounce is less time sensitive.
This is also supported by a paragraph near the end of the post: "As I described in the April issue, most switches seem to exhibit bounce rates under 10ms. Coupled with my observation that a 50ms response seems instantaneous, it's reasonable to pick a debounce period in the 20 to 50ms range."
In other words, the code in the example is much more important than the example values, and that the proper values to be used depends on the switches used; you're supposed to decide those yourself, based on the particulars of your specific use case.
Can't he just check 10 msec for press and release?
Sure, why not? As he wrote, it should work, even though he wrote (as quoted above) that he prefers a bit longer debounce periods (20 to 50 ms).
Is polling this function every 5 msec from main the most effecient way to execute it
No. As the author wrote, "All of these algorithms assume a timer or other periodic call that invokes the debouncer." In other words, this is just one way to implement software debouncing, and the shown examples are based on a regular timer interrupt, that's all.
Also, there is nothing magical about the 5 ms; as the author says, "For quick response and relatively low computational overhead I prefer a tick rate of a handful of milliseconds. One to five milliseconds is ideal."
or should I check for an interrupt in the pin and when there is a interrupt change the pin to GPI and go into the polling routine and after we deduce the value switch the pin back to interrupt mode?
If you implement that in code, you'll find that it is rather nasty to have an interrupt that blocks the normal running of the code for 10 - 50ms at a time. It is okay if checking the input pin state is the only thing being done, but if the hardware does anything else, like update a display, or flicker some blinkenlights, your debouncing routine in the interrupt handler will cause noticeable jitter/stutter. In other words, what you suggest, is not a practical implementation.
The way the periodic timer interrupt based software debouncing routines (shown in the original blog post, and elsewhere) work, they take only a very short amount of time, just a couple of dozen cycles or so, and do not interrupt other code for any significant amount of time. This is simple, and practical.
You can combine a periodic timer interrupt and an input pin (state change) interrupt, but since the overhead of many of the timer-interrupt-only -based software debounces is tiny, it typically is not worth the effort trying to combine the two -- the code gets very, very complicated, and complicated code (especially on an embedded device) tends to be hard/expensive to maintain.
The only case I can think of (but I'm only a hobbyist, not an EE by any means!) is if you wanted to minimize power use for e.g. battery powered operation, and used the input pin interrupt to bring the device to partial or full power mode from sleep, or similar.
(Actually, if you also have a millisecond or sub-millisecond counter (not necessarily based on an interrupt, but possibly a cycle counter or similar), you can use the input pin interrupt and the cycle counter to update the input state on the first change, then desensitize it for a specific duration afterwards, by storing the cycle counter value at the state change. You do need to handle counter overflow, though, to avoid the situation where a long ago event seems to have happened just a short time ago, due to counter overflowing.)
I found Lundin's answer quite informative, and decided to edit my answer to show my own suggestion for software debouncing. This might be especially interesting if you have very limited RAM, but lots of buttons multiplexed, and you want to be able to respond to key presses and releases with minimum delay.
Do note that I do not wish to imply this is "best" in any sense of the world; I only want you to show one approach I haven't seen often used, but which might have some useful properties in some use cases. Here, too, the number of scan cycles (milliseconds) the input changes are ignored (10 for make/off-to-ON, 10 for break/on-to-OFF) are just example values; use an oscilloscope or trial-and-error to find the best values in your use case. If this is an approach you find more suitable to your use case than the other myriad alternatives, that is.
The idea is simple: use a single byte per button to record the state, with the least significant bit describing the state, and the seven other bits being the desensitivity (debounce duration) counter. Whenever a state change occurs, the next change is only considered a number of scan cycles later.
This has the benefit of responding to changes immediately. It also allows different make-debounce and break-debounce durations (during which the pin state is not checked).
The downside is that if your switches/inputs have any glitches (misreadings outside the debounce duration), they show up as clear make/break events.
First, you define the number of scans the inputs are desensitized after a break, and after a make. These range from 0 to 127, inclusive. The exact values you use depend entirely on your use case; these are just placeholders.
#define ON_ATLEAST 10 /* 0 to 127, inclusive */
#define OFF_ATLEAST 10 /* 0 to 127, inclusive */
For each button, you have one byte of state, variable state below; initialized to 0. Let's say (PORT & BIT) is the expression you use to test that particular input pin, evaluating to true (nonzero) for ON, and false (zero) for OFF. During each scan (in your timer interrupt), you do
if (state > 1)
state -= 2;
else
if ( (!(PORT & BIT)) != (!state) ) {
if (state)
state = OFF_ATLEAST*2 + 0;
else
state = ON_ATLEAST*2 + 1;
}
At any point, you can test the button state using (state & 1). It will be 0 for OFF, and 1 for ON. Furthermore, if (state > 1), then this button was recently turned ON (if state & 1) or OFF (if state & 0) and is therefore not sensitive to changes in the input pin state.
In addition to the accepted answer, if you just wish to poll a switch from somewhere every n ms, there is no need for all of the obfuscation and complexity from that article. Simply do this:
static bool prev=false;
...
/*** execute every n ms ***/
bool btn_pressed = (PORT & button_mask) != 0;
bool reliable = btn_pressed==prev;
prev = btn_pressed;
if(!reliable)
{
btn_pressed = false; // btn_pressed is not yet reliable, treat as not pressed
}
// <-- here btn_pressed contains the state of the switch, do something with it
This is the simplest way to de-bounce a switch. For mission-critical applications, you can use the very same code but add a simple median filter for the 3 or 5 last samples.
As noted in the article, the electro-mechanical bounce of switches is most often less than 10ms. You can easily measure the bouncing with an oscilloscope, by connecting the switch between any DC supply and ground (in series with a current-limiting resistor, preferably).
I wrote a code for determining the push button state wheather it's long pressed or not. By the way this function is called by a timer interrupt routine in every 1 ms.
If you pressed more than 1 second, LongPressed is active ShortPressed is passive .so vice versa.
1- But it seems really dummy how can I make it shorter and more efficient according to both readibilty and professional rules?
BTW I updated the code like below.
void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
/*button pressed and count*/
if(!HAL_GPIO_ReadPin(GPIOC, GPIO_PIN_13))
{
usTick++;
}
/*not pressed*/
else
{
if( usTick > 1000){
ButtonState.PressedState = LongPressed;
HAL_GPIO_TogglePin(GPIOA,GPIO_PIN_5);
usTick = 0;
}
else if( usTick >350){
ButtonState.PressedState = ShortPressed;
HAL_GPIO_TogglePin(GPIOA,GPIO_PIN_5);
usTick = 0;
}
usTick = 0;
}
}
2- What should I add or change to get double Tap pressing information in this updated code?
Almost every STM32 timer has "external trigger synchronization" function. You can read about it in timer functional description in reference manual. You can use "Slave mode: Trigger mode" to start counting on "button down" event. And in EXTI interrupt of "button up event" you can read timer counter and do your business.
I don't know how to implement this via HAL, but Standard Peripheral Library should have the example.
1) Your code is only able to handle 1 button. Make it object oriented to read n buttons.
1 ms is much too fast. 20 ms should work fine. Remember: humans are slow.
2) I once had spent some time creating a LED controller with two pushbutton rotary encoders. These would feature advanced programming methods by means of pushing them long or multiple times. You could use the result of my sparring (it was never completed) as inspiration. The button code is fairly complex, it should fulfill your needs. And I remember it to be functional.
https://github.com/Jeroen6/LED-Rotary-Dimmer-SW/blob/master/user/button.c
https://github.com/Jeroen6/LED-Rotary-Dimmer-SW/blob/master/user/button.h
Forgive me for not having the indentations worked out correctly.
Arduino Nano and I need a timer within a timer and having some problems getting my head around the logic. I have played with some Libraries on GitHub, Timer, SimpleTimer and Metro but none seem to do what I need. Or, if they can I can't seem to get them to do it.
I need to switch a relay on for about 2-minutes and then off, every hour. I am trying
loop
{ if (millis() - 3600000 > TimeMax)
{ relay(on);
if (millis() - 12000 > relayMax)
TimeMax = millis();
}
}
It doesn't seem to work and I need this to all stay working within the "loop" as I have an nRF24L radio listening.
Could someone please help me with code snippets or at least an outline how to go about this.
Thanks
Ok, first of all timers in embedded dev speak means interrupts that gets fired after a delay. Generally speaking you want interrupts to handle very atomic actions, because you don't want to have an interrupt triggered while another one is triggered, because that could be the scenario of a horror movie.
But why would you want to make something hard, complex and overengineered, when it can be simple?
All you need to do is handle it through a simple dual state machine:
#define OPEN_DELAY 120*1000
#define CLOSE_DELAY 3600*1000
// N.B.: to be precise here, to make 2 minutes every hour,
// CLOSE_DELAY should be 3600*1000-OPEN_DELAY so it
// does not shift by 2 minutes every hour.
void loop() {
static bool open=false;
static long timestamp = millis();
if (!open && millis()-timestamp > CLOSE_DELAY) {
open=true; // change state
timestamp = millis(); // rearm timestamp
set_relay_on();
} else if (open && millis()-timestamp > OPEN_DELAY) {
open=false;
timestamp = millis();
set_relay_off();
}
}
The only reason you might want to use timer would be to save battery by keeping the AVR in sleep mode as much as possible. Then you'd set the timer to the biggest possible value before putting it to sleep, making it wake up the AVR with an interrupt every few seconds or so, so then you run the loop() once in CLOSE state going back to sleep — there you don't need to write an ISR, the main loop() is enough, or keeping it up for the full two minutes in OPEN state.
There's good documentation on timers you might want to read (beware the headaches, though):
http://maxembedded.com/2011/06/introduction-to-avr-timers/
Here's how to put the arduino to sleep for long delays:
http://www.bot-thoughts.com/2013/11/avr-watchdog-as-sleep-delay.html
HTH
I have begun to use explicit wait more and more to deal with asynchronous event on the page. For example i will wait for an element to be clickable before clicking it.
However many time i also face the situation when i need to wait an element to become stable, i.e. stop changing, before i will act on it. For example, i may do a query on a page, and wait for the search result (either shown in a list or a table) to stop changing, and then retrieve the results.
Off course, there will be a timeout period for this wait. So in a nutshell, i want to wait for a list or table while its values are not changed, say for 5 sec.
How to implement this kind of wait? Could anyone give a simple example in code, if possible?
Thanks,
Using FluentWait will do the job. Its advantage to implicitWait and explicitWait is that it uses polling and timeout frequency. For example, we have a timeout value of 5 seconds and 1 second for polling frequency. The element will be checked for every 1 second until it reaches the timeout value (5 sec). An exception is thrown if the timeout value is exceeded without having any result.
FluentWait is helpful in AJAX applications as well as in scenarios when element load time fluctuates often because it ignores specific types of exceptions like NoSuchElementExceptions while waiting for an element.
You can check the sample code for FluentWait here
I would do something like this. Basically you want to count what is changing, e.g. table rows, list elements, etc., wait X seconds, count again. If the count didn't change, you are done. If it did change, wait again.
int count = 0;
int newCount = 0;
boolean done = false;
while (!done)
{
newCount = driver.findElements(...).size();
if (newCount > count)
{
count = newCount;
}
else
{
// no new results, stop waiting
done = true;
}
Thread.sleep(2000);
}
Depending on your scenario, you might want to add an overall timeout so that you never exceed X minutes or whatever. Just add that to the while condition.
In my project, I have three buttons where each triggers a function.
This function have to do two things, one action when the button is pressed (actually working), but I want to add a second functionality, in which if the button is pressed for more then 3 seconds, it do something, like calling a function.
So far, i'm initializing the interruption:
attachInterrupt(0, footOne, Falling);
and the function is:
void footOne(){
static unsigned long last_interrupt_time = 0;
unsigned long interrupt_time = millis();
// Debounce
if (interrupt_time - last_interrupt_time > 200){
//Do things
if(debug==1){Serial.println("Button 1 pressed!");}
}
last_interrupt_time = interrupt_time;
}
Now I want to know how I can change the function to add the possibility if the button is pressed for longer then 3 seconds...
Remembering that this function is called from the interrupts.
Thank you!
With the way you have your program structured right now, you would need an external RTC to carry out this task. Once you initiate an interrupt, the internal clock on the arduino is compromised and therefore cannot be used reliably until leaving the interrupt. Is your implementation so time sensitive that an interrupt is required? Because if it isn't, polling the state of the button and then comparing the time elapsed would be a pretty easy implementation. If you want to stick with interrupts however, I'd take a look at volatile variables as a way to talk between your main loop and your interrupt functions.