Timers in a task context

[Joel Sherrill]

On Tue, Apr 10, 2018 at 7:20 AM, Matthew J Fletcher <amimjf at gmail.com>
wrote:

> Hi
>
> It would be good to know if rtems_task_self() is expected to return the
> 'TIME' a.k.a rtems_timer_initiate_server() task id, when a timer created
> with rtems_timer_server_fire_after() fires.
>

Yes. The timer server is just a task which runs at a special high priority.


>
> If it is then i will have to make up some work around, as quite a bit of
> code thats coming over from ThreadX depends on, it returning the previous
> 'user' task, not the previous 'system' task.
>
> Personally it does feel wrong that the behavior of  rtems_task_self()
> changes behavior depending if you use the timer server or not.
>

The ID returned for an ISR based timer function is random. It is the ID of
the thread running when the clock interrupt occurred. It could be the ID of
any thread but assuming your system goes idle, it is more likely to be IDLE
than anything else.

If you want a specific timer instance to send to a specific MQ, then use
the void * argument to pass in information which guides the timer instance.

The timer examples in examples-v2/led pass in the id of the timer instance
to have two timer instances use the same timer service routine.

You could do something similar. Pass in a MQ id or the pointer to a
structure with the required information.

--joel


>
>
>
> On 10 April 2018 at 10:19, Sebastian Huber <sebastian.huber at embedded-
> brains.de> wrote:
>
>> On 10/04/18 11:11, Matthew J Fletcher wrote:
>>
>>> It looks like a difference in operation to say, for example ThreadX,
>>> who's tx_thread_identify() function is documented similarly "If this
>>> service is called from an ISR the return value represents the thread
>>> running prior to the executing interrupt handler", however in operation in
>>> ThreadX there is no non-service, or raw timer interrupt handler, so it
>>> always returns the previous 'user' threads task.
>>>
>>
>> These timer routines executing in the context of a particular thread look
>> more like a signal. You could use a timer and then send a signal to a task
>> in RTEMS. However, I would not use signals in RTEMS due to their
>> implementation (there is a potential infinite recursion).
>>
>> --
>> 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.
>>
>>
>
>
> --
>
> regards
> ---
> Matthew J Fletcher
>
>
> _______________________________________________
> 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/20180411/05784011/attachment-0002.html>