Multiple Pulsin Measurements

[FinchPJ]

I need to make 8 simultaneous (relatively) measurements of pulsewidth on 8 different input pins - is there a PIC that could handle this with timers or interrrupts?

[cncmachineguy]

Can we get just a little more info about the pulses? for instance are you trying for a Logic storage type thing or reading R/C Rx pulses. Both need to have 8 bits read, but the Logic storage needs to get the states and go back watching while the Rx has at least 2mS before the next pulses may show up. Do you have an anticipated max/min pulse width?

[cncmachineguy]

Also can you expand on the first was "slow"? Do you mean it was to slow to react to the pulses? were they accurate but offset? How much percision and resolution do you need?

[FinchPJ]

OK - the scenario is measuring multiple (8) pulses arising from eight simple 12F675 circuits outputing pulses - I can change that to whatever I want, currently 1mSec pulse every 50 mSec, but the 12F675 has an LC circuit driving its oscillator so the pulse width is altered by the LC circuit (and any adjacent metal/tuned circuit etc.

When I say the Picbasic routine was slow I mean the precision or resolution - using PB PULSIN gives a resolution of 40/OSC uSec - ie. 0.833 uSec at 48 MHz - so a 1000 uSec pulse gives a Pulsin answer of around 1224 - using my PicBasic routine I get a measurement (ie number if cycles of sampling) of only around 300 (ie 3 uSec resolution) and using assembler a similar result, unless I only sample one bit in which case it rises to arounf 800 (ie 1.1 uSec resolution). So a PULSIN resolution of 40/OSC is pretty impressive!

Interestingly, a sequence of several PULSIN commands on each successive pin gives a much better (more precise) result - maybe I should never have started this idea and stuck to dirty successive PULSINs!

[cncmachineguy]

Sorry to be dense but here goes -
so for a 1000 uS pulse you get as a result-
1224 for pulsin
1300 for your routine
1100 for just 1 bit sampled?

You can see I don't think I have this right. If I do, they are all crap IMHO. best being off by 10%!

I am crafting up a possible solution, but these numbers are messing with me.

On to more fun stuff. So you have around 50 mS to wait for the next series of pulses correct? If so, what about this:
when the first pulse starts (or all of them at once, whatever) start a timer.
XOR the 8 bits (faster if they are all on the same port)
keep checking until one of more change.
when they do, grab the counter value and store it with the port value.
When you have done this 8 times, you will have the counter differences for each bit.

Now go process the information to determine how long each pulse lasted. Plenty of time left to get back and wait for the next series of 8 pulses. Now if you wanted to use interrupts, have all 8 on IOC pins, then when the ISR fires, grab the counter and states there. This will take a feww cycles longer though.

[FinchPJ]

Thanks for your advice - I will think about your "Fun stuff" - actually the actual timings/test results are the opposite of what you understood from my description:
so for a 1000 uS pulse you get as a result-
1224 for pulsin - correct (=~ 1000*48/40)
1300 for your routine - No I get an answer of around 300
1100 for just 1 bit sampled? - No I get an answer of around 800

Whilst using interrrupts etc as you suggest may be a purist answer, I think 8 successive PULSINs are going to be much easier - I cant guarantee the pulses will arrive synchronously, but it is the precision I am worried about, not the sample time it takes (hence the 50 mSec pause between pulses)

[cncmachineguy]

I dont know about the "purist" part, and IMHO anything needing better then 5uS accuracy is not well suited for interrupts.
Now I understand your numbers, 300 is really 300 iterations of the loop. so its as accurate as the loop takes (given 1000uS pulse, 3.333uS loop time)

I propose you can achieve 1uS with my suggestion, maybe better. But if you can get the XOR to be 2-3 instructions, 2 jumps = 4more (to the grab time and back), then a couple of instructions to save the timer count and port states. You will be right around 12 instructions I think. So not much better then the pulsein, but nicer in the respect you can get all 8 at once.

I am assuming you are using this to check the speed of the 8 uP's. something else to consider :
If they are sending the pulses every 50 mS, you could measure the low pluse (50mS long) instead of the high pulse. This will give you a much bigger window to check the the duration against. 1% is 500 uS in this case. so being off by 3 or 4 uS would then be peanuts.

[FinchPJ]

Thanks so much for your helpful thoughts - I will go away and work at your suggestion - I agree interrupts may not be accurate enough - you are quite correct I am monitoring the 8 baby PICs' oscillator speeds and I agree a longer pulse is easier (more accurate) to measure.
Peter