Strange PWM behavior on wake? #926
-
|
I have a thing that I'm making go into shutdown mode with a pair of buttons, setting an interrupt on each of the buttons, and bringing it active with those interrupts (pinMode input_pullup, interrupt on falling, using attachInterrupt, Old Version). Part of the wakeup code is to reset LED brightness (PWM) to minimum, regardless of entry conditions. Conditions of failure are having the device at high (more than 50%) brightness, before shutdown. If PWM is less than that, I can't seem to catch the failure. If I set PWM to "0" (directly) in the shutdown code, then when the device wakes up, there is a ~40% chance of the LED blinking BRIGHT for a tiny fraction of a second (one loop, I'm guessing?), before dropping to minimum brightness. If I set PWM to "1", and THEN "0", before shutdown sequence, when it wakes up, there is no blink. I have tried setting PWM to "0" in the wakeup process, and that doesn't do anything to help. It has to go to "1" before shutdown, or it can blink. I can only guess that this is an initialization issue in the PWM handling. I don't think it's due to the interrupt method that I'm using, but I guess it could be. Is there any combination of options I can use to prevent this little glitch, or should I just keep using my workaround? |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments
-
|
That's happening because the duty cycle is gettting set after the compare match for the new setting would have occurred, this produces a glitch lasting the duration of one pwm cycle. This is a problem with the split mode of the TCA, since it doesn't support buffering, which is the mechanism used to ensure that changing the duty cycle can never cause a glitch. This was one of the reasons that I implemented the (as yet untested) PWM pin selection tools subvmenu (another was that the tinies were jealous of DxCore's runtime portmux switching...), which lets you choose between a number of relevant pin mappings, for both the TCA and (on 1-series) the TCD. These pin mappins include 3-pin options, and the 3-pin options do not enable split mode and should use buffered writes and avoid that sort of glitch. It's currently in the github version, but not in any release, and I've been hoping someone would try to use it and give me some feedback on it, since I have not verified that it works at all |
Beta Was this translation helpful? Give feedback.
-
|
Mmmm , okay, now what's it github has a prayer of working.... |
Beta Was this translation helpful? Give feedback.
-
|
Alright, thank you. I will give that a shot, later, once I work the kinks out of the rest of my code. For now, the workaround is holding, and I'm struggling with interrupts. |
Beta Was this translation helpful? Give feedback.
That's happening because the duty cycle is gettting set after the compare match for the new setting would have occurred, this produces a glitch lasting the duration of one pwm cycle.
This is a problem with the split mode of the TCA, since it doesn't support buffering, which is the mechanism used to ensure that changing the duty cycle can never cause a glitch. This was one of the reasons that I implemented the (as yet untested) PWM pin selection tools subvmenu (another was that the tinies were jealous of DxCore's runtime portmux switching...), which lets you choose between a number of relevant pin mappings, for both the TCA and (on 1-series) the TCD. These pin mappins include 3-pin options…