The question is whether your driver is actually pending indefinitely as you think, or just the shell is running during the small sleeps.
On Sat, Nov 2, 2019, 9:06 AM Joel Sherrill <j...@rtems.org> wrote: > > > On Sat, Nov 2, 2019, 12:03 AM <mben...@windhoverlabs.com> wrote: > >> That’s kind of my point. The low priority shell task is working >> perfectly. The higher priority task is pended by time. I do have some >> sleep functions in the driver code but they are short sleeps. They >> shouldn’t just pens indefinitely until a run any random command in the >> shell. Unless I’m not understanding the priority model correctly and have >> inadvertently inverted my prioritities. >> > > The shell has to be the executing task to run the command and produce > output. It is only running when nothing else is running in your system. But > the reports will never catch another task ready because if it was ready, > the scheduler would pick it to be the executing thread. > > It looks and sounds odd but it is exactly what is supposed to happen. It's > lowest priority and produces output when it runs. > > >> Sent from my iPhone >> >> On Nov 1, 2019, at 14:40, Joel Sherrill <j...@rtems.org> wrote: >> >> >> >> On Fri, Nov 1, 2019 at 12:33 PM Gedare Bloom <ged...@rtems.org> wrote: >> >>> >>> On Fri, Nov 1, 2019 at 10:52 AM Mathew Benson <mben...@windhoverlabs.com> >>> 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 <j...@rtems.org> wrote: >>>> >>>>> >>>>> >>>>> On Fri, Nov 1, 2019, 11:24 AM Mathew Benson <mben...@windhoverlabs.com> >>>>> 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 >>>>>> users@rtems.org >>>>>> http://lists.rtems.org/mailman/listinfo/users >>>>> >>>>> >>>> >>>> -- >>>> *Mathew Benson* >>>> CEO | Chief Engineer >>>> Windhover Labs, LLC >>>> 832-640-4018 >>>> >>>> >>>> www.windhoverlabs.com >>>> >>>> _______________________________________________ >>>> users mailing list >>>> users@rtems.org >>>> http://lists.rtems.org/mailman/listinfo/users >>> >>>
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users