I'd go for an Atmel AVR @ 20MHz.
	You can do 80 instructions in 4uS.

	Mark Jordan


On 16 Jan 2008 at 15:13, M. Adam Davis wrote:

> I think you're looking at if from the wrong perspective, your program
> doesn't have to run entirely within a 4uS time slot.  It can run in
> the background - only the capture routine needs to run that fast.
> 
> Still, it's a difficult problem.
> 
> I'd go with interrupt on change (be aware of all the interrupt on
> change problems that occur).  Then you'd only be interrupted 8 times
> every 30mS, which is plenty of time to do other stuff, and you aren't
> tying up the processer doing polling, watching a timer, etc.
> 
> Set up a timer to free run at the resolution you need.
> 
> When the interrupt is triggered for a change on any of the four I/O
> then capture the current state of all four I/O (ignore which one cause
> the interrupt), capture the timer value, and then set a flag so the
> main routine knows a new capture is available.  I suspect this
> interrupt would only need 5-10 instructions on the outside, so it's
> not going to consume any significant time.
> 
> The main routine processes that information, probably uses a state
> machine for each input so you know what you're waiting for next for
> each one, and maintains a counter to account for timer roll over
> (which should also be monitored in the main routine, and perhaps as an
> interrupt if the main loop can't poll it fast enough)
> 
> Since you're capturing all the input state on each interrupt you'll
> avoid having to worry about whether they trigger too close together.
> If you're still worried, then capture the state of the inputs at the
> very end of the interrupt routine - the last thing before returning
> from interrupt.
> 
> This should work just fine, and give you tons of processing power.  If
> you're worried about the interrupt on change not functioning properly,
> there are some other interrupt triggering options (using the real int
> pin and a series of xor gates, etc) but I'd be surprised if you needed
> that.
> 
> But if that doesn't suit you, you can get very cheap chips with two
> ccp modules, and use two, one as a slave, to get the pulse width for
> all four signals with no sweat.
> 
> -Adam
> 
> 
> On 1/16/08, Martin <martin@nnytech.net> wrote:
> > Imagine that you want to measure 4 "RC" PWM signals, standard being
> > about 1mS to 2mS at 50 Hz (IIRC)
> > You want 8 bit accuracy so that leaves you with 1mS/256 = 4uS resolution.
> > There are a few schemes I can think of to achieve this, but I don't
> > think any are particularly good:
> >
> > 1. Polling - have a running timer and poll input pins. Resolution will
> > suffer so you will probably have to average several measurements to
> > (hopefully) get a good result. You won't really be able to do anything
> > else with your PIC.
> > 2. Interrupt on change - your interrupt code runs and checks the pins
> > when one changes. Chaos results when pins change within uS of each other
> > and the interrupt code is still executing.
> > 3. Capture - probably the correct way to do this (pin interrupt stops
> > timer). The problem is that I can't imagine there being a chip with 4
> > such CCP inputs
> >
> > How would you do it without a lot of external logic?
> >
> > De-mux into a capture pin maybe?
> > I'd lose f/n resolution: 50/4 = 12.5 samples per second, maybe that's
> > good enough. Then I'd want to add edge triggering to ensure that I don't
> > capture half-pulses, meaning more external logic.
> > -
> > Martin
> > --
> > http://www.piclist.com PIC/SX FAQ & list archive
> > View/change your membership options at
> > http://mailman.mit.edu/mailman/listinfo/piclist
> >
> 
> 
> -- 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> - - - - - - - - - - - - - - - - - - - - - - - - -
> Moving in southeast Michigan? Buy my house: http://ubasics.com/house/
> 
> Interested in electronics? Check out the projects at http://ubasics.com
> 
> Building your own house? Check out http://ubasics.com/home/
> -- 
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist


-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist