On 02/10/2018 08:48, Catalin Demergian wrote:
Hi,
This assert may not be directly related to my issue because I
reproduced it a few times (with RTEMS_DEBUG enabled in the build)
without seeing the assert being hit. What I discovered is that after a
while _Scheduler_priotity_Unblock is not called for my task anymore.
And since _Scheduler_priotity_Unblock calls _Scheduler_Update_heir, my
task will not be set as the heir and no context switch will be made
for it.
My question is why would _Scheduler_priority_Unblock not beeing called ?
The _Scheduler_priority_Unblock() is called by _Thread_Unblock() only if
the thread state changes from not-ready to ready.
rtems_event_send called from my USB ISR calls _Event_Surrender and
that calls _Thread_Unblock
Is there a conceptual problem calling rtems_event_send from an ISR ?
Using rtems_event_send() from an ISR is a standard use case.
I saw there is a rtems_event_system_send function. should I call this
one instead ? what is the difference?
It is a different event set, one for applications and one for the system.
--
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.
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
