Looking at the code at 0:32 I see a possible issue with this code. If an interrupt occurs, line 19 is executed and shouldMoveMotor is set to true with the intent to move the motor. The loop() function then executes line 12 and enters the if statement but hasn't yet executed line 13 yet. Now another interrupt occurs with the intent top move the motor again. However, now line 13 executes and sets shouldMoveMotor to false and effectively erases the request to move the motor a second time. Instead line 14 is executed to moveMotor() only once.
Good observation, though in practice, you will not get 2 interrupts that fast. Nobody that press the button twice in less than a few microseconds (then there is the debounce issue, which you can fix in the code)
@@RoboticsBackEnd A solution is to use a queue but you're right this event would happen rarely and heck we're not controlling realtime car functions like anti-lock breaks.
good explanation and points
Great video mate 👍
thanks
please provide captions as the audio is not clear. Captions help alot at 2x playing speed.
Looking at the code at 0:32 I see a possible issue with this code. If an interrupt occurs, line 19 is executed and shouldMoveMotor is set to true with the intent to move the motor. The loop() function then executes line 12 and enters the if statement but hasn't yet executed line 13 yet. Now another interrupt occurs with the intent top move the motor again. However, now line 13 executes and sets shouldMoveMotor to false and effectively erases the request to move the motor a second time. Instead line 14 is executed to moveMotor() only once.
Good observation, though in practice, you will not get 2 interrupts that fast. Nobody that press the button twice in less than a few microseconds (then there is the debounce issue, which you can fix in the code)
@@RoboticsBackEnd A solution is to use a queue but you're right this event would happen rarely and heck we're not controlling realtime car functions like anti-lock breaks.