Building an IR Receiver

[Anonymous]

 Hi,

   

I've been experimenting with a PSoC 3 'FirstTouch' eval kit. So far I am very pleased with it.

   

I am beginning to think about a serious application for a PSoC 3 chip, and thought I would circulate a few ideas here and see what the rest of the community think of it.

   

I'd like to build a universal IR (Infrared) receiver and decoder. One which can decode just about any common infra red remote control signal. The front end would be Vishay or Sharp Infrared receivers which demodulate the 36/38KHz signal.

   

I think I'd connect the output of the IR Receiver to a digital input pin.

   

So what would be best next? Can I implement an IR Signal decoder in hardware? Or should I simply generate an interrupt on the falling edge of the signal, then decode it all in software?

   

I've already done this several times in various projects, but using traditional micro-processors and doing it all in software. Mainly I just count deltas (the time the signal stays hi or low) and compare against a look up table, with a certain amount of jitter built in. 

   

However in this new approach I wonder if it's possible to actually decode the IR signal and extract the control codes - preferably in hardware, or a combination of hardware/software.  Any thoughts?

   

I already understand how to decode IR signals such as RC-5, RC-6 and so on, so I don't need references to 'understanding ir' - I'm more looking for any insight on the best approach to take to doing this on PSoC.

   

What would be best? A simple digital Input Pin, and ISR and software counters? Or some kind of digital input connected to a timer and shift register? How would that handle the preamble, and how could I detect different encoding schemes?

   

-Kenny

[Anonymous]

I think this could be done in the hardware using the UDBs.  Do you need the processor's MIPS to perform other functions (and thus the desire to offload to the hardware) or are you just curious if it can do it?  Reason I ask is if you already have code, it seems like it would be an easy port if you keep it done in software.

       

-Bobby

[Anonymous]

Bobby, 

   

Thanks for the reply. You have piqued my interest with talk about UDBs - that's something I think I'll need to learn more about.

   

I ported my existing code (From a Rabbit 5000 uP) over and have it working. I placed a single digital input pin, enabled interrupt on falling edge and popped a simple loop polling the pin for state into the ISR. It feels like a really inefficient way to do it on a PLD hence why I'm wondering about whether it can be done in hardware.

   

One thing I was very impressed with was this: I connected a 'not' gate to a digital output pin and connected it to a LED on the board and it continued to work even when the debugger was sitting on a break point. For someone who is brand new to PSoC and CPLDs this was impressive. 😉

       

Now, is there a good resource I can dig into to learn about the capabilities of the UDBs?

       

-K

[Anonymous]

 I had a look at the timer v1.0 component.

   

It looks like it could do the job, partly, when set to trigger on either-edge. However it's fifo can hold a maximum of only 4 counts. If that could be uprated to a higher number, like say, 48 then it would be ideal.

[Anonymous]

For more information about the UDBs, I recommend starting with the PSoC 3 & PSoC 5 Technical Reference Manual (TRM).  You can find it here: http://www.cypress.com/?rID=35180.

       

-Bobby

[Anonymous]

 Thanks,

   

I'll take a look at that. 🙂

       

-K

[Anonymous]

Hi KennyMillar,

       

The Components have a Hardware FIFO which is 4 Bytes deep. The size of the FIFO can be increased beyond this too. For this, the SRAM memory will be used up, and  ISRs will handle to ensure that the bytes are stored in the FIFO of specified length.

       

Regards,

   

dasg