Comment by userbinator

Comment by userbinator a day ago

3 replies

Of course, the project didn’t allow us to use an RTOS.

That tends to just make the project eventually implement an approximation of one... as what appears to have happened here.

How I'd solve the given problem is by using the PWM peripheral (or timer interrupts if no PWM peripheral exists) and pin change interrupts, with the CPU halted nearly 100% of the time. I suspect that approach is even simpler than what's shown here.

kevin_thibedeau 17 hours ago

You should not use interrupts for button inputs. You will just end up hammering the processor with useless interrupts when the switch bounces. Human interfaces can be polled and still maintain responsiveness. If polling isn't fast enough for machine actuated IO or you need to stay in a low power state then interrupts could be considered but you really need a non-naive solution that disables the interrupt from within the handler for a specified timeout duration.

  • apple1417 13 hours ago

    I've worked on several low power projects, while yes we needed an interrupt to wake the processor, they all still used polling for all the actual button handling. At worst the interrupt just set a flag. It's actually kind of amazing how polling turns the main loop into a denounce filter, entirely for free.

  • userbinator 10 hours ago

    I haven't had problems with that in my designs, debouncing is done in hardware.