http://forums.leaflabs.com/topic.php?id=168 A place to share, learn, and grow... en-US Fri, 22 Jan 2016 00:10:15 +0000 http://bbpress.org/?v=1.0.2 q http://forums.leaflabs.com/search.php http://forums.leaflabs.com/topic.php?id=168&page=2#post-1255 Tue, 14 Sep 2010 14:22:28 +0000 poslathian 1255@http://forums.leaflabs.com/ <p>Go with the newer post. I made a bunch of find &amp; replace style changes to be compatible with the current libmaple and i actually tested that it works - rather than just built it! </p> http://forums.leaflabs.com/topic.php?id=168&page=2#post-1235 Mon, 13 Sep 2010 18:54:44 +0000 crenn 1235@http://forums.leaflabs.com/ <p>No, but I did see this!<br /> <a href="http://forums.leaflabs.com/topic.php?id=121" rel="nofollow">http://forums.leaflabs.com/topic.php?id=121</a></p> <p>I'll look into to it in about an hour. I currently need an I2C bus to talk with a couple of speed controllers. </p> http://forums.leaflabs.com/topic.php?id=168&page=2#post-1232 Mon, 13 Sep 2010 18:46:42 +0000 poslathian 1232@http://forums.leaflabs.com/ <p>did you see this? <a href="http://forums.leaflabs.com/topic.php?id=182" rel="nofollow">http://forums.leaflabs.com/topic.php?id=182</a> </p> http://forums.leaflabs.com/topic.php?id=168#post-1228 Mon, 13 Sep 2010 18:38:14 +0000 crenn 1228@http://forums.leaflabs.com/ <p>Currently only need single master mode (our robot is designed around a single micro, which at this stage I'm hoping to be a Maple although there is a little bit of debating behind the scenes) and a software implementation will work fine for what we need. </p> http://forums.leaflabs.com/topic.php?id=168#post-1226 Mon, 13 Sep 2010 18:33:19 +0000 poslathian 1226@http://forums.leaflabs.com/ <p>days, and yes - software i2c with single master mode only. the hardware i2c with slave and multimaster is weeks. </p> http://forums.leaflabs.com/topic.php?id=168#post-1225 Mon, 13 Sep 2010 18:31:20 +0000 crenn 1225@http://forums.leaflabs.com/ <p>So a couple of weeks away? And is some form of I2C included in that release? </p> http://forums.leaflabs.com/topic.php?id=168#post-1220 Mon, 13 Sep 2010 18:17:30 +0000 poslathian 1220@http://forums.leaflabs.com/ <p>0.0.7 is just a regular incremental release. the "alpha" stuff was referring to our snazzy new IDE (completely redone) for 0.1.0. Well push the 0.0.7 as soon as the last straggling tickets are closed, which are very minor. For example "grep todo in codebase" is currently on the top of the stack ;) </p> http://forums.leaflabs.com/topic.php?id=168#post-1219 Mon, 13 Sep 2010 18:12:27 +0000 crenn 1219@http://forums.leaflabs.com/ <p>The most important question I'd ask is when is an alpha (or beta) of v0.0.7 going to be out! </p> http://forums.leaflabs.com/topic.php?id=168#post-1218 Mon, 13 Sep 2010 17:55:14 +0000 poslathian 1218@http://forums.leaflabs.com/ <p>Ahh, yea I pulled this out of git. I suspect then that this was a known bug in 0.0.6 and someone (bnewbold? iperry? mbolivar?) fixed it - Good! </p> http://forums.leaflabs.com/topic.php?id=168#post-1197 Mon, 13 Sep 2010 14:59:07 +0000 CarlO 1197@http://forums.leaflabs.com/ <p>poslathin,</p> <p>The code for delay and delayMicroseconds distributed with V0.6 is different. I have not been able to get the new delay code to compile, too many dependency changes. I assume the new code will work correctly, but I'll test it when released.</p> <p>CarlO. </p> http://forums.leaflabs.com/topic.php?id=168#post-1185 Mon, 13 Sep 2010 12:21:23 +0000 poslathian 1185@http://forums.leaflabs.com/ <p>hmm, the off by 1 in delay is very interesting: See the implementation:</p> <pre> void delay(unsigned long ms) { uint32 i; for (i = 0; i &lt; ms; i++) { delayMicroseconds(1000); } } void delayMicroseconds(uint32 us) { us *= 12; /* fudge for function call overhead */ us--; asm volatile(" mov r0, %[us] \n\t" "1: subs r0, #1 \n\t" " bhi 1b \n\t" : : [us] "r" (us) : "r0"); } </pre> <p>If delayMicros works, then delay should work. Odd. Perhaps what we should be doing for delay isnt a over delayMicroseconds anyway but instead a delayMicroseconds(1000*ms). This would roll over delayMircroseconds for calls to delay longer than 72 minutes (~4200 seconds, ~4200000 ms), which I think is OK. Or we could bump everything up to long, and add a little more overhead to the microseconds loop. </p> <p>In general, I am a fan that there is so little overhead for delayMicroseconds, only ,72us! Good stat CarlO! </p> http://forums.leaflabs.com/topic.php?id=168#post-1147 Thu, 09 Sep 2010 18:41:17 +0000 CarlO 1147@http://forums.leaflabs.com/ <p>gbulmer,</p> <p>I have a Racal model 1992, 9 digit counter that is stable down to 1ns. I also have a GPS Disciplined timebase that I use when I need high accuracy. I only recorded the digits that weren't dithering on the display. Due to the fact that the delay and delayMicroseconds functions are implemented in software, there is a tiny amount of jitter in the width of the pulse.</p> <p>Carl </p> http://forums.leaflabs.com/topic.php?id=168#post-1145 Thu, 09 Sep 2010 18:14:57 +0000 gbulmer 1145@http://forums.leaflabs.com/ <p>CarlO - very nice piece of work! As the young folks say, "Respect" :-)</p> <p>How are you measuring the pulse width so precisely (6 significant figures)? </p> http://forums.leaflabs.com/topic.php?id=168#post-1115 Wed, 08 Sep 2010 18:03:01 +0000 CarlO 1115@http://forums.leaflabs.com/ <p>Update,</p> <p>I found a small bug in the version of time.c that was released with v0.0.6 that was causing the delay function to delay for an extra millisecond. Now I see that in the code repository the delay functions have already been re-written. I'll try to compile my code with the new delay functions and re-run the tests.</p> <p>CarlO. </p> http://forums.leaflabs.com/topic.php?id=168#post-1113 Wed, 08 Sep 2010 16:04:23 +0000 CarlO 1113@http://forums.leaflabs.com/ <p>So I did some testing on the accuracy of the delay and delayMicroseconds functions. Here are the results:</p> <p>Using this code I measured the width of the pulse</p> <pre><code>void loop() { digitalWrite(Pin, HIGH); // set the LED on delay(100); digitalWrite(Pin, LOW); // set the LED off delay(1); }</code></pre> <p>I measured the following pulse width for each value of delay<br /> <pre><code>Delay Width 100 101.002ms 200 201.005ms 300 301.007ms</code></pre> <p>Then I used this code and again measured the width of the pulse<br /> <pre><code>void loop() { digitalWrite(Pin, HIGH); // set the LED on delay(100); delay(100); delay(100); digitalWrite(Pin, LOW); // set the LED off delay(1); }</code></pre> <p>I measured a pulse width of 303.007ms</p> <p>So for the delay function it looks like you get a delay of 1ms greater than the value passed to the function. (within the accuracy of the crystal) Note that the overhead for the function call etc. is very small compared to the minimum delay value.</p> <p>Then I used this code and again measured the pulse width</p> <pre><code>void loop() { digitalWrite(Pin, HIGH); // set the LED on delayMicroseconds(1000); digitalWrite(Pin, LOW); // set the LED off delay(1); }</code></pre> <p>I measured the following pulse width for each value of delay<br /> <pre><code>Delay Width 1000 1000.72us 2000 2000.77us 3000 3000.74us</code></pre> <p>And then again with this code</p> <pre><code>void loop() { digitalWrite(Pin, HIGH); // set the LED on delayMicroseconds(1000); delayMicroseconds(1000); delayMicroseconds(1000); digitalWrite(Pin, LOW); // set the LED off delay(1); }</code></pre> <p>And measured a pulse width of 3000.93us</p> <p>So for the delayMicroseconds function it looks like you get a the proper delay with an overhead of about 0.1us for the function call etc. and about 0.5us for the function call to turn the pin off.</p> <p>CarlO </p>