2023-08-15 07:48 PM
i am using NUCLEO-F410RB board
i followed the simple exti tutorial try to print "button pressed" to uart when the corresponding button is pressed
like most of the tutorial setting : interrupt rising edge . no pull up and pull down , one side of button is the certain pin and the other side is connect to the board 3.3V pin
and insert code like this
void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
{
if(GPIO_Pin == GPIO_PIN_14){
printf("button pressed");
}
}
i have tried several exti gate. they have the same problem
even i just plug a wire to the certain pin , the other end of wire has not connected anything yet
the uart would display a tons of 'button pressed' which means the exti was triggered multiple time
it is kind of weird
do you guys have encountered this problem before?
Solved! Go to Solution.
2023-08-15 09:07 PM - edited 2023-08-15 09:12 PM
Hello
add new line to the end of string:
printf("button pressed\n");
or add:
fflush(stdout);
after printf.
Now your printf's wait for buffer to fill. Your interrupt is probably working just fine.
BR J.T
2023-08-15 08:00 PM
Hello
Now your input pin is floating when button is not pressed and that is causing interrupts. You must either activate the internal pull-down or install external pull-down resistor to your board. Then the pull-down keeps your pin nicely low when button is not pressed.
Br J.T
2023-08-15 08:25 PM
Hi Br J.T
thanks for the advise
i tried to activate the internal pull-down to the pin
it doesn't trigger itself now.
but there is another issue. the exti not response immediately and not trigger correctly
after 5-6 presses to the button ,the uart print out like 20-30 'button pressed' on the screen
why a simple function can be so hard:loudly_crying_face:
2023-08-15 09:07 PM - edited 2023-08-15 09:12 PM
Hello
add new line to the end of string:
printf("button pressed\n");
or add:
fflush(stdout);
after printf.
Now your printf's wait for buffer to fill. Your interrupt is probably working just fine.
BR J.T
2023-08-15 09:39 PM
Thank you
it works now. never thought it is related
2023-08-15 09:58 PM - edited 2023-08-15 09:59 PM
Good. Please note also that calling printf from interrupt routine is not recommended, so never use it in 'production' version. It can cause serious problems since its non-reentrant.
Generally speaking interrupt handlers should be short and also non-blocking. Good practice is set some flag and handle it for example in main loop, if handling needs complicated fuctions etc
2023-08-16 12:54 PM
One thing that hasn't been mentioned, but you should be aware of, is that the EXTI being called multiple times is genuine. Most mechanical switches do "bounce" i.e. at the moment they are changing state they make and break several times. And each time the pin will change from low-to-high or back. And when the appropriate edge happens, you get an interrupt.
The duration of bouncing can depend on the type of switch, but you can expect it to last a few tens of milliseconds.
To reduce confusion, people have written "switch debouncing" routines, so that only one change event gets passed up to higher levels of software. One way is for the system to ignore changes-in-state for a longer-than-debounce-period after each recognised change-in-state. @JTP1 did this by waiting in the interrupt-service-routine for the entire duration of the printf (which I assume was sending the message down a UART or similar). But you shouldn't spend excess time in an interrupt-service-routine unless absolutely necessary because the cpu can't be doing any other work (except service a higher-priority interrupt).
So maybe your EXTI interrupt could start a timer and disable that EXTI, as well as triggering whatever you want to happen. When the timer expires (by interrupt) you re-enable the EXTI.