Rate Monotonic Manager

[Joel Sherrill]

On Wed, Oct 12, 2016 at 9:05 AM, Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

>
>
> On 12/10/16 15:56, Agostino Mascitti wrote:
>
>> #define CONFIGURE_MICROSECONDS_PER_TICK     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 */
>>
>
> I would use 1000 or 10000 for CONFIGURE_MICROSECONDS_PER_TICK. I am not
> sure if values >  20000 work at all.
>
>
It is likely that configuring a large value for microseconds per tick
results
in something that a clock hardware can't properly handle. If the specific
BSP's
device driver doesn't detect that the value isn't within range, it
effectively
results in a random clock tick quantum.

For example, the old 16-bit counter/timers could often not physically count
for more than about 30 milliseconds. So any configured value above that
was not supportable. Whether the specific BSP detected that or not is
another matter.

But remember always that the accuracy of timeouts, delays, periods, etc.
in any OS using a fixed tick is always dependent on the clock tick quantum.
It sets a minimum on the length of time you can sleep, etc.

As Sebastian said, it is usually better to have something small. I also add
that it is better if it is a least common denominator for all your periods
and
you are happy with 1/2 period as average error in all timing. So I tend to
recommend 1, 5, and 10 millisecond clock tick quantums as starting points.

--joel

-- 
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20161012/67032112/attachment-0002.html>