Question about PWM
cgracey
Posts: 14,209
in Propeller 2
For the triangle PWM, would it be better to grab the next value to output at the beginning of the ramp UP, or at both the UP and DOWN beginnings? I think BOTH would be preferrable, as it increases the potential feedback rate for closed-loop systems, but I wonder what you guys think about this. Thanks.
Comments
Since down-counters are cheaper than up-counters, where a comparison must be made, is it okay if the PWM has a constant OFF edge and a variable ON edge?
I would expect to see a constant leading edge and a variable trailing edge, but it takes less logic (using down-counters) to make the leading edge variable and the trailing edge fixed. What do you say?
The DIR signal is used to reset each smart pin, where 0=reset and 1=go. This way, you could configure a whole bunch of pins for, say, some common PWM frame size, and then start them all up synchronously by raising their DIR signals together. For example, we can get dual-output triangle PWM by configuring any two pins with the same frame size and then starting them together using DIR.
No problem for the simple individual PWMs. Go for it.
-Phil
It's good for differential drive with dead space.
For the sawtooth, it's fine (even preferable, I think) to use down-counting and have a constant off.
For both of these, is it going to be possible to have constant phase differences between pins ?
For example, with the sawtooth, with a 512-clock period, having 3 other pins that hit zero 128, 256, and 384 clocks relative to the first one. With the triangle, again with a 512-clock period, could you have 3 other pins that started up-counting 128, 256, and 384 clocks after the first one ?
I can do this with the P1 (relative to the system counter), although it takes a dedicated cog for every 2 pins.
Just raise their DIRs at the desired initial offsets and they will stay that way.
Update once per period would mean the relative slice points stay in phase, whilst update twice means the Rise and Fall edges can skew, briefly.
I think users would prefer a system with just two values, the old and new, not a 3rd value in the mix as well.
How many capture/compare channels are there per counter ?
If there are two, there is a case for update of both compare set points on the same single period edge.
(ie there may be an aditional delay on the first-loaded value, before they both update.
What about the handling of timing of update of the compare set-points of multiple phases of counter ?
The Pin can flip polarity, so this is tolerable.
Can this map to more than just Ctr Reset ? (related to Q above)
ie be used as an ARM or GO signal, applied to capture or compare registers.
In use, that would allow queued Compare writes to as many channels as the user wanted, and then the ARM_GO updates all those values on the next (common) period end.
For Capture, the same signal would be ARM for (one shot) capture on the next-edge of multiple channels.
Reciprocal counters need such paired captures, where the next Fin edge captures both Time and Cycles.
Sync-updates need to apply on the same clock edge, across multiple pin-cells.
What Chip mentioned above around Reset-Start is great, as that can same-clock signal to many pin cells (up to 32?) but it needs to be able to mux-out to more than just RST.
Typically for PWM you would hold counters in reset, load compares, and then release reset once, but need to update all the compares on the same edge. A simple MUX scheme would support that.
For counters, you could start counters from 0, and then arm many captures for the net trigger event, then read the results, and arm again.
Capture of Duty and Period needs 2 registers - I'm unclear if one counter has 2 captures, or if two counters running in sync are needed.
Guess that depends on if the Pin cell is per-pin, or per pair-of-pins.
I can see one context where the streamer could couple nicely with Smart pins, and that is as a high speed Event capture.
Consider a time-stamp logic anaylzer - instead of some fixed sample rate, this captures a Bit-pattern and a time-stamp, which gives them natural compression and very wide dynamic range.
As in the above Frequency Counter use case, this needs two captures from the same event edge, one from Pins, and one from a timebase counter.
The streamer would transfer 2 (16b or 32b?) capture values, and wait for the next event.
(ie Streamer here clocks twice per external event, not at a fixed rate)
Highest allowable edge rate is set by possible pin filtering, and the streamer ability, but down to 2 SysCLKS spacing on events looks doable. Any edge has a 1 SysCLK resolution.
Most other smart pin uses like PWM or Capture or Frequency Counting, or UARTS etc have far more modest update rates, but they could use the sync-many feature discussed above.
Here is an example ... you have two inputs that could be quadrature, but for the sake of the example lets say that they are not quadrature, but at the same time you want to detect the precise lead or lag between the two pins, ... ok, so a simple complementary nor gate configuration can determine what leads or lags, and here is where the PWM comes in ... by XORing the two inputs you can detect the amount of error or difference in lead or lag by way of a PWM from the output of the XOR. If you "gate" this operation with a processor clock you get unwanted propagation delays from the clock cycle that degrade the dynamic quality and sensitivity of the circuit.
The Video I have here uses a very similar circuit to the one below with a classic Wheatstone derivative. Although the video suggests a metal detector approach, the principle can be applied towards MANY other sensor arrangements as well as signal comparisons. ... just to give an idea, the sensor used in the video is a chip inductor that measures 1mm x 1mm x 2mm in it's physical size. The amount of inductive deflection by an external metal or magnet source is less than 10% of the inductors value.
Are you asking here for another pin-mode ? - Along the lines of an ASYNC XOR, or a Configurable Logic (simple gates/FF) as found in Microchip and SiLabs MCUs ?
I think Async Invert (for Pin oscillators) is there already, but a Async XOR could certainly be useful.
I have seen clever things done with P1 Counter PLLs (missing on P2) and they allowed Async signal generation, and even phase sweep by deliberately wobbling the reference so lock was never settled.
This allowed external XOR approach, and by measuring over a large number of samples. and assuming the clocks were never locked, you can calculate the fractional times, down to sub ns.
Down count triangle PWM is very, very, good. Triangle with the individual deadtimes is better tho.
Most power pwm is higher voltage anyway. there are many I and H bridge drivers with built in deadtime.