| View previous topic :: View next topic |
| Author |
Message |
sanddune008
Joined: 23 Oct 2008
Posts: 38
|
| Problem in Implementing an IR code.... |
 Posted: Fri Nov 14, 2008 3:48 am |
 |
|
Hi all,
I am implementing code for IR remote.
Following is the code for sending an command.
| Code: |
e.g.
#use delay(clock=4000000)
send command()
{
//command 0xA6
//will send data bits based on the command
SendBit0();
SendBit1();
}
//send bit 0 of data
void SendBit0(void)
{
int OnTime = 13,OffTime=82; //based on protocol
//38khz Pulses
for( OnTime = 0;OnTime < ON_TIME;OnTime++ )
{
//-------- Generate pulses of 50% duty cycle and 38Khz -------------------------
IR_LED_ON; //setting pin low
delay_us(13);
IR_LED_OFF;//setting pin high
delay_us(13);
//-------- Generate pulses of 50% duty cycle and 38Khz -------------------------
}
//No pulses for 82
for( OffTime = 0;OffTime < BIT0_OFF_TIME;OffTime++ )
{
IR_LED_OFF;
}
Similarly for sending Bit1
bit1()
{
//similiar to the above function
}
} |
what I need to know is, will this be an efficient way of sending IR command
data bits?
As the data bits need to be continuous, will the funtion calls to bit0() and bit1() from send command() , affect the continuity of the data bits.If yes
then how many machine cycles will be consumed between function calls?
As i use following encoding scheme to send bit 1 == [13*(1/carrier freq)](duration for sending pulses)+ [82*(1/carrier freq)]( duration for no pulses sent)
OR is Timer or PWM the best option to go? how to achieve this using timer or PWM?
Thanks in advance |
|
 |
TTelmah
Guest
|
|
| Posted: Fri Nov 14, 2008 4:32 am |
|
|
Problems:
First, your initial 'pulse' code, will not give 38KHz. Instructions take _time_. The addition, then test for the loop, will take a few uSec, and the instructions to turn the LED on and off, also take time. I'd expect to see something like perhaps 30KHz from this loop.
Then, the opposite happens in the 'off' loop. This loops 82 times, but only takes the time needed for the LED off instruction, and the arithmetic in the loop count. A total of perhaps half a mSec, rather than the 2.16mSec needed by the protocol.
It is also really 'pointless' to loop here. The LED is always 'off' when you arrive here, so why not just wait for the required time (delay_us(2158)). Nothing else is needed.
So, provided you don't need to do anything else (remember if an interrupt occurs, the pulse train _will_ be mistimed at this point), the basic method will work. However it will need 'tweaking' to get the timing right, and can be simplified by removing the second loop.
Best Wishes |
|
|
sanddune008
Joined: 23 Oct 2008
Posts: 38
|
|
| Posted: Fri Nov 14, 2008 4:58 am |
|
|
Thanks............
Then this approach seems to be a total waste isn't?
How do i achieve the same(sending 38khz pulses for 343us and no pulses for 2.15ms for sending data Bit 1 similarly for data bit 0 ) using a timer or say a PWM (as i am using 16F628A). As i am new to embedded.....
A hint or help in this direction will be greatly appreciated
Thanks in advance. |
|
|
sanddune008
Joined: 23 Oct 2008
Posts: 38
|
|
| Posted: Fri Nov 14, 2008 7:05 am |
|
|
| Is the same possible with timer and PWM....if so a how? |
|
|
Rohit de Sa
Joined: 09 Nov 2007
Posts: 282
Location: India
|
|
| Posted: Fri Nov 14, 2008 8:40 am |
|
|
No, this approach isn't a total waste. This method will work absolutely fine as long as the processor has nothing else to do. The minute you add interrupts and other things you may need to start looking at tighter and more efficient code.
PWM and timers can also be used to do this, but it is a little more involved.
I would suggest setting the TRIS registers (pin directions) manually, using appropriate delays. Simulate your code in MPLAB Sim, and tweak the delays to get close to 38kHz.
Rohit |
|
|
sanddune008
Joined: 23 Oct 2008
Posts: 38
|
|
| Posted: Fri Nov 14, 2008 8:53 am |
|
|
| Rohit de Sa wrote: | Simulate your code in MPLAB Sim, and tweak the delays to get close to 38kHz.
Rohit |
Thanks....
how do I simulate using CCS IDE? as I am using CCS.
Yes I am involving interrupt in my application.
Thanks |
|
|
sanddune008
Joined: 23 Oct 2008
Posts: 38
|
|
| Posted: Fri Nov 14, 2008 8:57 am |
|
|
| Rohit de Sa wrote: | tweak the delays to get close to 38kHz.
Rohit |
can you suggest me a better approach.
No if I have to use timers how do I need to proceed with encoding bit 0 and bit 1 at 38 khz carrier frequency
Thanks |
|
|
Rohit de Sa
Joined: 09 Nov 2007
Posts: 282
Location: India
|
|
| Posted: Fri Nov 14, 2008 9:39 pm |
|
|
| Quote: | | how do I simulate using CCS IDE? as I am using CCS. |
IMHO, MPLAB has a better debugging and stimulus interface. I use MPLAB for debugging (you can get it as a free download off the Microchip website). There is even a nice stopwatch which can time your code.
I don't care much for the CCS IDE for debugging purposes. But it has a lot of nifty features which are very helpful - Valid Fuses and Interrupts and the ability to view output file statistics (size, memory usage, function stats, etc), are useful while developing code.
| Quote: | | if I have to use timers how do I need to proceed with encoding bit 0 and bit 1 at 38 khz carrier frequency |
Depending on the PIC you choose, you will have access to at least one 8-bit timer, or better. You can use the timer in different ways to help output 38kHz. You can setup the timer and its corresponding clock source in such a way that it rolls over at a rate of 38kHz. The interrupt generated by this roll-over is you cue to toggle the LED. In practice, you will need to setup the timer a little faster than 38kHz due to code and interrupt overheads. If you have a PWM module on your PIC you can vary its duty cycle and period to output an infrared pulse train. ex_pwm.c in the Examples folder has some code to get you started.
Rohit |
|
|
Ttelmah
Guest
|
|
| Posted: Sat Nov 15, 2008 3:21 am |
|
|
Realistically, you can just count the instructions (good experience anyway, to work out how stuff really works). There was a thread only a few weeks ago, and at the time, I simply did this (opened the .lst file, and counted how many instruction cycles were used by the output instructions, and the loop), and trimmed the value I posted. If you were dealing with code with hundreds of instructions, then the easiest route really, is just to use the 'stopwatch' in the MPLAB simulator, but for this loop, with only a handfull of instcutions involved, a manual count is almost as easy.
Best Wishes |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
