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