![](templates/subSilver/images/CCSLogo.jpg) |
![CCS C Software and Maintenance Offers](templates/subSilver/images/forumAd6.jpg) |
View previous topic :: View next topic |
Author |
Message |
mash14
Joined: 16 Oct 2012 Posts: 2
|
Problem with signal of tsop1738 in 18f4550 |
Posted: Tue Oct 16, 2012 10:21 pm |
|
|
Hi all,
My problem is simple, I have a TSOP1738 sensor connected to RBO to detect the 33 NEC protocol flanks.
My problem is that it is only possible to detect between 12 and 18 bits of the protocol without knowing about the rest.
data:
My pic 18F4550 is designed to work with the internal clock to 8MHz, this will be the main issue?. ie not mind fast enough to detect all interrupts on time and perform program instructions.
Any reference is welcome since I have three years of experience with microcontrollers and I had never seen this.
Thank you very much.
nec protocol....
http://wiki.altium.com/download/attachments/8749270/NECMessageFrame.png?version=1&modificationDate=1228300890343
(and yes, I use a translator my little experience speaking English sorry ) |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19359
|
|
Posted: Wed Oct 17, 2012 2:42 am |
|
|
8MHz, is plenty fast enough to handle this protocol.
However you probably need to be changing your approach to how you do it.
I's suggest you use a hardware timer.
In the interrupt, you just want to record the _times_ when the edges happen do nothing more complex than this.
Realistically 'ideal' to use the CCP for this, rather than RB0.
Your diagram on the protocol, could well be misleading you, since it only applies to a device with an address of '0'.
The way the protocol works, you will see a rising edge, followed 13.5mSec latter by the next rising edge. This signals the 'start'. I'd reset the timer when this is seen. Rising edges then come at gaps of either 1.125mSec, or 2.25mSec for either a 0, or a 1. A total of 32bits of data, followed by another 0 to mark the end.
If you setup the hardware timer (say timer1, if using the CCP) to use the peripheral clock/4. So Fosc/16.
Then simply record the time when each rising edge is seen. Do one bit of maths. If the delta from the last record is >20000 reset the timer, and set the index to the recording array back to zero.
In the main, wait for the index to reach 32. At this point you have the times recorded for all the edges. _If_ the timer1 interrupt triggers, then you have missed a packet (will happen if you get to 31% after the last bit should have been seen).
Then decode. Two parts to this. Simply go through the first 32 entries of the array of times, to create four bytes. If the delta<900 store a '0', if greater, a '1'. Then invert the second and fourth bytes of the result, and compare these with the first and second bytes. If they don't match there was an error. If they match, you have the data received.
I'd suspect you are trying to do the decode inside the interrupt. If so, time would be very tight indeed, especially when testing for the inverted bytes.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
mash14
Joined: 16 Oct 2012 Posts: 2
|
|
Posted: Wed Oct 17, 2012 1:11 pm |
|
|
Thank you very much, you gave me a very good idea.
and tried to do just this, but with the difference that just try to detect and decode 32 bits.
Ttelmah wrote: |
I'd suspect you are trying to do the decode inside the interrupt. If so, time would be very tight indeed, especially when testing for the inverted bytes.
Best Wishes |
I turned a page and looked where an example, in which I base using timer interrupt and 1 with the difference that uses a 20MHz crystal.
http://picmania.garcia-cuervo.net/experimentos_ir.php
I'll take your suggestions and will try to see what happens, thank you very much. |
|
![](templates/subSilver/images/spacer.gif) |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|