1. Home
  2. Embedded Programming
  3. Continuous Pulse-Width Measurement

Continuous Pulse-Width Measurement

Hi,

I'm wondering if anyone knows of a microcontroller or some cheap hardware in combination with a micro that can be used to continuously measure and buffer all of the high and low pulse-widths of a binary signal. I'd like to be able to buffer about 1000 16-bit width measurements in one shot.

The catch is that the smallest pulse width measurable needs to be 700ns or better (500ns would be nice). I've looked at using an input capture pin to a 20MHz or faster auto-cleared timer in combination with a DMA controller to transfer the captured pulse-widths to RAM, but all the transfer cycles generally add up to well over 1 micro-second. The 20MHz timer gives sufficient resolution, but the time to buffer the data is too long.

Right now, the company I work for accomplishes this exact feat using an ASIC. Together, the current ASIC and micro cost about $7. Can the same be done for less money, and possibly with a single chip?

I appreciate anyone's suggestions on this problem.

Thanks!

Reply to
jawereq
Loading thread data ...

Measured to what accuracy? Is it enough to distinguish 700 ns from zero, ie no pulse at all (most of the time), or do you have to know whether it was 700 or 700.5 ns? What about a maximum pulse length? What's the minimum pause between pulses?

I rather much doubt that anything looking like a CPU will get you there. I guess a bit of analog electronic would get this job done faster (think time-to-analog conversion, comparators, sample-and-hold).

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Reply to
Hans-Bernhard Broeker

I would guess that this application would be simple with a smallish FPGA. You will be paying more, especially if you cannot be done with the micro. Does the micro communicate with the outside? You can put async serial in FPGA, but the effort nay not be worth it. What does the micro do?

[...]
Reply to
Bryan Hackney

How much resolution do you need and how long of a period do you need to capture over? How many bits? If 500ns of resolution is sufficient and you have the RAM space, you might just do a CPU copy into RAM space and then do the measurements as a postprocessing step looking through RAM for transitions. For single bit monitoring, an 8 bit shift register that is clocked from an accurate source would give you either 8x the resolution or 1/8 the storage space. Read the parallel outputs of the shift register and copy them to RAM. Do the measurements as a software postprocessing step. Obvously this approach will only work if you have enough free RAM and don't need continuous operation.

Bob

Reply to
MetalHead

If the total cycle time (ton + toff) can be guaranteed to be at least some microseconds or longer you might be able to do it by using two counter-timer modules in some micros, but otherwise I think you're looking at programmable logic of some kind.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
Reply to
Spehro Pefhany

schreef in bericht news:Xns9641C69191956chickentonight@130.81.64.196...

to

be

16-bit width, 20MHz timer, that suggests the pulses are between 500ns and 3ms. Is Ton + Toff constant? What are you going to do with those 1000 measurements? Maybe there is an entirely different approach to this problem, one that does not require storing 1000 measurements.

Ubicom's IP2022 is extremely fast (120 mips), IP3023 twice as fast, and both have enough ram to store your 1000 samples.

--
Thanks, Frank.
(remove 'q' and 'invalid' when replying by email)
Reply to
Frank Bemelman

You don't state the resolution, or refresh rate, which makes an answer difficult. You infer from the mention of 20Mhz and 1us that 50ns resolution is OK, and that 1us refresh is not ?

Volumes ? Present uC brand/code size ?

Single chip support for timing is going through something of a improve-cycle right now.

ie core speeds have hit a plateau, but the designers have finally realised that the silicon can go (much) faster on peripherals, and so now there are PWM generates with 64/96/200MHz clock speeds - and some of these will also offer capture.

recent examples are SiLabs Si8250, and Freescale 56F8013

A small FPGA will certainly do this - speed will not be an issue at all, main selection criteria will be Idle Icc, and RAM to store the capture values.

You will not have to make any (or minimal) uC-Sw changes on this path.

-jg

Reply to
Jim Granville

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.