Search the Community
Showing results for tags 'scope'.
Found 1 result
-
I've written a 7-segment refresh routine that runs every 2 millis at the beginning of loop(). It starts this way: void loop() { CURmillis = millis(); if ((CURmillis - PREVmillis) > 1) { // 2ms refresh period = 71 Hz per segment digitalWrite(18,HIGH); PREVmillis = CURmillis; // Turn the current segment OFF while making changes - prevents ghosting digitalWrite(SEGARRAY[SEGCOUNT], SEGOFF); The digitalWrite to pin 18 has been added so I can measure how long the refresh routine takes to run. Pin 18 is turned off as the last instruction in loop(). So the idea is to put my scope on pin 18, and see how much time the routine takes to run, and make sure there's no chance of an overrun. The good news is that the routine runs in about 25 uSec, so it will never overrun the next milli. But the bad news is that the scope shows that millis do not occur regularly. Pin 18 generally triggers the scope at 2 ms intervals, but there are occasional triggers at other points. I can't tell if the extra triggers are early or late, but they never go away. When I did this test on the assembler version of this code, with the Watchdog timer in interval mode, and the clock running at 1 MHz, the pin 18 triggers are absolutely regular. So Energia is doing something in the background that's causing this behavior. Of course it has to execute whatever is done to update the millis value, but I can't iimagine that this would take much time. But I guess there could be some "beat" in the interaction of the background millis interrupt and the loop() execution frequency. Is there any way to get rid of this millis flutter? Is it possible to hook into the interrupt that Energia uses for millis? If so, I could put my routine into the ISR, and loop() would be empty.
