The loop task indeed needs to run in high priority. I provided a PR for
this.
However, the functionality in up_idle cannot be transferred to the loop
function. This is because:
* Either the loop task will execute, and no one will be able to preempt it.
* Or the loop task will get to sleep, but will never wake-up because it
itself advances the system timer.
The system timer needs another way to run in simulator, better emulating
the interrupt-based behaviour of an actual target.
Any ideas?
On Thu, Jul 21, 2022 at 10:14 PM Xiang Xiao <xiaoxiang781...@gmail.com>
wrote:
> On Fri, Jul 22, 2022 at 12:12 AM Fotis Panagiotopoulos <
> f.j.pa...@gmail.com>
> wrote:
>
> > Here is the actual issue:
> >
> > The timer g_system_timer is updated in the IDLE task.
> > This causes problems, because time is not advancing if the system does
> not
> > have any idle time.
> >
> >
> Ok, you don't enable tickless mode. If you enable it like us, the
> timestamp will reflect the real value even if some thread is busy.
>
> The timer behaves erratically, or just gets stuck.
> > For example, a spin-lock-like structure, as is the following snippet,
> works
> > correctly on a hardware target, but locks-up in sim:
> >
> > while ((clock() - start) < TIMEOUT)
> > {
> > if (foo())
> > break;
> > }
> >
> > I thought that I should move g_system_timer in the loop task, but then I
> > realized that it also runs at SCHED_PRIORITY_MIN.
> >
> > I expect similar problems on other parts of the simulator, in such
> > spin-lock like codes.
> > For example while waiting for serial input, without any sleep.
> > (Practically all cases that are normally served by interrupts).
> >
> >
> > My proposition is to:
> > * Set the loop task to SCHED_PRIORITY_MAX. (I tested it, it works and I
> > don't expect side effects).
> > * Move the remaining logic within the idle task to the loop task.
> >
> >
> > What do you think?
> >
> >
> I think it's fine or better to use the highest priority thread to simulate
> the interrupt.
>
>
> >
> > On Thu, Jul 21, 2022 at 6:56 PM Xiang Xiao <xiaoxiang781...@gmail.com>
> > wrote:
> >
> > > On Thu, Jul 21, 2022 at 11:27 PM Fotis Panagiotopoulos <
> > > f.j.pa...@gmail.com>
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > I am having some issues with scheduling in simulator.
> > > > I noticed that there is a "loop task", that performs various
> > > house-keeping
> > > > tasks.
> > > >
> > > > This task is started with a priority of SCHED_PRIORITY_MIN.
> > > > Is this correct / on-purpose?
> > > >
> > > >
> > > The house keeping work ran in the idle loop before, but since some work
> > may
> > > sleep/wait internally, we have to move them to the "loop task". That's
> > why
> > > we select SCHED_PRIORITY_MIN.
> > >
> > >
> > > > I would expect this task to run on maximum priority, simulating
> various
> > > > interrupt or timer events that an MCU would normally have.
> > > >
> > >
> > > It should be fine to increase the priority of the "loop task".
> > >
> >
>
