[En-Nut-Discussion] NutThreadRemoveQueue clears runQueue to NULL
Matthias Ringwald
mringwal at inf.ethz.ch
Wed Aug 28 12:33:40 CEST 2013
Hi Ole
Could it be that the comment was suggesting to do the timer handing in a separate thread instead as part of the thread context switch? By this, many of the restrictions might go away (printf could be used, etc..) And maybe the comment was about starting such a thread only if timers are used. I remember reworking the timer implementation "back in the days" (™). If you like, do a svn blame on that comment to see where it came from.
cheers,
matthias
On Aug 28, 2013, at 12:29 PM, Ole Reinhardt <ole.reinhardt at embedded-it.de> wrote:
> Hi!
>
>> Ole> However this would not prevent Philips bug, as the scheduling
>> Ole> appears in the uart write there...
>>
>> It Philips problem a "bug" or documented missing feature?
>
> I understood:
>
> - it is not allowed to use a scheduling function in a timer callback
> - Phillip used printf in the timer callback
> - This lead to an error
>
> I referred to something different:
>
> - The timer demo writes in a comment:
> "It would be great to be able to start a thread here, but
> unfortunately this doesn't work in Nut/OS."
>
> The reason is the same that caused Phillips bug.
>
> My idea was an idea to enhance Nut/OS features by implementing a
> NutThreadCreateAsync that would allow to create new threads in functions
> that does not allow scheduling (like the timer callback, interrupts,
> etc...).
>
> Bye,
>
> Ole
>
> --
> kernel concepts GmbH Tel: +49-271-771091-14
> Sieghuetter Hauptweg 48 Mob: +49-177-7420433
> D-57072 Siegen
> http://www.embedded-it.de
> http://www.kernelconcepts.de
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
More information about the En-Nut-Discussion
mailing list