http://forums.leaflabs.com/topic.php?id=9141 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:08:08 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=9141&page=2#post-20340 Wed, 17 Oct 2012 21:05:48 +0000 palsor 20340@http://forums.leaflabs.com/ <p>Yes, as gbulmer said, we're trying to avoid the 300ms loop times. Ideally we're hoping for a 20ms loop time.</p> <p>After some experimentation, it looks like the problem is now tied to SD card writes, not to our calls to micros(). I did several experiments, but here are the four that I thought were interesting.</p> <p>1. Running the simple code I posted at the top of the thread without the fix to micros() that gbulmer posted results in occasional long loop times.<br /> 2. Running the simple code I posted at the top of the thread with the fix that to micros() that gbulmer posted results in no long loops.<br /> 3. Running our full code with the fix that gbulmer posted results in long loop times.<br /> 4. Running our full code with the fix that gbulmer posted, but with our SD card writes commented out results in no long loops.</p> <p>Based on that, I'm inclined to believe that at least some of the long loops we were seeing originally were due to the bug in micros(), but now I'm convinced that I don't understand the delays that SD cards throw into the mix. i've started researching the options for DMA'ing data to the SD card, or using other card modes. </p> <p>Anyway, thanks for all the help guys!</p> <p>- Andy </p> http://forums.leaflabs.com/topic.php?id=9141#post-20334 Wed, 17 Oct 2012 07:25:22 +0000 gbulmer 20334@http://forums.leaflabs.com/ <p>crenn - AFAIK, they are not trying to wait for 300ms; the bug seems to give the effect that <code>micros()</code> sometimes takes 300ms to return, rather than a microsecond (or less). They don't want that effect. </p> http://forums.leaflabs.com/topic.php?id=9141#post-20319 Tue, 16 Oct 2012 20:40:45 +0000 crenn 20319@http://forums.leaflabs.com/ <blockquote><p>@crenn, did you have any luck reproducing this? If needed, I could send you our log file so you have some data to look at.</p></blockquote> <p>Unfortunately not, as it's approaching the end of my university semester, I've got a lot of work due this week. I'll most likely be looking into the issue either this weekend or next week.</p> <p>If you're waiting for 300ms? Why not just use millis()? </p> http://forums.leaflabs.com/topic.php?id=9141#post-20308 Mon, 15 Oct 2012 23:14:40 +0000 palsor 20308@http://forums.leaflabs.com/ <p>Yeah, I'll try a few experiments and post back. </p> http://forums.leaflabs.com/topic.php?id=9141#post-20297 Mon, 15 Oct 2012 08:37:12 +0000 gbulmer 20297@http://forums.leaflabs.com/ <p>palsor - would you please post a minimal program that demonstrates the bug?</p> <p>Is the delay of 300ms or 450ms a slow call of micros() or is it where currTime and time differ by a lot?</p> <p>(Would you try (an irrational) thing just to set my mind at ease, and change the name of variable <code>time</code> to prevTime or something just to ensure their isn't a weird clash? The linker should notice, but it should be easy enough to change.)</p> <p>When you say " Interestingly, the instances of getting a 300ms loop occured on a pretty regular interval, with almost exactly 15 seconds between each instance."<br /> How close to 15 seconds is that repetition rate? Could it be closer to 16.8 seconds?</p> <p>Edit: I should have said, 16.8 seconds could correspond to the cycle time of the underlying 24bit hardware SysTick timer, if it were counting at 1us. SysTick and<code>micros()</code> should not be behave strangely at 16.8 seconds (IIRC it should be much faster), but I'm just trying to exclude possibilities. </p> http://forums.leaflabs.com/topic.php?id=9141#post-20290 Sun, 14 Oct 2012 21:50:29 +0000 palsor 20290@http://forums.leaflabs.com/ <p>Well bad news. Even with the fix gbulmer pointed too, and without USB, the problem doesn't seem to be have resolved itself. My friend and I did a pass at logging all of our sensors while driving around his neighborhood. Our loop time is normally between 5ms and 30ms depending on what happens. However, over the course of logging for 10 minutes, we saw 5 instances where our loop time jumped up to 450ms, and 38 instances where the loop time jumped up to 300ms. Interestingly, the instances of getting a 300ms loop occured on a pretty regular interval, with almost exactly 15 seconds between each instance. Any guesses as to what would cause that?</p> <p>@crenn, did you have any luck reproducing this? If needed, I could send you our log file so you have some data to look at. </p> http://forums.leaflabs.com/topic.php?id=9141#post-20266 Thu, 11 Oct 2012 19:50:42 +0000 palsor 20266@http://forums.leaflabs.com/ <p>@higwoshy - Yes, thank you. Work has been all consuming this week so I haven't gotten a chance to try anything, but I'll definitiely try gbulmer's fix first. </p> http://forums.leaflabs.com/topic.php?id=9141#post-20245 Tue, 09 Oct 2012 21:02:30 +0000 gbulmer 20245@http://forums.leaflabs.com/ <p>higwoshy - That is very helpful of you to follow up for the OP.<br /> That result is interesting. I think that implies that the system is so deterministic that the bug is repeatable. Impressive. </p> http://forums.leaflabs.com/topic.php?id=9141#post-20241 Tue, 09 Oct 2012 12:22:43 +0000 higwoshy 20241@http://forums.leaflabs.com/ <p>UPDATE : It was the fix gbulmer pointed to : a systick overflow. Edit file /Developer/MapleIDE.app/Contents/Resources/Java/hardware/leaflabs/cores/maple/wirish_time.cpp and change the code accordingly (this is under OSX, but just look for your maple core and you'll find it). </p> http://forums.leaflabs.com/topic.php?id=9141#post-20224 Mon, 08 Oct 2012 06:22:21 +0000 higwoshy 20224@http://forums.leaflabs.com/ <p>@gblumber : Ah, I should have done the maths first, it was getting late here - I'm not fond of late night maths, even simple stuff. It seemed plausible at the time, a kind of harmonic race condition(?). Nevertheless (curtime-time) is definitely creating large numbers. </p> <p>@crenn : The brackets did seem plausible, but it made no difference. Does the +1 to micros() internal reg happen in two parts? It's not possible to interrupt an addition instruction is it? That would create some obscure bugs if it did. :) I'm guessing the answer is no.</p> <p>@palsor : Yep, I can confirm that changing micros() to millis() doesn't cause any instability.</p> <p>P.S. I'm running this example in RAM - I know that is a source of some obscure bugs. Just tried it in flash memory and it's a lot more stable as in the USB doesn't effect it now, but it still "times out" every 12 seconds. How strange.</p> <p>Anyway, I'll let the experts work it out, over to you guys. </p> http://forums.leaflabs.com/topic.php?id=9141#post-20213 Sun, 07 Oct 2012 21:06:25 +0000 palsor 20213@http://forums.leaflabs.com/ <p>@higwoshy ... Yes, the code I posted was just to demonstrate the problem I'm seeing. The only thing I'll say in addition to what you guys already posted is that if I switch from micros() to millis() and change the delay from 75000 to 75 (due to the change to millis()), then I don't see the problem anymore. That makes me think the problem has to do with micros() rather than the end-of-loop code from libmaple. </p> <p>@higwoshy and gbulmer ... I'll try removing USB from the picture and see if that changes anything.</p> <p>@gbulmer ... Thanks for the link above. I'll try adding in the fix to micros() and see if that changes anything, though I agree that it doesn't look like the bug in the thread you linked to would actually cause the effect I'm seeing. I'm might try playing with the while loop in micros() and see if that causes anything interesting to happen as well.</p> <p>Thanks for the help guys. </p> http://forums.leaflabs.com/topic.php?id=9141#post-20211 Sun, 07 Oct 2012 20:53:20 +0000 crenn 20211@http://forums.leaflabs.com/ <p>I'll run your code tonight to see if I can replicate your results</p> <p>I'd put a bracket around (curTime - time), it shouldn't affect it, but I can't remember some of the priorities in the maths (aka how logic fits into BODMAS) </p> http://forums.leaflabs.com/topic.php?id=9141#post-20210 Sun, 07 Oct 2012 20:05:29 +0000 gbulmer 20210@http://forums.leaflabs.com/ <p>higwoshy - micros() should overflow when an unsigned long overflows. </p> <p>IIRC an unsigned long is 32bits, i.e. a maximum of a little over 4,000,000,000 </p> <p>When used to record microseconds, it should overflow every 4000 seconds, which is a tad more than an hour, not every 10 to 15 seconds.</p> <p>I agree USB is plausibly a culprit. </p> http://forums.leaflabs.com/topic.php?id=9141#post-20209 Sun, 07 Oct 2012 17:35:17 +0000 higwoshy 20209@http://forums.leaflabs.com/ <p>Uh? What is that code meant to do? Replacing the serial print with a togglePin(13) I get a randomly flashing light.</p> <p>Did you mean this?<br /> <pre><code>... if (curTime - time &gt; 75000) { togglePin(13); //SerialUSB.println(&quot;1&quot;); time = curTime; // new bit } ... }</code></pre> <p>Or is your code meant to be a test to show when micros() pauses? Cos I don't think your code does that, more like showing that when you exit the main loop (to loop round again), sometimes it takes longer than others to return. I might be getting the wrong end of the stick. </p> <p>AHH! Ok, got it. Hmmm, try running off battery, as the usb functions can screw timings up. Certainly running your original code with usb connected causes random flashing - disconnecting usb causes a flash every so often as you mention. In fact I altered the code to 375000 and I got a toggle every 11.9 - 12.1 seconds (using a stopwatch, so it might be off by .2 seconds)</p> <p>HOWEVER, changing the code to this to eliminate the maple-main-loop-code,<br /> <pre><code>unsigned long time = 0; void setup() { time = micros(); pinMode(13, OUTPUT); } void loop() { unsigned long curTime; while(1) { curTime = micros(); if (curTime - time &gt; 375000) { togglePin(13); } time = curTime; } }</code></pre> <p>I get a weird effect going on... toggling like mad for 3 seconds then a pause of 9 seconds. Hmmm. 9+3 = 12. A clue I think.</p> <p>My head hurts, I'm going to lie down now...</p> <p>30 seconds later ... It's probably caused when micros() overflows back to zero, causing curTime to be 0 ish and time being a very large number, which overflows again to produce a negative number, which shows up as positive number &gt; 75000 because it's unsigned. Clear? Try changing 375000 to 11375000... And the reason usb causes random flashing? Usb is connected to an expensive Mac which is randomly sending out control signals. Well, not randomly, but you know what I mean.</p> <p>I think you need to write a better test program :) to make sure it is micros() that is the problem and not something else. Try using an audio out. Scopes are nice as well. </p> http://forums.leaflabs.com/topic.php?id=9141#post-20206 Sun, 07 Oct 2012 12:11:19 +0000 gbulmer 20206@http://forums.leaflabs.com/ <p>palsor - there was a bug in micros(), explained here:<br /> <a href="http://forums.leaflabs.com/topic.php?id=1958#post-11383" rel="nofollow">http://forums.leaflabs.com/topic.php?id=1958#post-11383</a></p> <p>So it might be worth checking that you have the fix.</p> <p>But, I don't think that explains the effect you're seeing. </p>