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
On Fri, Nov 1, 2019 at 12:53 PM Gedare Bloom wrote:
> Hi Chris et al.,
>
> On Thu, Oct 31, 2019 at 12:50 AM Chris Johns wrote:
> >
> > Hello,
> >
> > I would like to announce the start of release snapshots from the master
> branch.
> > A release snapshot will be created on the first day of each
On Fri, Nov 1, 2019 at 12:33 PM Gedare Bloom wrote:
>
> On Fri, Nov 1, 2019 at 10:52 AM Mathew Benson
> 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
Hi Chris et al.,
On Thu, Oct 31, 2019 at 12:50 AM Chris Johns wrote:
>
> Hello,
>
> I would like to announce the start of release snapshots from the master
> branch.
> A release snapshot will be created on the first day of each month. These are
> development snapshots so they can be unstable.
>
Hi Joel,
thanks for your prompt reply and definitive answer. It helps to have clear
boundaries regarding what is feasible or not.
It's taken me a while to get back - I understand that you, Chris and Sebastian
discussed this,
and I recently had a good phone call with Sebastian where we discussed
You found the right threads to follow, and you're right that this is
lacking some documentation. (Patches/Writeups welcome.)
On Fri, Nov 1, 2019 at 10:18 AM Mathew Benson
wrote:
> "SHED" = scheduler_name, but that traces back to:
> name.name_u32 = _Thread_Scheduler_get_home( rtems_thread
On Fri, Nov 1, 2019 at 10:52 AM Mathew Benson
wrote:
> So no matter what priority the shell task is initialized as, it preempts
> all other tasks?
>
> No.
With low priority (250) under the default scheduling (fixed priority
round-robin), the shell would only run when higher priority tasks are
So no matter what priority the shell task is initialized as, it preempts
all other tasks?
On Fri, Nov 1, 2019 at 11:36 AM Joel Sherrill wrote:
>
>
> On Fri, Nov 1, 2019, 11:24 AM Mathew Benson
> wrote:
>
>> My shell task is set to priority 250. I have another task that I've set
>> to a
On Fri, Nov 1, 2019, 11:24 AM Mathew Benson
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
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
"SHED" = scheduler_name, but that traces back to:
name.name_u32 = _Thread_Scheduler_get_home( rtems_thread )->name;
_Objects_Name_to_string(
name,
false,
canonical_task->scheduler_name,
sizeof( canonical_task->scheduler_name )
);
Shelve that one until later...
The task command doesn't appear to be defined there. I found the header in
libmisc/monitor/mon-task.c:rtems_monitor_task_dump_header(). It gets a
little buried in function callbacks from there. I'm trying to trace it
back now, but I recommend the documentation be improved to include what the
cpukit/libmisc/shell/ has many of the entry points for the shell functions.
On Fri, Nov 1, 2019 at 6:39 AM wrote:
> I take it that’s a no on the documentation. Can somebody just tell me
> what these mean or point me where in the code it is? It’s not an easy
> follow.
>
> Sent from my iPhone
>
I take it that’s a no on the documentation. Can somebody just tell me what
these mean or point me where in the code it is? It’s not an easy follow.
Sent from my iPhone
> On Oct 31, 2019, at 13:43, Mathew Benson wrote:
>
> is there any documentation that explains the actual output of the
14 matches
Mail list logo
