Post by thread:[PIC]: Reading/Decoding IR Remote Control Pulses

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_OUTmattTakeThisOuTmattmarsh.net Yahoo: marshmn Web: http://www.mattmarsh.net/ Jabber: .....mattmarshKILLspam@spam@jabber.org MSN: mattKILLspammattmarsh.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

> 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

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}> 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: .....mattKILLspam.....mattmarsh.net Yahoo: marshmn > Web: http://www.mattmarsh.net/ Jabber: EraseMEmattmarshspam_OUTTakeThisOuTjabber.org > MSN: mattspam_OUTmattmarsh.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 -- 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

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@mattKILLspammattmarsh.net Yahoo: marshmn Web: http://www.mattmarsh.net/ Jabber: KILLspammattmarshKILLspamjabber.org MSN: RemoveMEmattTakeThisOuTmattmarsh.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

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: spamBeGonemattspamBeGonemattmarsh.net Yahoo: marshmn Web: http://www.mattmarsh.net/ Jabber: TakeThisOuTmattmarshEraseMEspam_OUTjabber.org MSN: RemoveMEmattTakeThisOuTmattmarsh.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

> 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

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

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}> 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 -- 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

> > 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: mattEraseME.....mattmarsh.net Yahoo: marshmn Web: http://www.mattmarsh.net/ Jabber: EraseMEmattmarshjabber.org MSN: RemoveMEmattEraseMEEraseMEmattmarsh.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

Capture Compare PWM Shawn Wilton Junior in CpE MicroBiologist Phone: (503) 881-2707 Email: RemoveMEshawnspam_OUTKILLspamblack9.net http://black9.net Matt Marsh wrote: {Quote hidden}>>>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: RemoveMEmattTakeThisOuTspammattmarsh.net Yahoo: marshmn > Web: http://www.mattmarsh.net/ Jabber: EraseMEmattmarshspamspamBeGonejabber.org > MSN: RemoveMEmattKILLspammattmarsh.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 -- 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

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

> 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

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}> > 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. "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

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

> 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

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: mattSTOPspamspam_OUTmattmarsh.net Yahoo: marshmn Web: http://www.mattmarsh.net/ Jabber: spamBeGonemattmarshSTOPspamEraseMEjabber.org MSN: KILLspammattspamBeGonemattmarsh.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.

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.

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: EraseMEshawnEraseMEblack9.net http://black9.net Byron A Jeff wrote: {Quote hidden}> 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. -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.

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.

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@spam_OUTMITVMA.MIT.EDU]För Jan-Erik Soderholm Skickat: den 18 april 2004 17:31 Till: spamBeGonePICLISTKILLspamMITVMA.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.

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_OUTmattmarsh.net Yahoo: marshmn Web: http://www.mattmarsh.net/ Jabber: TakeThisOuTmattmarsh.....TakeThisOuTjabber.org MSN: TakeThisOuTmattKILLspamspammattmarsh.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.

On Sunday 18 April 2004 15:42, Byron A Jeff wrote: {Quote hidden}> 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). 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: .....mattRemoveMEmattmarsh.net Yahoo: marshmn Web: http://www.mattmarsh.net/ Jabber: RemoveMEmattmarshspamBeGonejabber.org MSN: spamBeGonematt@spam@spam_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.

On Sun, Apr 18, 2004 at 05:39:16PM +0100, Matt Marsh wrote: {Quote hidden}> On Sunday 18 April 2004 15:42, Byron A Jeff wrote: > > 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). > > 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. 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.

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