On Fri, Jul 22, 2022 at 6:58 PM Fotis Panagiotopoulos <f.j.pa...@gmail.com> wrote:
> 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? > > Yes, it's a chicken-and-egg problem, that's why we still keep the timer related stuff in the idle thread. The solution is: 1. Enable the tickless mode, so the caller can get the changing timestamp even if it is in a busy loop. All busy loops we encounter before can be fixed by this method. 2. Move the timer related stuff to the host signal handler by enabling SIM_WALLTIME_SIGNAL( https://github.com/apache/incubator-nuttx/blob/master/arch/sim/Kconfig#L132-L139 ), But since SIM_WALLTIME_SIGNAL is seldom used, you may hit some stability issues. > > 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". > > > > > > > > > >
