On Fri, Nov 1, 2019 at 12:33 PM Gedare Bloom <[email protected]> wrote:
> > On Fri, Nov 1, 2019 at 10:52 AM Mathew Benson <[email protected]> > wrote: > >> So no matter what priority the shell task is initialized as, it preempts >> all other tasks? >> >> No. > But an odd artifact of looking at the status of threads in the shell is that the shell thread has to be **EXECUTING** to do that. Since this is a single core system, it means all other threads are either blocked or ready and have a lower priority. > > With low priority (250) under the default scheduling (fixed priority > round-robin), the shell would only run when higher priority tasks are > blocked. This is typical, and the shell will be preempted when higher > priority tasks are made ready. The "TIME" state indicates your driver task > self-suspended on a timer, e.g., nanosleep or wake_after type call. It > should preempt the shell after the timeout. If it isn't then something is > going strangely. > Yep. > > As Joel hinted, if you're using POSIX threads, then 250 is higher priority > than 235. > But I don't know how this is reported by the command he is using. I recall one command to list Classic API tasks and one for POSIX threads. I don't recall one which lists all but I could be wrong. --joel > > Gedare > > >> On Fri, Nov 1, 2019 at 11:36 AM Joel Sherrill <[email protected]> wrote: >> >>> >>> >>> On Fri, Nov 1, 2019, 11:24 AM Mathew Benson <[email protected]> >>> wrote: >>> >>>> My shell task is set to priority 250. I have another task that I've >>>> set to a priority of 235. When I have the shell in the build, that >>>> priority 235 task appears to pend indefinitely with the shell reporting >>>> state = "TIME" and I don't know where it would be pending. The task is >>>> accessing NOR drivers. But just by running the shell command, releases >>>> that priority 235 task. In fact, any command releases it. Whether its a >>>> valid command or not. But if I remove the shell from the build, everything >>>> is fine. The task doesn't pend. It executes as it should. Did I miss >>>> something in the documentation regarding integration of the shell? Is >>>> there something we are or are not supposed to do when the shell is >>>> integrated? >>>> >>> >>> I'm off today and this is from my phone. >>> >>> TIME should indicate that the task is sleeping. Assuming these are not >>> POSIX thread priority The priority 235 task has to be blocked or the shell >>> task won't run at all. So anytime your shell task runs, the others should >>> be blocked. >>> >>> --joel >>> >>>> >>>> -- >>>> *Mathew Benson* >>>> CEO | Chief Engineer >>>> Windhover Labs, LLC >>>> 832-640-4018 >>>> >>>> >>>> www.windhoverlabs.com >>>> >>>> _______________________________________________ >>>> users mailing list >>>> [email protected] >>>> http://lists.rtems.org/mailman/listinfo/users >>> >>> >> >> -- >> *Mathew Benson* >> CEO | Chief Engineer >> Windhover Labs, LLC >> 832-640-4018 >> >> >> www.windhoverlabs.com >> >> _______________________________________________ >> users mailing list >> [email protected] >> http://lists.rtems.org/mailman/listinfo/users > >
_______________________________________________ users mailing list [email protected] http://lists.rtems.org/mailman/listinfo/users
