Determine timing of two interrupts of AtMega1284p

[donaldhwong]

I setup two RFM69 on INT0 and INT1.  The code works, because I am getting RSSI. 

What I needed to do next is to read PD1 and PD3 and count their difference in reception time. But the code below does not work.  Can anyone help?

Code: [Select]

  unsigned long difference = 0, timeout = 0, distance = 0;
  boolean finished = false;
  boolean oneFire = false;
  boolean twoFire = false;
  long setPoint1 = 0;
  long setPoint2 = 0;

  while ((oneFire == 0) || (twoFire == 0)) {
    if (((PIND & (1<<PD3)) == 0) && !oneFire) {
      oneFire = true;
      setPoint1 = timeout;
    }
    if (((PIND & (1<<PD1)) == 0) && !twoFire) {
      twoFire = true;
      setPoint2 = timeout;
    }
    delayMicroseconds(1);
    timeout++;
    if (timeout > 19000)
      break;
  }
Much oblgied,
Donald

[mklrobo]

  Hello!
Your code;
  unsigned long difference = 0, timeout = 0, distance = 0;
  boolean finished = false;
  boolean oneFire = false;
  boolean twoFire = false;
  long setPoint1 = 0;
  long setPoint2 = 0;

  while ((oneFire == 0) || (twoFire == 0)) {
    if (((PIND & (1<<PD3)) == 0) && !oneFire) {
      oneFire = true;
      setPoint1 = timeout;
    }
    if (((PIND & (1<<PD1)) == 0) && !twoFire) {
      twoFire = true;
      setPoint2 = timeout;
In the two above conditional test, I would assume that onefire and twofire, as well as the PIND,PD3, PD1 may all have the same value at the very start! In this case, all conditionals are met. I have found this to happen when I am using a processor with high speeds, relative to the real world ports it monitors. I think the ATMega1284 is in the speed neighborhood of 16 - 20 MIPS, so it might be a good thing to insure some kind of speed duality check, where permissible.     
}
    delayMicroseconds(1);
    timeout++;
    if (timeout > 19000)
      break;
  }
I would also check the type of variables that you are using. A long can handle a lot of numbers, over 19000, I think. Another variable may suit your needs; I have found some processor "bugs" occur when variables have spill over in the internal registers when certain conditions are met. Just a thought. Good Luck! 

[mklrobo]

  Hello!
I looked up the unsigned long variable value;
Long signed integer type. Capable of containing at least the [−2147483647,+2147483647] range;[3] thus, it is at least 32 bits in size.
An unsigned, is just positive, so no problem there.
This size of number may be more than you want to deal with, in context with your timeout value. I would hope this does not cause register problems.(depending on the "bug" is applicable.) Good Luck!

[donaldhwong]

Thank you, mklrobo, for your quick reply.

I changed all variables to integer.  But the code still does not work.

Any other thoughts.  It is really simple code, very frustrating.

Thank you,
Donald

[mklrobo]

  Wow! this is unusual. I would ask a question, where permissible.....
What kind of compile errors do you get? if any?
I would take this code, and run it in another program, just for that code. Sometimes,
compilers do not always "remember" that you change the code. Also, this "tests"
this part of the code. you will have to interject the timing input, but a small price to
pay. If you run it in another code, like C++, do not make it access a port, just a register.
This way, you can narrow down any unusual port/header calling problems, if any.( I might
try to run this on my turbo C++ compiler, to see what happens.  )
If you run it in another program, and it runs clean, maybe you can port it back into your program
to see what happens. (You KNOW the test would work)
The only other thing I can think of, is the conditional testing. If you got this generically from
some source, it might have to be specialized to the AtMega1284p processor. AVR Studio 6 is
supposed to have cross-platform capability, but I have not had time to test that out. 
Keep me posted, interesting problem....

[donaldhwong]

Hi Again,

Thank you for keeping this in your heart. 

I have just downloaded and compiled under AVR Studio 6.2.

No error.  Sorry to disappoint you.

Perhaps I was reading the registers too soon?  or too late?  After an interrupt, this function was called immediately.  Perhaps I need to delay it for a few microseconds more?

I don't know the inner workings at all.  Though 30 years ago, I was designing CPU.  LOL.

[donaldhwong]

I changed the code to work for two ultrasonic module, it works fine. 

But when I switch it to monitor interrupts coming from two RFM69 module, it does not work, therefore I strongly believe I initiated the action either too early or too late.

Please advise.

[donaldhwong]

Or Perhaps, use the wrong pin.  Perhaps not the interrupt pin.

[mklrobo]

  Awesome! 
It sounds like you have isolated the problem. Now, the "digging" begins.
1> checking the pin, to see what functions/commands can control/manip it....
2> isolate header/commands that may have bugs in it..........
3> isolate time domain problems that may be happening.
This seems to be the next logical options. Once they are exhausted, the trip up the river
gets more interesting, and more interesting.  Good work!