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 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