For the Arduino, a software timer with millis() is often enough. Long story short : a timer interrupt to read buttons has a fixed impact on the software, and the fixed sample rate makes it possible to use debounce calculations. If no delays are used, the millis() function is often enough for a software timer with good responsive buttons. ![]() In the Arduino, it is often possible to avoid the use of timers and interrupts. When the code uses delays, the software timer might be delayed and the pressing the button is not always the same anymore. I'm not joking, that would really be a terrible bad design.Ī software timer can be too soft. ![]() That means that if the device would get older and the buttons get worse, the device could stop working. It can no longer be predicted what the impact of the interrupt is for the device. If the button would be connected to an interrupt, the interrupt could not be triggered (no button pressed) or the interrupt could be triggered at an extremely high rate (dirty and bouncing contacts). That is how embedded devices were designed for decades. That is a good design for an embedded system. The timer will just read the matrix and extract the pushed buttons.Ī design like that has no weird consequences for longer or shorter delays. When a keypad matrix is used, an interrupt is often not possible. Those calculations do indeed need a fixed sample rate. There are very dumb and very complex mathematical calculations to do debouncing with samples at a fixed rate. That 100Hz has a fixed influence on the system. To get that 50ms, a hardware timer of 100Hz could be used with a filter over 5 samples. That 50ms is the response time and it is a fixed time that determines how responsive the device is. ![]() Suppose a button is accepted when during 50ms the average is above or below 50%.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |