<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 12, 2016 at 9:05 AM, Sebastian Huber <span dir="ltr"><<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On 12/10/16 15:56, Agostino Mascitti wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
#define CONFIGURE_MICROSECONDS_PER_TIC<wbr>K     4000000 /* That's to make it work. a tick of 1.000.000 gives a periodic action every 1 second (with my machine). So 1 : 1.000.000 = 4 : x => x = 4 / 1 * 1.000.000 = 4.000.000 */<br>
</blockquote>
<br>
I would use 1000 or 10000 for CONFIGURE_MICROSECONDS_PER_TIC<wbr>K. I am not sure if values >  20000 work at all.<span class="im HOEnZb"><br>
<br></span></blockquote><div><br></div><div>It is likely that configuring a large value for microseconds per tick results</div><div>in something that a clock hardware can't properly handle. If the specific BSP's</div><div>device driver doesn't detect that the value isn't within range, it effectively</div><div>results in a random clock tick quantum.</div><div><br></div><div>For example, the old 16-bit counter/timers could often not physically count</div><div>for more than about 30 milliseconds. So any configured value above that</div><div>was not supportable. Whether the specific BSP detected that or not is</div><div>another matter.</div><div><br></div><div>But remember always that the accuracy of timeouts, delays, periods, etc.</div><div>in any OS using a fixed tick is always dependent on the clock tick quantum.</div><div>It sets a minimum on the length of time you can sleep, etc.</div><div><br></div><div>As Sebastian said, it is usually better to have something small. I also add</div><div>that it is better if it is a least common denominator for all your periods and</div><div>you are happy with 1/2 period as average error in all timing. So I tend to</div><div>recommend 1, 5, and 10 millisecond clock tick quantums as starting points.</div><div><br></div><div>--joel</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="im HOEnZb">
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone   : <a href="tel:%2B49%2089%20189%2047%2041-16" value="+4989189474116" target="_blank">+49 89 189 47 41-16</a><br>
Fax     : <a href="tel:%2B49%2089%20189%2047%2041-09" value="+4989189474109" target="_blank">+49 89 189 47 41-09</a><br>
E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brain<wbr>s.de</a><br>
PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br></span><div class="HOEnZb"><div class="h5">
______________________________<wbr>_________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman<wbr>/listinfo/users</a><br>
</div></div></blockquote></div><br></div></div>