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.
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
