Use case: A trigger pulse for a Triac driving an AC load. Imagine a zero crossing detector on an input and using that to derive your pulse timing to have the triac produce the truncated sine wave each half cycle for AC light, heater, or motor power control.
Since we don't have interrupts, we can't start a timer to generate a delayed pulse asynchronously as is the usual method for this in C. But if your AC is a relatively constant frequency as most power sources are, measuring that and setting up PWM to generate the triac gate pulses should work, so long as you stay in sync. But you can't afford to run that for very long as unsynchronized timers will drift out of phase. AC power is usually 50-60Hz so the PWM cycle start timing control is desirable to at least 100us accuracy. The half waveform needing sliced up being just over 8ms.
Feature request:
-
The ability to control exactly when a PWMOut instance starts counting. This is unspecified in the docs today. So while I might assume PWMOut construction starts the timer, that doesn't appear documented so it'd be a bad assumption to make as under the hood timers on microcontrollers are often a scarce shared resource. If I assign a new value to duty_cycle, does that reset the timing or is it still based on some unknown base time? Or is this platform implementation dependent?
-
The ability to tweak the PWM counter reset offset on the fly to adjust the PWM chain on to a new reference sample.
-
At a higher level than the above... The ability to generate triac gate pulses based off of a zero crossing input. If a PWMOut like interface had the ability to auto-resynchronize to an adjustable phase offset based on an edge from a Pin, that sounds like an ideal Triac gate control. Imagine something high level like:
class TriacGatePulseOut:
def __init__(self, gate_output: Pin, zero_crossing_trigger_input: Pin,
pulse_duration_us: int = 4, *, starting_duty_cycle: int = 0):Hacks that might be possible today:
- The
variable_frequency option exists. Being able to tweak that to shift one way or the other sounds like a dangerous way to compound errors if done wrong. You might need to monitor your own output on another input to understand the exact generated pulse time vs your goal. A phase micromanagement loop like this is undesirable. I've got sensors and other outputs to manage in the foreground.
- Regularly
deinit() the PWMOut and construct a new one often enough, probably a couple of times a second, to head off timing drift. Possibly taking long enough that I miss a half cycle and lose some output. This could lead to flickering lights or an oddly pulsing motor.
Otherwise, give up and use C seems like today's best answer.
Use case: A trigger pulse for a Triac driving an AC load. Imagine a zero crossing detector on an input and using that to derive your pulse timing to have the triac produce the truncated sine wave each half cycle for AC light, heater, or motor power control.
Since we don't have interrupts, we can't start a timer to generate a delayed pulse asynchronously as is the usual method for this in C. But if your AC is a relatively constant frequency as most power sources are, measuring that and setting up PWM to generate the triac gate pulses should work, so long as you stay in sync. But you can't afford to run that for very long as unsynchronized timers will drift out of phase. AC power is usually 50-60Hz so the PWM cycle start timing control is desirable to at least 100us accuracy. The half waveform needing sliced up being just over 8ms.
Feature request:
The ability to control exactly when a
PWMOutinstance starts counting. This is unspecified in the docs today. So while I might assume PWMOut construction starts the timer, that doesn't appear documented so it'd be a bad assumption to make as under the hood timers on microcontrollers are often a scarce shared resource. If I assign a new value to duty_cycle, does that reset the timing or is it still based on some unknown base time? Or is this platform implementation dependent?The ability to tweak the PWM counter reset offset on the fly to adjust the PWM chain on to a new reference sample.
At a higher level than the above... The ability to generate triac gate pulses based off of a zero crossing input. If a
PWMOutlike interface had the ability to auto-resynchronize to an adjustable phase offset based on an edge from aPin, that sounds like an ideal Triac gate control. Imagine something high level like:Hacks that might be possible today:
variable_frequencyoption exists. Being able to tweak that to shift one way or the other sounds like a dangerous way to compound errors if done wrong. You might need to monitor your own output on another input to understand the exact generated pulse time vs your goal. A phase micromanagement loop like this is undesirable. I've got sensors and other outputs to manage in the foreground.deinit()the PWMOut and construct a new one often enough, probably a couple of times a second, to head off timing drift. Possibly taking long enough that I miss a half cycle and lose some output. This could lead to flickering lights or an oddly pulsing motor.Otherwise, give up and use C seems like today's best answer.