For pulse width measurements, you need to have a free-running counter, so you would need to use the timer counter for a reference anyway. I'm assuming there is a good reason that you would not be using the timer for the pulse width measurement, ie. it is already being used for something else. The advantage to using the timer for pulse width measurements is that it latches the contents of the counter immediately when the predetermined condition exists. The KBI can be made to latch the contents of the counter by software in the ISR, but there is a significant delay between the event and the latching of the counter since it takes the CPU time to stack the registers and begin handling the ISR. If that delay is the same when the pulse goes high as it is when the pulse goes low, then you should still have an accurate measurement - but if you have any other interrupts configured, then you can not count on the delay being the same. Suppose a timer interrupt occurs and the CPU starts stacking registers and then your KBI interrupt occurs. The CPU will first have to handle the timer ISR before going to the KBI ISR. The time the CPU spends working on the timer ISR becomes error in your measurement. Even if you enable interrupts again immediately at the beginning of the timer ISR, there is a potential error coming from the time it takes the CPU to stack the registers for the timer ISR.
Also - some KBI modules can not be made sensitive to rising edges. If the chip you are using is one of these then the best you could do is measure period and not pulse width.
I guess my question would be - why not use the input capture on the timer? Are you out of channels?
