Hi, I think I've managed to narrow it down,. rtems_task_self() is documented as "If called from an interrupt service routine, this directive will return the Id of the interrupted task.",.. however if you run a timer server and your timer is initiated using rtems_timer_server_fire_after(), then rtems_task_self() will always return 'TIME'.
It does not give the "user" task executing before the 'TIME' task,.. as rtems_timer_fire_after() presumably would. On 9 April 2018 at 18:59, Joel Sherrill <j...@rtems.org> wrote: > > > On Mon, Apr 9, 2018 at 11:54 AM, Matthew J Fletcher <ami...@gmail.com> > wrote: > >> Hi, >> >> Some other operating systems allow a timer be created that will fire the >> associated routine in that tasks context. In rtems timers are either in the >> interrupt or the timer task, either way, not in the context of the task >> that created the timer. >> >> > FWIW I'm not familiar with an OS that does this. Happy to see any manuals > online. > > >> This has caused me some head scratching,. the existing task does >> something like this... >> >> do_bunch_of_stuff() >> { >> forever { >> rtems_message_queue_receive( rtems_task_self () -> rtems_id , >> wait_forever_no_timeout ) >> do_something_with_messages_received(); >> } >> } >> > > I am not 100% sure what you are trying to accomplish but message queues > are independent > objects that tasks/threads block on. You don't pass in the thread id. > Message queues have > their own id returned by the rtems_message_queue_create() call. > > >> >> while another task does,.. >> >> rtems_timer_create(5_seconds, do_bunch_of_stuff() ); >> rtems_message_queue_send( do_bunch_task -> rtems_id, blob1 ); >> rtems_message_queue_send( do_bunch_task -> rtems_id, blob2 ); >> rtems_message_queue_send( do_bunch_task -> rtems_id, blob3 ); >> // etc >> >> of course when do_bunch_of_stuff() gets invoked by the timer, >> rtems_task_self() is not going to magically know the task id to return. >> >> >> Whats the best way to deal with this ?, any method i use (events / >> semaphores, etc) is not going to work because there is already an existing >> "wait_forever" blocking action,.. i presume i would have to change that to >> non-blocking then sample the queue every N ? >> >> >> -- >> >> regards >> --- >> Matthew J Fletcher >> >> >> _______________________________________________ >> users mailing list >> users@rtems.org >> http://lists.rtems.org/mailman/listinfo/users >> > > -- regards --- Matthew J Fletcher
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users