Odd Time of Day Reported with Ticker
Sebastian Huber
sebastian.huber at embedded-brains.de
Tue Jan 19 15:15:58 UTC 2016
On 19/01/16 16:08, Joel Sherrill wrote:
>
>
> On Tue, Jan 19, 2016 at 8:57 AM, Sebastian Huber
> <sebastian.huber at embedded-brains.de
> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>
>
>
> On 19/01/16 15:39, Joel Sherrill wrote:
>
> The tasks are delaying 500, 1000, and 1500 ticks with
> nanoseconds_per_tick = 10000000. Delay operations are
> guaranteed to be a minimum of the requested amount and this is
> not being honored.
>
>
> For the ticks based services this is not true, you wait to the
> n-th tick. If you are 1ps before it, you wait 1ps + interrupt
> processing time.
>
>
> That is not how the original requirements for RTEID were written:
>
> https://ftp.rtems.org/pub/rtems/people/joel/RTEID-ORKID/RTEID-2.1/merged/
>
> See page 65 for tm_wkafter. Quoting:
>
> "If the system clock frequency is 100 ticks per second, and the
> requester wants to wait for 2 seconds, then the input parameter will
> be 100*2, or 200 ticks."
>
> I think you have to add 1 internally to all "ticks" based operations
> to ensure this requirement is met.
If you add 1, then you have a potential integer overflow. How was it
implemented in RTEMS v1? I guess this problem existed also in this version.
--
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.
More information about the devel
mailing list