Jinx wrote:
>Analysing and comparing an IR data stream need not be
>memory intensive, but given your need to scan for keys
>and serial activity it could get processor intensive at times
>
>I think the first thing you'll need to do is prioritise - eg which
>event is slowest or repeatable and which is a must do
>
>Without knowing any details of your system, IR would seem
>to be the highest priority as pulses tend to be faster, in the
>order of a few microseconds, than "common" serial (eg 9600
>baud is around 100us bit period) data or key presses (100s
>of milliseconds)

Most IR *data* is really quite slow on the de-modulated side.
Pulses of around 500us to 2500us are quite normal.

>IR pulses tend to be short as greater range can be attained by
>dumping large currents into the LED. This of course means
>that average power must be kept low by keeping the pulse
>short

Yes, the IR *pulses* are short. The rx data is still slow though.
The little all-in-1 demodulator blocks take care of that.  :-)
<snip>
You could probably use RB0 and make it interrupt driven.
Regards...

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.