Guarantee rtems_timer_server_fire_after() will be 'after' interval

Matthew J Fletcher amimjf at gmail.com
Fri Jun 5 07:28:51 UTC 2020


Replying to myself.

Fetch is from RTEMS commit d2efc968e2f644512062de1e06fab20abd2e6854 (around
2019-10-25)

On Fri, 5 Jun 2020 at 08:24, Matthew J Fletcher <amimjf at gmail.com> wrote:

> RTEMS version: 5.0.0
> RTEMS tools: 7.4.1 20190514 [gcc-7-branch revision
> e394c07a6f0:5dcbdf0fab0:9fe5ced54b87698db3c13994155020ed003cbc7f]
>
> Its not a big problem for the application, we can always check for
> multiple invocations in the same second.
>
> I cant quite believe its a core RTEMS issue, would seem BSP specific.
>
>
> On Thu, 4 Jun 2020 at 23:42, Joel Sherrill <joel at rtems.org> wrote:
>
>> What version Matthew?
>>
>> On Thu, Jun 4, 2020 at 4:24 PM Gedare Bloom <gedare at rtems.org> wrote:
>>
>>> Yes, it should. If not, have to chase down a bug somewhere.
>>>
>>> https://docs.rtems.org/branches/master/c-user/timer_manager.html#rtems-timer-server-fire-after
>>>
>>> On Wed, Jun 3, 2020 at 2:05 AM Matthew J Fletcher <amimjf at gmail.com>
>>> wrote:
>>> >
>>> > Hi,
>>> >
>>> > Does the implementation of rtems_timer_server_fire_after() ensure that
>>> the supplied routine will be called 'after' the interval ?
>>> >
>>> > On my ARMv7M BSP with a 10ms tick and 100 passed as the interval
>>> argument i occasionally (once in 10,00 or so) see the following;
>>> >
>>> > routine called - 0 millis
>>> > routine called - 980 millis
>>> >
>>> > I am using rtems_clock_get_ticks_since_boot() to get the millis
>>> >
>>> >
>>> >
>>> > regards
>>> > ---
>>> > Matthew J Fletcher
>>> >
>>> > _______________________________________________
>>> > users mailing list
>>> > users at rtems.org
>>> > http://lists.rtems.org/mailman/listinfo/users
>>> _______________________________________________
>>> users mailing list
>>> users at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>>>
>>
>
> --
>
> regards
> ---
> Matthew J Fletcher
>
>

-- 

regards
---
Matthew J Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20200605/2d1234ab/attachment.html>


More information about the users mailing list