Tips for to "de-pwm" a signal?

[grandaspanna]

Wasn't quite sure how to phrase this question so my webs searching hasn't been very fruitful.

I'm looking for an efficient way to ignore any PWM component of a signal and determine if it's "on" or "off" (ie: if duty cycle >0, it's on). PWM frequency could potentially vary from 1kHz to 8kHz - it's coming from an external source that will be unknown at design time.

I have an inkling that the CCL could likely help here, maybe combined with a one-shot set to a fraction longer than the frequency?

My work-in-progress project is using a DA32 and one B timer alongside LUT0 and TRUTH0 to handle the rest of the flow.

Wondering if there's a standard approach for doing this. If there's some terminology I'm missing, I'm happy to keep searching.

FWIW, I need relatively small latency (1 uS or better) for the off->on transition, the off->on transition is less important.

[SpenceKonde]

Take the signal to an event input, and set an unused TCB (TCB2 is used for millis by default).
I think you want Timeout Check mode, configured to fire if there is more that a given period of time between when it is called and the rising edge of the input.

TCBn.CTRLB = TCB_CNTMODE_TIMEOUT_gc; //timeout check mode
TCBn.CTRLA = TCB_CLKSEL_DIV1_gc; // divide CLK_PER by 1
TCBn.EVCTRL = TCB_EDGE_bm |TCB_CAPTEI_bm; //enable event input on falling edge.
TCBn.CCMP = //timeout in system clocks.

[grandaspanna]

Thanks for this - this looks useful.

I get a logic high after the signal stops, so if I feed that into an LUT configured as an S-R latch (as per "tips and tricks", I'm thinking that should give me a clean view of start with a one PWM cycle lag on stop.

Gotta wrap my head around the routing of the events and the truth table, but is this halfway plausible?

Next step will be to bust out my dev board and 'scope :-)

[SpenceKonde]

It is not clear exactly what the signal you are monitoring looks like, and what the precise constraints you;re working within are,. it's difficult for me to comment further.

[grandaspanna]

That's completely fair. I can't expect anyone to solve this for me, but grateful for suggestions.

The original source of signal is the output of a h-bridge motor driver (this is an external component that I have no control over). Using the analog comparator, I clean that up and get a decent view of the transition to "on" and currently feeding that into an LUT which works well if the duty cycle is 100%. This piece is to make it more robust when the PWM is at work. For my purposes, anything from >0% duty cycle is "on".

Perhaps I can solve this with smarter configuration of the truth table, but I have a habit of thinking in stages.

Are there any tools for visualising CCL inputs/outputs?

[SpenceKonde]

I use the techniques of our proud ancestors: Scratching marks onto pressed, bleached vegetable fibers using a graphite rod.

I know pencil and paper is kind of old fashioned, but that's all I've ever used. I've almost always had to write out the truth tables though.

That said, I'm not sure there is way to do that without a timer, for the simple reason that you cannot tell whether the PWM has stopped, until the next pulse would be coming.... and it doesnt appear. at 1 kHz PWM, the only way you will know whether there is or is not PWM worst case (low duty cycle is by observing the pins has not changed during that time. That's a 1000 us delay.

But this is literally exactly wheat timeout check mode is for, though. If you need the other edge - I don;t know ifr the EDGE bit works right (there has been some thrash regarding the function of that pin), but inverting the pin will definitely work,.

[SpenceKonde]

You could then have two interrupts, the TCB0 interrupt which would turn off it;s interrupt, and turn on the port interrupt, (or falling iver you had to invert it to make it work) The port interrupt will take an eon to reach your codeif you do it via attach interrupt, so dont use attach interrupt. manually declare the ISR and assume responsibility for setting the ISC bits in to enable/disable it./

I think youd have the timeout check interrupt disable itself, and clear the port intflags and enable the interrupt on the port pin (the same one you're piping to the time, which the port interrupt would the opposite, so you'd get a port interrupt to start the timeout check when the PWM first turned on, then when it turned off, the TCB interrupt would fire asfter no pulses for a while

[mosqu-ito]

A missing pulse detector can be pretty easy to implement in hardware. Use a pnp transistor on your active low pulse to shunt out a little capacitor that otherwise floats up to Vdd on a pullup. But if you want to avoid external hardware, let's see..

Can you count on the signal being less than 100% duty cycle?
(Or to put it differently, will there always be edges if the duty cycle is >0%?)
Is the signal nice and clean?
(Nice and square with no spurious edges?)
(And failing that, can we put a pin in that and worry about cleaning it up separately?)

In that case, I might be inclined to trigger an interrupt on every negative edge (it's active low, right?) which, at a minimum, records the time, for instance "LastNegativeEdgeTime". While recording the time of the negative edge you can also immediately assume that the duty cycle is not 0%, maybe check a flag to see if you're already doing whatever is required there, and if not, do it. For the less time-critical (stand down?) event, you could simply look, at any convenient time, perhaps even just in the main service loop (and after consulting a flag to see if it even was running previously) at how long it's been since the last negative edge and decide when you think it's been long enough to declare things "off" and take whatever action that entails.

I've filled in some blanks with my imagination here so please set me straight where required.

[grandaspanna]

The original signal is kinda messy, so I'm currently using an analog comparator to clean it up a bit and that seems to be working ok. The overall intent of what I'm thinking is (I'm hoping) shown here:

Output of the AC is the top signal and my post de-pwm ideal is the bottom one. The period of the PWM signal is denoted as P.
The time from "A" to "B" should be as small as possible (less than 1uS if possible), since it's that rising edge that I'm interested in. The time from "C" to "D" is less important and using the TCB timeout, a delay of slightly longer than P should be fine.
I'm caught in some paper musings at the moment of combining the event system and CCL, but been time poor to try any code yet.
Ref this:

The idea is to use a RS latch, have it set with the first rising edge from the AC and then reset by the TCB. The documentation says that W0 can feed the LUT, but it doesn't look like the timeout mode on TCB triggers W0, so maybe I have to go via an event? I then channel the output of the latch into another CCL arrangement to do more work. On the DA32, I've got enough peripherals to do what I want (I think).

[mosqu-ito]

Are you wanting an all-peripheral no-runtime-code solution? Is that why you're trying to do it with LUTs, Events, and Timers? There is of course no magic way to know that you're at time D without waiting to see if there's going to be another pulse. So isn't the speedy bit really just about catching the first edge of the train? If there's code that needs running then, an interrupt on that edge seems like the place to put it. What am I missing?

[grandaspanna]

To start off with, an all-peripheral solution will hopefully give me more deterministic results. The overhead of interrupts etc and my less than optimal code-writing skills could be an issue. I'm hoping to keep sub 1uS precision. The delay at the end of the train is acceptable, and if "E" follows "D" by an amount that's PWM period-ish, then I think that's fine. Using TCB in timeout mode seems like a plausible way to do that.

Of course, it may be that my downstream logic could be fixed, but currently is getting confused by the multiple leading edges of the PWM signal. This is one of three states that feeds into the final LUT (not shown in the picture).

Work has been super busy - I'm hoping that I can bust out the dev board and 'scope and start experimenting soon.