Searching \ for '[PIC]: Reading/Decoding IR Remote Control Pulses' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=ir
Search entire site for: 'Reading/Decoding IR Remote Control Pulses'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Reading/Decoding IR Remote Control Pulses'
2004\04\17@095436 by Matt Marsh

flavicon
face
Hi guys,

For my second PIC project, I'm going to need to detect a button
being pressed on an IR remote control. I've done a small amount of
research on this and from what I've read I'm going to need to hook
up an IR receiver to one of the pins and then time how long pulses
last (and/or the gaps between them depending on the remote).

So, in order to determine how long a pulse lasts I'm thinking that
I'm going to need to do something like:

 - loop waiting for pin to go high
 - reset TMR0
 - loop waiting for pin to go low
 - value in TMR0 now contains length of time of pulse

I just wanted to get some feedback whether I'm thinking of this in
the right way, or whether there is some other technique that is
generally used for timing pulses etc.

Thanks,
Matt

--
Matt N. Marsh
Email: spam_OUTmattTakeThisOuTspammattmarsh.net          Yahoo: marshmn
 Web: http://www.mattmarsh.net/  Jabber: .....mattmarshKILLspamspam@spam@jabber.org
                                    MSN: mattspamKILLspammattmarsh.net
                                    ICQ: 250467363
                                    AIM: MattMarshUK

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\17@102417 by Jinx

face picon face
> I just wanted to get some feedback whether I'm thinking of this
> in the right way, or whether there is some other technique that
> is generally used for timing pulses etc

A quick way would be to use a scope to get some ballpark (or
even actual) idea of how the stream is put together.

Is this a commercial transmitter ? If so you may find the format
and timing on the web. You could use timing code to confirm
that

Otherwise what you suggest should work with a 3-pin detector
that has a logical output (might be inverted), as they strip the
carrier frequency out and present the PIC with just the data

There could be several timings present. The pulse itself, a "0"
space, a "1" space, the inter-burst space, possibly others, that
will probably be multiples of a base period. The faster you have
the PIC running the better the resolution, although this may not
matter too much if the periods are distinct and relatively long

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\17@104419 by Andrew Kilpatrick

flavicon
face
I've played around with this a bit. You need to read not only
the presence of a pulse, but decode the pulse train as well.
Most of the receivers I've seen put out the data output with
the carrier removed. This means that either you need to write
your software with the timing for a specific model of remote,
or you need to have some way of teaching the PIC. (like a
learning remote) The former is probably the best way to start.
If you find specs on the web, it will let you write receiving
code without much trial and error. I made a PIC send codes to
my CD player, and the data format was very simple. It was just
two bytes, the first being the actual command byte, and the
second being the retrograde (bits changed MSB to LSB first, or
whatever) of the byte as a checksum.

The data rates are usually very low (1000bps) because the
carrier is only around 40khz. You'll find that some buttons on
the remote, such as volume and channel, send the code repeating
over and over, obviously so you can hold down the button. The
repetitions are usually fast enough to trigger a scope. You can
usually fit the entire message on the screen at once. This will
give you a really good idea of what sort of timing you're working
with.


Andrew

On Sat, Apr 17, 2004 at 02:54:11PM +0100, Matt Marsh wrote:
{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\17@113306 by Matt Marsh

flavicon
face
Hi,

On Saturday 17 April 2004 15:25, Jinx wrote:
> Is this a commercial transmitter ? If so you may find the format
> and timing on the web. You could use timing code to confirm
> that

Yeah, it is a commerical remote, in fact I want to use the one that
is available for the XBox. I'm currently googling to see if I can
get the relevant specs for it.

> Otherwise what you suggest should work with a 3-pin detector
> that has a logical output (might be inverted), as they strip the
> carrier frequency out and present the PIC with just the data
>
> There could be several timings present. The pulse itself, a "0"
> space, a "1" space, the inter-burst space, possibly others, that
> will probably be multiples of a base period. The faster you have
> the PIC running the better the resolution, although this may not
> matter too much if the periods are distinct and relatively long

ok, great. Hopefully I can find the specs for the remote and
validate what sort of lengths of time I'm going to be dealing with.

Thanks,
Matt

--
Matt N. Marsh
Email: @spam@mattKILLspamspammattmarsh.net          Yahoo: marshmn
 Web: http://www.mattmarsh.net/  Jabber: KILLspammattmarshKILLspamspamjabber.org
                                    MSN: RemoveMEmattTakeThisOuTspammattmarsh.net
                                    ICQ: 250467363
                                    AIM: MattMarshUK

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\17@113720 by Matt Marsh

flavicon
face
Hi Andrew,

On Saturday 17 April 2004 15:43, Andrew Kilpatrick wrote:
> I've played around with this a bit. You need to read not only
> the presence of a pulse, but decode the pulse train as well.
> Most of the receivers I've seen put out the data output with
> the carrier removed. This means that either you need to write
> your software with the timing for a specific model of remote,
> or you need to have some way of teaching the PIC. (like a
> learning remote) The former is probably the best way to start.

Yeah, that was my plan. I might do the learning thing later as that
will give me chance to learn how to use the EEPROM space too in
order to store the learned codes in.

> If you find specs on the web, it will let you write receiving
> code without much trial and error. I made a PIC send codes to
> my CD player, and the data format was very simple. It was just
> two bytes, the first being the actual command byte, and the
> second being the retrograde (bits changed MSB to LSB first, or
> whatever) of the byte as a checksum.

Ah, I hadn't realised they had checksums and things... useful to
know.

> The data rates are usually very low (1000bps) because the
> carrier is only around 40khz. You'll find that some buttons on
> the remote, such as volume and channel, send the code repeating
> over and over, obviously so you can hold down the button. The
> repetitions are usually fast enough to trigger a scope. You can
> usually fit the entire message on the screen at once. This will
> give you a really good idea of what sort of timing you're working
> with.

I've been wondering how long it will be before I have to get around
to buying a scope :-) And learning how to use it for that matter...
pity they are so expensive though :-( I might see if I can pick up
a second hand one on ebay...

Thanks for all the info, very useful.
Matt

--
Matt N. Marsh
Email: spamBeGonemattspamBeGonespammattmarsh.net          Yahoo: marshmn
 Web: http://www.mattmarsh.net/  Jabber: TakeThisOuTmattmarshEraseMEspamspam_OUTjabber.org
                                    MSN: RemoveMEmattspamTakeThisOuTmattmarsh.net
                                    ICQ: 250467363
                                    AIM: MattMarshUK

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\17@125325 by Wouter van Ooijen
face picon face
> So, in order to determine how long a pulse lasts I'm thinking that
> I'm going to need to do something like:

I wrote IR-receive code for RC5, sharp and NEC. It is all in Jal, except
for a timing routine that contains some assembler (~ 6 statements). No
timers.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\17@133347 by michael brown

picon face
Matt Marsh wrote:
> Hi guys,
>
> For my second PIC project, I'm going to need to detect a button
> being pressed on an IR remote control. I've done a small amount of
> research on this and from what I've read I'm going to need to hook
> up an IR receiver to one of the pins and then time how long pulses
> last (and/or the gaps between them depending on the remote).

Ok

> So, in order to determine how long a pulse lasts I'm thinking that
> I'm going to need to do something like:
>
>   - loop waiting for pin to go high
>   - reset TMR0
>   - loop waiting for pin to go low
>   - value in TMR0 now contains length of time of pulse

That should work.  The output of normal IR detectors is nicely processed
and fairly easy to work with, just remember to ground the metal housing
if there is one.  A scope and a powered IR detector will show you
everything you need to know.  The output pin of the detector is normally
idling at Vcc and drops to Vss when an appropriate carrier is detected.
The detector strips the carrier from the signal and you only see the
unmodulated pulses.  IOW, it looks much like bursts of serial data bits
to the micro.  A burst (frame) may contain roughly 8-20 bits depending
upon the system being used, the difference being that they are usually
PWM or Manchester encoded instead of simply being present or missing to
indicate a 0 or 1.

> I just wanted to get some feedback whether I'm thinking of this in
> the right way, or whether there is some other technique that is
> generally used for timing pulses etc.

The CCP feature is ideal for doing this without wasting allot of CPU
cycles looping, plus it's more accurate/consistant.  No one seems to
have mentioned this yet, I'm kinda surprised.  ;-)

Have fun

michael brown

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\17@141200 by PicDude

flavicon
face
I just did this recently, with an IR LED with a PIC12F629 for the transmitter and a 3-pin 38khz IR receiver module with a PIC16F628 for the receiver.  I came up with my own 8-bit coding scheme, which has start and stop bits.  The receiver module goes low when it senses a 38khz signal, so I used...

       (1)  Wait for negative-edge interrupt
       (2)  Interrupt off.  Set TMR0 for 0.5 T (where pulse (bit) width = T)
       (3)  Read pin state and set in a register (let's call it CODE)
       (4)  Set TMR0 for 1 T
       (5)  Read pin state
       (6)  Left-shift into the CODE register
       (7)  Repeat from step 4 until 8 total bits received.
       (8)  Ensure blank for some interval time, then reset, interrupt on, etc.

The first 0.5 T sets the point of reading to be in the middle of the pulse.

Then check the code with what you have.  Fairly simple.

Cheers,
-Neil.



On Saturday 17 April 2004 08:54 am, Matt Marsh scribbled:
{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\17@150223 by Matt Marsh

flavicon
face
> > I just wanted to get some feedback whether I'm thinking of this
> > in the right way, or whether there is some other technique that
> > is generally used for timing pulses etc.
>
> The CCP feature is ideal for doing this without wasting allot of
> CPU cycles looping, plus it's more accurate/consistant.  No one
> seems to have mentioned this yet, I'm kinda surprised.  ;-)

So now of course I have to ask, what is CCP? :-)

Matt

--
Matt N. Marsh
Email: mattEraseMEspam.....mattmarsh.net          Yahoo: marshmn
 Web: http://www.mattmarsh.net/  Jabber: EraseMEmattmarshspamjabber.org
                                    MSN: RemoveMEmattEraseMEspamEraseMEmattmarsh.net
                                    ICQ: 250467363
                                    AIM: MattMarshUK

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\17@151401 by Shawn Wilton

flavicon
face
Capture
Compare
PWM


Shawn Wilton
Junior in CpE
MicroBiologist

Phone: (503) 881-2707
Email: RemoveMEshawnspam_OUTspamKILLspamblack9.net

http://black9.net


Matt Marsh wrote:
{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\17@155844 by William Chops Westfield

face picon face
There was an interesting idea that was in Myke Predko's "Programming &
Customizing PICmicro Microcontrollers" which sounds like it would work
well if you're only interested in decoding a relatively small number of
button-presses.  Basically, given an approximate idea of the length of
a given protocol, you arrange to have a bunch of samples happen during
that period (after seeing the initial state change on the IR decoder),
and then calculate a hash (CRC-style) of each bit.  When you're "done",
the resulting hash value will probably have a pretty good one-to-one
correspondence with the button pushed.  (the advantage being that you
don't have to decode or understand the specifics of the protocol being
used...)  I thought that was pretty neat.  (actually, come to think of
it, you don't even need to know the sequence length; just wait till you
stop seeing transitions.)  If it's more convenient, I think you can
hash the time between transitions instead of the bit values...  And you
can recognize multiple remote protocols without having to implement
multiple protocols...

The disadvantage, aside from possible false triggering, is that you
have to "train" your software somehow, because there's no way of
knowing ahead of time what the hashed codes are going to be for the
buttons you're interested in.  You can train on the initial powerup, if
you want, or design some circuit to upload/display/whatever codes as
you press buttons, and hardcode them into software...

BillW

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\17@164857 by Wouter van Ooijen

face picon face
> the resulting hash value will probably have a pretty good one-to-one
> correspondence with the button pushed.  (the advantage being that you
> don't have to decode or understand the specifics of the protocol being
> used...)

You do know that some protocols (like RC5) have one bit that is flipped
each message? So if you use this trick you would half the time have to
press a button twice :(

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\17@164901 by Byron A Jeff

face picon face
On Sat, Apr 17, 2004 at 02:54:11PM +0100, Matt Marsh wrote:
> Hi guys,
>
> For my second PIC project, I'm going to need to detect a button
> being pressed on an IR remote control. I've done a small amount of
> research on this and from what I've read I'm going to need to hook
> up an IR receiver to one of the pins and then time how long pulses
> last (and/or the gaps between them depending on the remote).

Right on the mark.

{Quote hidden}

"Young grasshoppa, there is no right, there is no wrong, there is only
options."

This is especially true here. Let me make a couple of observations then throw
out my suggests:

1) Typically for remote protocols, only the pulse width of one polarity is
important. And again typically this is the polarity of when the IR led is
on and a pulse is actively being sent. See this web page for examples:

http://users.pandora.be/davshomepage/sony.htm

You are on point on that with your code above.

2) The difference pulse widths are often multiples of some base width. So
in the Sony example the base width T is defined as 600 uS. So a 0 it 1T,
a one is 2T, and a start bit is 4T. So it's possible to measure at a much
longer interval then simply counting.

So now onto how to get it done. If you have a CCP (Capture/Compare/PWM) module
it's your bestest friend for such a project. It'll measure the pulse widths
for you, give you an interrupt when it's done capturing, and has programmable
polarity and counting speed. It's literally set and forget.

Otherwise the purely software approach you outlined above is possible. However
it may be better to integrate it into an interrupt routine where you capture
or count samples at an interval of T/3 or similar. Then you'll get max 3T
samples/counts for every interval. So say T=600 uS so you interrupt then
capture/count every 200 uS. Since zero=T one=2T and start=4T, then the counts
you'd get for zero is 2-3, one is 5-6 and start is 11-12. Now the beauty of
this approach is that now the capture happens completely in the background
so you can get other stuff done while you waiting for transistions.

If you have a Universal remote the Sony protocol is nice because it's simple,
and very well documented.

Hope this helps,

BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\17@172108 by Jan-Erik Soderholm

face picon face
Matt Marsh wrote :
> Hi guys,
>
> For my second PIC project, I'm going to need to detect a button
> being pressed on an IR remote control....
> So, in order to determine how long a pulse lasts I'm thinking that
> I'm going to need to do something like:
>
>   - loop waiting for pin to go high
>   - reset TMR0
>   - loop waiting for pin to go low
>   - value in TMR0 now contains length of time of pulse

I did something similar some time ago.
Sender was 18F1320 with protocol made up by me.
Receiver was a 12F675 using a TSOP IR recever.

First I set up the IR-input pin of the 12F675 for "interrupt-on-
change" and using passive pullup. The "interrupt edge" was
initialy set to "idle-to-carrier-present" (0->1) edge.

Then in the ISR for the interrupt-on-change I did :

- Was this a 0>1 slope ?
 We have a start-of-carrier (pulse) edge !
 - clear timer 1
 - toggle the "interrupt edge" bit.
 - exit ISR

- Was this a 1>0 slope ?
 We have an end-of-carrier (pulse) edge !
 - Check timer 1 for start/zero/one bit.
 - Take care of the bit accordingly.
 - toggle the "interrupt edge" bit.
 - Exit ISR.

The timing of the start/zero/one "pulses" was selected
in such a way that it was enough to check a single
bit (bcf/bsf) in TMR1 to detect the type of pulse. Didn't
have to check against some "ranges" at all. Fast and simple.
The ISR updated a few status variables to keep track of where
it was in the pulse train between different runs of the ISR.

The "command" sent begun with a "start" bit, and then about
25 bits in 4-5 different "fields" like "device number", "command",
"value" and so on.

Since timer 1 is reset at the start of each bit/pulse, there are no
cumultative errors. Any timing errors betwen the sending and the
receiving PIC's are zeroed out at the beginning of each new pulse.

There are never any code "waiting" for anything. The ISR end as fast
as possible. The 12F675 was at the same time handling a 100 Hz interrupt
on another pin (from a zero cossing detector) and also handling
phase control on an output (using another timer interrupt). By building
it all without any software timing/delaying code at all, at was much
easier to get it all together. Everyting was interrupt driven, the
"main" part of the code, just run in a loop checking a number of
flags that was set by the different ISR's.

Best Regards
Jan-Erik.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\17@210904 by Jinx

face picon face
> ok, great. Hopefully I can find the specs for the remote and
> validate what sort of lengths of time I'm going to be dealing with

I've looked up some old 877 code I used to characterise and then
simulate the output from a Philips SAA3001 IR transmitter used
as a 2-wire keyboard encoder

Its timing is based on a 455kHz ceramic oscillator, which gives
a base Tosc of 2.2us. Pulse width is Tosc x 4, "0" space is Tosc
x (2 x 1152), "1" space is Tosc x (3 x 1152), inter-burst space is
Tosc x 55296

The PIC runs at 20MHz -> 200ns IC. INT is set to trigger on the
rising edge of the first pulse, the period of which is counted by
TMR1. During this time the polarity of INT is flipped to trigger
on the falling edge of the pulse, at which point TMR1 is saved
to RAM. It's cleared and measures the period of the following
"0" or "1" space. This pulse-space measuring continues until a
TMR1 roll-over occurs, which means that the data burst has
finished and it's into the inter-burst period. On the next INT IRQ
(which is the rising edge of the first pulse of the next burst),
measuring ceases and the RAM values are saved to EEPROM
(after compensation for non-counting instruction cycles) so they
can be read in MPLAB to determine the 01 pattern

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\04\18@093450 by Matt Marsh

flavicon
face
On Saturday 17 April 2004 21:49, Byron A Jeff wrote:
> So now onto how to get it done. If you have a CCP
> (Capture/Compare/PWM) module it's your bestest friend for such a
> project. It'll measure the pulse widths for you, give you an
> interrupt when it's done capturing, and has programmable polarity
> and counting speed. It's literally set and forget.

So, having had a couple of responses saying that CCP would be useful
for this, I thought I'd better do a bit of research into CCP (given
that I hadn't heard of it before). It certainly looks interesting,
although from Microchip's website I can only see it available on
some of the 18F* chips? Is that correct? If so, I might have to do
without CCP and do it the more manual approach as I was hoping to
do this on one of the small 8-pin 12F629 (or similar) chips.

Thanks,
Matt

--
Matt N. Marsh
Email: mattSTOPspamspamspam_OUTmattmarsh.net          Yahoo: marshmn
 Web: http://www.mattmarsh.net/  Jabber: spamBeGonemattmarshSTOPspamspamEraseMEjabber.org
                                    MSN: KILLspammattspamBeGonespammattmarsh.net
                                    ICQ: 250467363
                                    AIM: MattMarshUK

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

2004\04\18@104116 by Byron A Jeff

face picon face
On Sun, Apr 18, 2004 at 02:34:08PM +0100, Matt Marsh wrote:
> On Saturday 17 April 2004 21:49, Byron A Jeff wrote:
> > So now onto how to get it done. If you have a CCP
> > (Capture/Compare/PWM) module it's your bestest friend for such a
> > project. It'll measure the pulse widths for you, give you an
> > interrupt when it's done capturing, and has programmable polarity
> > and counting speed. It's literally set and forget.
>
> So, having had a couple of responses saying that CCP would be useful
> for this, I thought I'd better do a bit of research into CCP (given
> that I hadn't heard of it before). It certainly looks interesting,
> although from Microchip's website I can only see it available on
> some of the 18F* chips? Is that correct?

Nope. Not even close. From a cursory look, the smallest cheapest chips with it
is the 16F818 with a Digikey single chip price of $3.25 and the 16F628A
weighing in at $3.05. That's about double the price of the 12F629. OTOH
you do get more pins, more memory, and more peripherals to play with
(like a hardware UART if you happen to need it).

> If so, I might have to do
> without CCP and do it the more manual approach as I was hoping to
> do this on one of the small 8-pin 12F629 (or similar) chips.

It's a tradoff. A more expensive 18 pin part that has the hardware vs. a
less expensive 8 pin part that doesn't. Since I have stacks of both on hand
(along with 16F87X and 18F parts) I'd just pick the one that the application
requires. However as I said in my original post, there are no right or wrong
choices here, just choices. So pick based on what you have on hand, or the
price point, or if the design requires multiple tasks to be done at the same
time (A big seller for me. It's why I choose hardware laden parts like the
16F88 and the 16F877A).

The only wrong choice is something that doesn't work.

BAJ

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

2004\04\18@110643 by Shawn Wilton

flavicon
face
As you don't have any parts on hand, you can also bounce to the
microchip site and grab some samples.


Shawn Wilton
Junior in CpE
MicroBiologist

Phone: (503) 881-2707
Email: EraseMEshawnspamEraseMEblack9.net

http://black9.net

Byron A Jeff wrote:
{Quote hidden}

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

2004\04\18@112957 by Jan-Erik Soderholm

face picon face
Matt Marsh wrote :

> If so, I might have to do
> without CCP and do it the more manual approach as I was hoping to
> do this on one of the small 8-pin 12F629 (or similar) chips.

There is nothing in the 12Fxxx chips stopping you to use it as a
recevier for IR remote control codes. Just use whatever tools they have.

Let me know if you'd like a copy of my 12F675 code, and I'll
zip it up and send it over. Note that this is a maybe 80% done project,
but the I think that the IR part was more or less running OK.
And also, it was written to use Olin Lathrops development environment,
so it used his macros where appropriate, but I think you could
replace them with your own code...

Jan-Erik.

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

2004\04\18@115112 by Ake Hedman

flavicon
face
Jan-Erik,

Can your code be used for an Open Source/Open Hardware project? I'm
working with a couple of modules for the VSCP (Very Simple Control
Project- http://www.vscp.org) and one of the planned modules is an IR
receiver (RC5). As this is something done "just for fun" (I never expect
someone else to bother about/like/use VSCP...) it would have been nice
if at least the code and possibly the hardware designs where useful also
for other projects.

/Ake

-----Ursprungligt meddelande-----
Från: pic microcontroller discussion list
[@spam@PICLIST@spam@spamspam_OUTMITVMA.MIT.EDU]För Jan-Erik Soderholm
Skickat: den 18 april 2004 17:31
Till: spamBeGonePICLISTspamKILLspamMITVMA.MIT.EDU
Ämne: Re: [PIC]: Reading/Decoding IR Remote Control Pulses


Matt Marsh wrote :

> If so, I might have to do
> without CCP and do it the more manual approach as I was hoping to
> do this on one of the small 8-pin 12F629 (or similar) chips.

There is nothing in the 12Fxxx chips stopping you to use it as a
recevier for IR remote control codes. Just use whatever tools they have.

Let me know if you'd like a copy of my 12F675 code, and I'll
zip it up and send it over. Note that this is a maybe 80% done project,
but the I think that the IR part was more or less running OK.
And also, it was written to use Olin Lathrops development environment,
so it used his macros where appropriate, but I think you could
replace them with your own code...

Jan-Erik.

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

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

2004\04\18@123545 by Matt Marsh

flavicon
face
On Sunday 18 April 2004 16:30, Jan-Erik Soderholm wrote:
> Matt Marsh wrote :
> > If so, I might have to do
> > without CCP and do it the more manual approach as I was hoping
> > to do this on one of the small 8-pin 12F629 (or similar) chips.
>
> There is nothing in the 12Fxxx chips stopping you to use it as a
> recevier for IR remote control codes. Just use whatever tools
> they have.

This is indeed what I may well do.

> Let me know if you'd like a copy of my 12F675 code, and I'll
> zip it up and send it over. Note that this is a maybe 80% done
> project, but the I think that the IR part was more or less
> running OK. And also, it was written to use Olin Lathrops
> development environment, so it used his macros where appropriate,
> but I think you could replace them with your own code...

Well if you wouldn't mind sending me a copy, that would be great.
I'm sure it will give me some good hints to get me going.

Thanks for the help,
Matt

--
Matt N. Marsh
Email: .....mattspam_OUTspammattmarsh.net          Yahoo: marshmn
 Web: http://www.mattmarsh.net/  Jabber: TakeThisOuTmattmarsh.....spamTakeThisOuTjabber.org
                                    MSN: TakeThisOuTmattKILLspamspamspammattmarsh.net
                                    ICQ: 250467363
                                    AIM: MattMarshUK

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

2004\04\18@123959 by Matt Marsh

flavicon
face
On Sunday 18 April 2004 15:42, Byron A Jeff wrote:
{Quote hidden}

Ah, you're totally right, my searching of Microchip's website was
obviously far from effective. Now that I've gone back there and
looked again I can see that there are several that I missed the
first time. I also notice a new 8-pin chip which claims to have CCP
which is the 12F683 and looks right up my street. However, it was
due for release just 2 days ago and I can't yet see it listed on
their samples section or at any suppliers yet.

Are Microchip usually on-time with when they say that something is
going to be released? And do they normally have samples available
soon after release?

Thanks for your help,
Matt

--
Matt N. Marsh
Email: .....mattspamRemoveMEmattmarsh.net          Yahoo: marshmn
 Web: http://www.mattmarsh.net/  Jabber: RemoveMEmattmarshspamspamBeGonejabber.org
                                    MSN: spamBeGonematt@spam@spamspam_OUTmattmarsh.net
                                    ICQ: 250467363
                                    AIM: MattMarshUK

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

2004\04\18@143751 by Wouter van Ooijen

face picon face
> Are Microchip usually on-time with when they say that something is
> going to be released? And do they normally have samples available
> soon after release?

Microchip on-time with releasing?? Should I ROFL or weep and cry?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

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

2004\04\18@171750 by Byron A Jeff

face picon face
On Sun, Apr 18, 2004 at 05:39:16PM +0100, Matt Marsh wrote:
{Quote hidden}

Typical.

>
> Are Microchip usually on-time with when they say that something is
> going to be released?

No. Quick example: dsPICs were announced over 3 years ago. It's still not
available in anything other than engineering examples at this point.

> And do they normally have samples available soon after release?

Don't count on it. With Mchip it's always best to use something in wide scale
production. You can grow old waiting for them to release new stuff.

BAJ

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

2004\04\21@135844 by Edson Brusque

face
flavicon
face
Hello Wouter,

> I wrote IR-receive code for RC5, sharp and NEC. It is all in Jal, except
> for a timing routine that contains some assembler (~ 6 statements). No
> timers.

    I don't use Jal, but even so I would like to take a look at it if
you don't mind.

    I'm thinking about an efficient way to receive an IR stream from
any remote control (well, Sony, NEC, JVC, RC5 and RC6 actually). It's
for some sort of remote control system integration project.

    Thank you very much,

    Brusque

--
---------------------------------------------------------------------
Edson Brusque                     C.I.Tronics Lighting Designers Ltda
Research and Development                   Blumenau  -  SC  -  Brazil
http://www.suporte.ind.br/ryan/netiqueta.htm     http://www.citronics.com.br
---------------------------------------------------------------------

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...