Micros error been fixed? « LeafLabs Garden

LeafLabs Garden » Support » Maple IDE Support

Micros error been fixed?

(12 posts) (2 voices)

Started 4 years ago by bart_dood
Latest reply from gbulmer

bart_dood
Member

Hi folks,

I am working on some firmware that has external interrupts which then times how long between interrupts.
My interrupt function just subtracts the previous micros() time from the current micros() time to calculate the difference. It sets a flag high and thats all.

I've tested this under different speeds (times) and for example it will work with 60 millisecond cycles and outputs the right time difference (around 60,000 microseconds). But then when I slow things down or speed things up, I'll get these weird values, like 900 microseconds on one cycle and then like 40000000 on the next?

I've stripped everything else out my code and it still does this. Is this related to the bug in micros that someone discovered a while back? I'm on version 0.0.12

My variables are all unsigned integers and I don't think I'm having problems with the values rolling over or going negative.
Just can't figure out whats going on....(scratches head).

Thanks for the help

Posted 4 years ago #
bart_dood
Member

I just checked wirish/wirish_time.h on my workstation here at work and the micros() bug is there, I'll fix the bug when I get home and see if it fixes my problem.

I'll report back if it does.

Posted 4 years ago #
bart_dood
Member

Hi Folks, I've done some more checking and testing. I fixed the compiler bug and it didn't make any difference.
I looked at my code more and it seems to be related to the 'CHANGE' on the interrupt, when I have it as 'RISING' the calculation works. I need to figure out whats happening but I think its code related.

Posted 4 years ago #
gbulmer
Moderator

bart_dood - my intall of 0.0.12 still contains the micros() bug we spotted a while ago:
http://forums.leaflabs.com/topic.php?id=1098

Have you got the corrected code installed?

When you say "I fixed the compiler bug" what are you describing?

Posted 4 years ago #
bart_dood
Member

Hi gbulmer/all,

I think I've narrowed the problem down a little. I have 3 external interrupts on pins 10, 11 and 12. They are all set to interrupt on a CHANGE.

If I just have one of the interrupts it seems to work fine, the problem happens when I have two or three. It starts spitting out errors.

When I say I fixed the compiler bug I switched around the line that is in the wrong place in the wiring time file. It didn't make any difference to my problem.

Posted 4 years ago #
bart_dood
Member

Just to add one more thing. If I have one interrupt and I send an ON/OFF signal (from an arduino) to it, it triggers correctly and reports back (via serialUSB) the correct time between pulses, whether change or rising.

However if I have two interrupts in the maple code, even when I am still only sending a signal to the OTHER pin, it still screws up the time. My serialUSB starts sending out screwy numbers. Considering I'm not even sending out a signal to the other interrupt pin this is head scratching.

Posted 4 years ago #
bart_dood
Member

Ok, so I have set my maple code to read each interrupt pin after an interrupt on one of them. The other two are set LOW from the arduino.

Oddly when I read them they are randomly showing HIGH. How can this be? is it some kind of weird cross talk or bounce that is triggering them? They are never set high, always held LOW.

Posted 4 years ago #
bart_dood
Member

Sorry to keep posting. I've found a work around.

It seems when I calculate my velocity inside the interrupt function, it for some reason repeats and calculates it again, sometimes once sometimes twice. This leads to errors in the velocity number.

When I add a flag that only allows one single velocity calc and then this flag gets set false, eventually to be reset elsewhere it does a single velocity calc and no errors.

I've tested it over lots of different speeds of interrupt and it works, zero errors now. I can't understand why this works exactly or why the code would repeat itself seemingly randomly but for now this is a working fix.

Posted 4 years ago #
gbulmer
Moderator

bart_dood - I'm pleased you have a workaround.

Are you reasonably confident that:
a. the USB output isn't upsetting things - could you remove that output (maybe just store a few thousand values into an array)
b. nothing is screwing up the state of the pins - could you put some LEDs on the pins to see what is happeing?
c. is the interrupt being level triggered, rather than edge triggered - that might explain multiple runs of the interrupt routine

Posted 4 years ago #
bart_dood
Member

Hi gbulmer,

I am pretty confident its nothing to do with USB etc. I ran into this problem before I had any SerialUSB prints at all, I only added one to try and diagnose where the problem is.
The pins on my test setup here (on my desk at work) are just wires from the arduino to the maple, nothing more.
I might be able to add some low capacitance caps to ground to iron out signal noise if that is the source of the problem. On the real setup these interrupts are triggered by hall sensors inside a brushless motor.

How can I tell if the interrupt is level or edge triggered? It would still be good to fix this problem without my workaround as I think it will add a little more complication elsewhere in my code.

I've noticed the arduino is also very sensitive when an interrupt is set to CHANGE rather than rising etc, they become extremely jumpy.

Posted 4 years ago #
bart_dood
Member

I'm thinking I might hook an Oscope to the pins and take a look at how clean the signals are. I have access to a nice one here.

Posted 4 years ago #

bart_dood - An oscilloscope would be very handy, especially if it is a storage scope.

I did have a an idea.
Could you just try a dumb test monitoring the lines directly?
This attempts to count the number of pulses on each line:

setup() {
     pinMode(10, ...);  // use the same mode as your existing code
     pinMode(11, ...);  // use the same mode as your existing code
     pinMode(12, ...);  // use the same mode as your existing code

     int count10 = 0;
     int count11 = 0;
     int count12 = 0;

     const int* address10 = bb_perip(GPIOA_BASE->IDR, 4);  // bit band address for pin 10
     const int* address11 = bb_perip(GPIOA_BASE->IDR, 7);  // bit band address for pin 11
     const int* address12 = bb_perip(GPIOA_BASE->IDR, 6);  // bit band address for pin 12

     int state10 = *(address10);    // initialise current state
     int state11 = *(address11);
     int state12 = *(address12);

     for (int i=0; i<1000000; ++i) {  // count pulses as fast as practical
         count10 += (*(address10) == state10)? 0 : 1;   // count if pin 10 changed
         count11 += (*(address11) == state11)? 0 : 1;   // count if pin 11 changed
         count12 += (*(address12) == state12)? 0 : 1;   // count if pin 12 changed

         state10 = *(address10);
         state11 = *(address11);
         state12 = *(address12);
      }

      SerialUSB.print("Pin 10 count = ");  SerialUSB.println(count10);
      SerialUSB.print("Pin 11 count = ");  SerialUSB.println(count11);
      SerialUSB.print("Pin 12 count = ");  SerialUSB.println(count12);
}

I don't know what is happening in your system, but this is a way to remove the event/interrupt mechanism. If the pulses are very fast (sub microsecond, I guess), it might miss some, but otherwise should give numbers which look about right compared to the oscilloscope.

Micros error been fixed?

Reply