Hello, SIM_WALLTIME_SIGNAL indeed seems the correct option for me, exactly what I need.
Unfortunately, it is not working. The function sim_timer_update() is correctly called on the first signal that the host delivers. Then the simulation crashes during the execution of the function oneshot_callback() in the file nuttx/drivers/timers/arch_alarm.c. I will investigate further... On Fri, Jul 22, 2022 at 3:29 PM Xiang Xiao <xiaoxiang781...@gmail.com> wrote: > 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". > > > > > > > > > > > > > > >
