On 19/01/16 16:08, Joel Sherrill wrote:
On Tue, Jan 19, 2016 at 8:57 AM, Sebastian Huber
<sebastian.hu...@embedded-brains.de
<mailto:sebastian.hu...@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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
