You are here

Shift left uint64 data type | Cypress Semiconductor

Shift left uint64 data type

Summary: 7 Replies, Latest post by Alex101 on 31 Aug 2016 12:50 PM PDT
Verified Answers: 2
Last post
Log in to post new comments.
Alex101's picture
User
152 posts

Hi everyone

I need some help with the following code.

This code is based on RC5 protocol for Irda communication.
I just take from it the bit time, half bit time and the 36 khz modulation frequency.
The idea is implement a 64 bit infrared link. The two first high byte send to the receiver start with 0xFFFF at MSB and MSB-1.
The emitter is implemented with a regular infrared emitter diode and the receiver with
TSOP38436.
To synchronize I wait for the first high to low transition at Demod_input which is the first clock transition of Manchester encoding.
After a Delay of 0.445 ms I can say that the reading at Demod_Input is "1".
After successive sampling of Demod_Input at intervals of 1.778 ms I would say that I am recovering each bit of payload received.

I can get the code running and I suspect about left shift 64 bits data.

The the scopes' screenshot show the TSOP38436 yellow trace and the inverted output as blue trace.

Thank you in advance for any help.

 

user_1377889's picture
User
10699 posts

Your shifts seem to be ok, at first sight I cannot see that something is wrong.

But:

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.

Way out:

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

or:

  • 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.

 

Bob

Alex101's picture
User
152 posts

Thank you very much Bob

I will try your suggestions

Best regards,

Alex

Alex101's picture
User
152 posts

Hi Bob

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.

Best regards,

Alex

 

 

Magnus Lundin's picture
User
41 posts

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.

/Magnus

Alex101's picture
User
152 posts

Hi Magnus

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.

Alex

 

 

 

Magnus Lundin's picture
User
41 posts

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% .

Alex101's picture
User
152 posts

Hi

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.

 

Best regards,

Alex

Log in to post new comments.