Single Chip PWM decoders?

Hi.

I'm working on a spare-time project where I have to decode a PWM coded signal. The bit protocol looks like this:

Frequency is 500Khz, each bit starts with a raising edge.

One bits have a high duty cycle of 75%. Zero bits have a high duty cycle of 25% (with a bit of margin of cause).

Now I want to read this stream into a microcontroller or DSP. I wonder what would be the simplest way to decode this signal and split it into a clock and data-stream (so I can read it in via SPI or so).

Are there any ready made converter chips that receive PWM coded single wire protocols like the one I've just described and output something more standard like SPI or so? A built-in FIFO would also come very handy.

Best, Nils

Reply to
Nils
Loading thread data ...

Sounds like you could decode it with a PLL locking on the rising edges, and sampling your signal at the (mid point) falling edge of the recovered clock.

You also could use a 1us pulse from a mono-stable triggered on the rising edge, and sampling on the falling edge.

The first is more tolerant of frequency wandering, but requires that data always be present.

The second handles starting and stopping.

Reply to
Richard Damon

Timer Capture function of one of the pins ?

Or, RC Low Pass Filter and A/D converter input ?

boB

Reply to
boB

The problem with your scheme is the framing. Unless there's some higher level protocol on top of it that you haven't mentioned (i.e. start/stop bits) you've just got undifferentiated ones and zeros that need to be decoded in software. That's a bad match to try to translate into any kind of framed protocol like SPI.

Both ideas already posted are good starting places, but with some problems. Either the capture timer or the external one-shot will resolve your ones and zeros, but you'll need to read it every 2 us. That doesn't leave you much time to do other things unless you're running a beast of a machine.

The best thing you could do is handle the data reconstruction externally. You could do it dumb with a shift register and a counter, or smarter with a CPLD or dedicated tiny microcontroller. You're south of $2 either way. Personally I'd go the latter route; it's one more thing to program but at least you can reframe the data externally so that what you're sending to your main processor is pretty. I suppose you could use a very multicore machine instead, like a Propeller or an XMOS to do the same thing but all in one package, but I like my hardware like I like my politicians: an easily purchased commodity that can be replaced if it becomes problematic.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com 
Email address domain is currently out of order.  See above to fix.
Reply to
Rob Gaddi

One of the ARM M0 parts should be able to do this. The ST parts are the ones I'm most familiar with: the STM32F030F4P6 should be able to do this, and costs $1.45 in onsies from DigiKey, close to $0.50 in high volume.

At 500kbps the part won't be doing much _other_ than acting as a comm peripheral, but unless the framing is really perverse it should be able to demodulate the raw bits, figure out framing, then pump stuff out on an SPI port or a USART.

--
Tim Wescott 
Control system and signal processing consulting 
 Click to see the full signature
Reply to
Tim Wescott

... which then leaves you with the considerable task of handling a continous data stream of 500 kbps on the other end of that SPI or UART. That may require DMA of its own if the main CPU is to do anything useful in between telegrams --- the external converter would only relax your interrupt load by a factor of 10. 62500 UART interrupts per second don't really look all that relaxed.

Reply to
Hans-Bernhard Bröker

On Mon, 03 Mar 2014 22:21:30 +0100

an

Interrupts at 20 us are scary. Interrupts at 2 us are terrifying. But yeah, ideally you'd pipe that into some sort of IO device with a DMA engine, or at least a FIFO.

Or depending on latency requirements, the external CPLD/CM0 could be the FIFO. Check in on it every 1 ms, read out however much data has come in since the last time. Maybe even offload some checksumming, etc, tasks if you're feeling particularly adventurous.

--
Rob Gaddi, Highland Technology -- www.highlandtechnology.com 
Email address domain is currently out of order.  See above to fix.
Reply to
Rob Gaddi

I would be mighty tempted to do this with an external logic device that's pretty damned capable. I was running with the "use a microprocessor" idea because of the under $2.00, but if engineering time means anything, a CPLD or even an FPGA that's memory-mapped to a processor may be the better deal.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

Well, yes, but I'm just pursuing the OP's question, not the wisdom of his overall system design.

--
Tim Wescott 
Control system and signal processing consulting 
 Click to see the full signature
Reply to
Tim Wescott

With a modern MCU, fast interrupts don't need to be scary. If you can handle an interrupt in 500 ns for instance, then 2 us interrupts take

25% of the CPU time. The remaining 75% is still faster than a common MCU from a decade ago. If you combine this with interrupt priority levels, it may be completely transparent to the rest of the design.
Reply to
Arlet Ottens

I have figured out how I'll do it. Many thanks to the suggestions so far.

that let me generate a SPI like waveform at some output pins without using the CPU at all.

The CPU itself will then be used to calibrate the capture times to the received baud rate every N cycles.

Framing is not an issue. The protocol running on top of the bit-stream has framing and it will send enough idle-bits before and after each transfer so I don't have to worry about the SPI word-length.

I'll decode the frames later off-line. The real problem was how to get the data into a readable format that can be captured using standard peripherals.

There is also a second bitstream running on-top of the protocol in the current domain. I have to decode that as well, but this bit-stream is quite easy to capture.

For those who wonder what that protocol is all about: It is the SWP protocol that connects NFC enabled SIM cards in your mobile phone with NFC controllers chips. I want to wire-tap this signal for debugging purposes.

Thanks everyone, you pushed me into the right direction.

Best, Nils

Reply to
Nils

Don't forget that, depending on the processor, you may occasionally get pessimal interaction with the caches - which can very drastically increase the latency.

Even on a 486 processor from 20 years ago with its minimal cache, the mean:max ratio was 1:10. The situation won't have improved, but I'd be very interested in some measurements on a more modern processor.

Reply to
Tom Gardner

Yes, you should always take latencies in mind, but in a case like this, where a problem would be solved with a small CPU, there's typically no cache to worry about. And concerns about high latency Flash access can often be fixed by placing the ISR code in RAM instead.

Reply to
Arlet Ottens

It isn't clear to me whether the original problem has "clean digital" bitstream data as its input or requires extracting a digital signal from noise (either AGWN or just digital "jitter"). The latter would require significantly different algorithms and processing power, of course.

That's a case of RTFM, of course, being mindful of what you need to look for.

Possibly. That may be necessary but not sufficient. RTFM!

Reply to
Tom Gardner
2014-03-02 16:11, Nils skrev:

I think you should look into the event system which is available on many Atmel Micros including XMEGA and Cortex-M0. You can automate a lot of the functionality of the decoding by using the DMA controllers.

I have seen a customer doing low pass filtering of 21 analogue signals purely using the event system. This included controlling an external mux to allow for more than the 16 ADC channels on chip.

The events made the DMA controllers move around data, and they would also reconfigure other peripherals on the fly without CPU intervention.

Allowed the customer to meet the power consumption target.

BR Ulf Samuelsson

Reply to
Ulf Samuelsson

Thanks for sharing the idea, adding event inputs is an interesting extension to what I've done previously with DMA linked lists. Does the xmega DMA support linked lists, are multiple DMA channels used or how is the 'program' implemented ?

Of course I do not have a project for this at the moment, but now I started to wonder how much of IO can be off-loaded to DMA controllers. Might be a nasty surprise for the next guy working on the code, though!

--
Mikko OH2HVJ
Reply to
Mikko OH2HVJ

On the Cortex parts you have dual buffer, on the AVR single buffer.

They have several DMA controllers, and they use the DMA to reconfigure other DMA controllers. The programmer said is was "quite hairy" ;-)

BR Ulf Samuelsson

Reply to
Ulf Samuelsson

Someone should set up Underhanded C Contest for the embedded world.

--
Mikko OH2HVJ
Reply to
Mikko OH2HVJ

I've done that sort of thing - DMA channels which trigger new DMA channels, DMA channels that write to the "address" and "step" values for another DMA channel and then trigger it as a way of doing an addition, and other such joys. The real fun is trying to make absolutely sure that you cannot get data races when the cpu is trying to change bits that are also handled by the DMA channels :-)

Reply to
David Brown

sunnuntai, 2. maaliskuuta 2014 17.11.56 UTC+2 Nils kirjoitti:

If the transmission takes place in bursts you could just sample the bit stream with a microcontroller in a tight loop into a memory buffer, and process the stream after the transmission has ended.

Atmel's application note AVR135 provides yet another solution.

Maybe a simple analog integrator and comparator might do the trick to turn the PWM stream into 1s and 0s.

You have options :)

Br, Kalvin

Reply to
kalvin.news

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.