Your shifts seem to be ok, at first sight I cannot see that something is wrong.
You try resetting the timer using a control register. The reset input is synchronous, so there is a clock l->h transition needed to reset the timer.
Write a function Timer_Reset() that
- stops the timer (in isr_1 interrupt handler to avoid one-shot which requires a reset)
- reloads the timer counter
- starts the timer
- Set the control register output type to "Pulse"
- use a toggle ff to divide the timer_clock by 2 (two) and feed that into the control register clock
- only write a 1 (0x01) to the control register, do not write the 0 (zero)
This will ensure a clean reset of the one-shot timer.
Thank you very much Bob
I will try your suggestions
I have tried your suggestions and sorry but they doesn't seems to be the solution to get the code working.
Please see attached Terminal's screenshot to show you the payload received and you will see that for test payload (0xFFFF007892430000), the code receive OK the first 16 bits.
Regarding those 16 bits, I have a code working with a very similar algorithm and 16 bits payloads which work fine.
With this code I am also using the same TSOP38436 device and without take care about the asynchrony Timer Reset.
I can use that code but isn't efficient , because to send (0xFFFF007892430000), you should send 8 16 bit packet and previously get the Payload's CRC, and at the receiver recover the data byte.
Really I spent almost more two weeks trying to get working this code.
May be you can give me more suggestion I will appreciate them very much.
What main clock source are you using on your sender and receiver ?
It looks to me like the sending and receiving clocks are drifting relative to each others.
One way to check this is to time a sequence of received high to low transitions and measure if they really are 1.778 ms apart as measured by the receiver board.
Thank you by your suggestion.
I'll try that of course.
In my code the half bit which is 889 us and the full bit which is 1,778 us have #defines which allows for 30% tolerance to account differences in timer or other delays.
So those constants set up boundaries to check the Timex variable out regarding those values +/- 30%
Thank you for your help.
If the decoder, starting at midpoint of a halfbit, reads 20 bits correctly, and then shifts to the wrong polarity, a time error of 445uS, the relative timing error is 445uS in 20x1778us = 1.24% .
Yes, Magnus you are wright, it is that you said.
I am working on that.
Also, apparently there is some influence regarding the time interval between the last bit sent and the first bit received with the next packet.
On the TX side I send a packet or Payload every 300 ms.
At the RX side I am capturing a Payload every 150 ms.
After one Payload was received a function wait for input pin be idle (logic "1"), for at least 5 ms to start to start over the whole process .
As a result of wait 150 ms to capture the next Payload, I am getting continuously the correct one but with wrong MSB byte and LSB byte.
I think that what you said is related with this lost of MSB and LSB bytes.
This is just a code to get running the Infrared link.
With the definitive code there will be just a capture every 30 sec.
Then it is a testing code.
So I am working to workout that issue.
I very appreciate very much your interest to help me.