Hi speed input capture

Hi,

Situation:i have 32 input lines from 32 different rotating devices each operating at a speed of 15,000 rpm. Each input line have an equal priority. I need to keep a track of number of revolution and pass this info to PC.

If power is gone then i need to store current count of each input line to some persistent memory location in a fraction of second.

Problem:

  1. I am not able to understand which microcontroller (avr, 8051 or some other) to use (i know 8051 better).
  2. No microcontroller has 32 internal counter to keep track of it.
  3. Will i be able keep track of 32 devices at a time.

My Thoughts:

  1. To use Master/slave architecture.
  2. To use 8 bit hardware counter and maintain another 8 bit counter as software counter. Hence i will be having a complete 16 bit counter. When ever a h/w counter completes, s/w counter will be incremented by one.
  3. Use Atmel 8051RD2 for my colege project as its development board is easily available.

Please advice.

--------------------------------------- Posted through

formatting link

Reply to
sarcasticami
Loading thread data ...

This sounds like an ideal application for an FPGA.

:-)

Nial.

Reply to
Nial Stewart

each

It should be possible of a low cost microcontroller to detect these. With 15K RPM that corresponds to 250 revs per second. If you were to be getting one pulse from each motor per rev you could clock each pulse into an edge clocked flipflop that could then be cleared by the MCU code. Setup a timer interrupt in the MCU at say 1msec period (1000 Hz) and have that trigger a periodic poll of the flip-flop inputs via some port pins. After the poll cycle is complete have the code clear all the flops at once. This will somewhat limit the resolution with which you can compute the RPM of the motors but may be just good enough. Depending upon the horsepower of the MCU you select in terms of raw compute bandwidth one MCU can probably handle 8, 16 or all 32 inputs.

If the pulses from the motor are wide enough (say at least four sample periods) then you could actually eliminate the flip-flops and do the pulse edge detection in software. There are ways to so byte wide arithmetic using AND, OR and XOR type instructions to support the pulse detection on inputs up to 8 at a time. Even counters for each channel can be implemented as bit serial things across a series of stored bytes. Sometimes these are referred to as vertical counters where a series of bytes represents 8 counters, one in bit 0, one in bit 1 etc. A lot of work can be done with surprisingly little instruction bandwidth.

Long ago I made an MCU setup that was able to track the status of 28 phone lines detecting hook status and ringing cadence (~~20 t0 25 Hz signalling) using 80's technology with an MCU clocked at 6MHz. Using todays MCUs with clocking at 50 or even 100MHz it should be possible to do this without a lot of extra logic and without a need use many MCUs.

On the other hand if it is necessary to note the difference between

14,999 RPM and 15,000 RPM then you will need to use separate counter hardware per motor that has a clocking resolution to note tachometer pulse changes that correspond to these rates. You always also need to make the decision if you compute the RPM by pulses per unit time or by measuring time from pulse to pulse. Often when measuring RPM over a large range is is necessary to use both modes and switch from one to the other at a certain threshold. As I've indicated if the RPM resolution is critical to your design then you may have to find allocate motors at 2, 3, 4 or 5 per MCU depending upon on how many timers you have per MCU.

You could also consider looking at the Coldfire family parts that have the on-board TPU. Certain parts can clock up to 80MHz and the TPU can process timing measurements on up to 16 parallel channels at a time. You could maybe do everything for 32 motors using two MCUs. If your product had some modularity of say 16 versus 32 motor monitor channels you could maybe even put one Coldfire per board and have some configurability to the product and offer several cost level offerings.

--
Michael Karas
Carousel Design Solutions
http://www.carousel-design.com
Reply to
Michael Karas

The 15000rpm is only 250 pulses per second. This is not much; a microcontroller could process 32 inputs with that kind of speed in the software without any problems.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

formatting link

Reply to
Vladimir Vassilevsky

If I understood the question correctly, you are actually doing more than required. I read it as just counting 32 inputs @ 250Hz, which should not be a problem for almost any availably mcu, provided it has enough inputs.

Why you would want to count 15000 rpm with only a 16 bit counter and even store the result over power cycles was not made clear in the question. Should revolutions from a still spinning motor after power loss also be counted?

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

This dungeon is owned and operated by Frobozz Magic Co., Ltd.
Reply to
Stef

Seems like a perfect job for a GA144 (

formatting link
). It is a chip with 144 small processors, very energy aware. Each input can be treated separately by a processor, so the programming would become trivial. Then you've some hundred processors left to do communication. With 700MIPS per node, they should handle 15 Khz no problem.

This is a static chip: no work, no power drain. After handling an input a processor would go to sleep for thousands of nanoseconds automatically.

Too bad this chip is still not commercially available. If this is a college project, you could get a pre-production sample. Experience gained would be "off the Richter scale" compared to yet another boring 8051 project. (OK, doing this with 8051's is a challenge.)

Groetjes Albert

--

--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
Reply to
Albert van der Horst

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.