[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