Re: Rabbit 2000

["patrick_o_matic" <patrick@xxxxxxxxxxxx>]

> Experience
> shows that counting pulses by using an interrupt input is an endless
source of trouble because of ill-conditioning
> of the pulses and exceptions that often happen at the start and end
of the pulse train."

Hmm, well this is a bit dis-ingenious. It's certainly true that
interrupt driven hardware is trickier to debug (and therefore
support), and that a polled solution is often more appropriate to
variable bit streams (such as i2c and serial comms). But it's all
moot, given that you have 3 pulse streams to deal with.

I think your basic progamming logic is probably right. Most likely
guess is that you need to balance the sample rate with pulse width you
are looking to detect. You need to sample such that at least 2
interrupts fall within either a low or high state for the shortest
state of the three pulses you are sampling. This should allow you to
unambiguously detect state. If your pulses are very short, look at
stretching them with your conditioning circuitry. If you are using a
555 in a monostable configuration, if the pulse is stretched too far,
you will never see any change in state at all (the monostable is
repeatedly reset by the occurence of each new pulse, so there is no
change in state on the output).

Other tricks that can help debugging:
- toggle spare output pins in your timer routine so that you can
"see"
what is happening in terms of logic execution on the scope as your
pulse is detected.
- swap the pulse generating circuitry for a signal generator, if you
have one - you know the pulse will be clean, you can control
mark-space ratio and you can experiment with really slow frequency
pulse counting which will be easier to follow on the scope

HTH a bit,
Patrick