diff --git a/Documentation/reference/os/time_clock.rst b/Documentation/reference/os/time_clock.rst index e47583ce54..823db438f0 100644 --- a/Documentation/reference/os/time_clock.rst +++ b/Documentation/reference/os/time_clock.rst @@ -209,13 +209,13 @@ are, in increasing order of importance: - **Overhead**: Although the CPU usage of the system timer interrupt at 100Hz is really very low, it is still mostly - wasted processing time. One most timer interrupts, there is - really nothing that needs be done other than incrementing the + wasted processing time. On most timer interrupts, there is + really nothing that needs to be done other than incrementing the counter. - **Resolution**: Resolution of all system timing is also - determined by ``CONFIG_USEC_PER_TICK``. So nothing that be time - with resolution finer than 10 milliseconds be default. To - increase this resolution, ``CONFIG_USEC_PER_TICK`` an be + determined by ``CONFIG_USEC_PER_TICK``. So nothing can be timed + with resolution finer than 10 milliseconds by default. To + increase this resolution, ``CONFIG_USEC_PER_TICK`` can be reduced. However, then the system timer interrupts use more of the CPU bandwidth processing useless interrupts. - **Power Usage**: But the biggest issue is power usage. When the @@ -226,7 +226,7 @@ are, in increasing order of importance: greater power consumption. **Tickless OS**. The so-called *Tickless OS* provides one solution -to issue. The basic concept here is that the periodic, timer +to this issue. The basic concept here is that the periodic, timer interrupt is eliminated and replaced with a one-shot, interval timer. It becomes event driven instead of polled: The default system timer is a polled design. On each interrupt, the NuttX @@ -255,18 +255,26 @@ Tickless Configuration Options - ``CONFIG_ARCH_HAVE_TICKLESS``: If the platform provides support for the *Tickless OS*, then this setting should be - selected in the ``Kconfig`` file for the board. Here is what - the selection looks in the ``arch/Kconfig`` file for the + selected in the ``Kconfig`` file for the architecture. Here is + what the selection looks in the ``arch/Kconfig`` file for the simulated platform: + .. code-block:: console + + config ARCH_SIM + bool "Simulation" + select ARCH_HAVE_TICKLESS + ---help--- + Linux/Cywgin user-mode simulation. + When the simulation platform is selected, ``ARCH_HAVE_TICKLESS`` is automatically selected, informing the configuration system that *Tickless OS* options can be selected. -- ``CONFIG_SCHED_TICKLESS``: If ``CONFIG_ARCH_HAVE_TICKLESS`` - is selected, then it will enable the Tickless OS features in - NuttX. +- ``CONFIG_SCHED_TICKLESS``: If ``CONFIG_ARCH_HAVE_TICKLESS`` is + selected, then you will be able to use this option to enable the + *Tickless OS* features in NuttX. - ``CONFIG_SCHED_TICKLESS_ALARM``: The tickless option can be supported either via a simple interval timer (plus elapsed @@ -277,15 +285,15 @@ Tickless Configuration Options The advantage of an alarm is that it avoids some small timing errors; the advantage of the use of the interval timer is that - the hardware requirement may be less. + the hardware requirement may be simpler. - ``CONFIG_USEC_PER_TICK``: This option is not unique to *Tickless OS* operation, but changes its relevance when the - *Tickless OS* is selected. In the default configuration where + *Tickless OS* is selected. In the default configuration, where system time is provided by a periodic timer interrupt, the - default system timer is configure the timer for 100Hz or + default system timer is configured for 100Hz, that is, ``CONFIG_USEC_PER_TICK=10000``. If ``CONFIG_SCHED_TICKLESS`` is - selected, then there are no system timer interrupt. In this + selected, then there are no system timer interrupts. In this case, ``CONFIG_USEC_PER_TICK`` does not control any timer rates. Rather, it only determines the resolution of time reported by ``clock_systime_ticks()`` and the resolution of @@ -342,26 +350,23 @@ platform code must provide the following verify similar functions: - ``up_timer_start()``: Starts (or re-starts) the interval timer. -Note that a platform-specific implementation would probably -require two hardware timers: (1) A interval timer to satisfy the -requirements of ``up_timer_start()`` and -``up_timer_cancel()``, and a (2) a counter to -handle the requirement of -``up_timer_gettime()``. Ideally, both timers +Note that a platform-specific implementation would probably require two +hardware timers: (1) A interval timer to satisfy the requirements of +``up_timer_start()`` and ``up_timer_cancel()``, and (2) a counter to +handle the requirement of ``up_timer_gettime()``. Ideally, both timers would run at the rate determined by ``CONFIG_USEC_PER_TICK`` (and certainly never slower than that rate). -Since timers are a limited resource, the use of two timers could -be an issue on some systems. The job could be done with a single -timer if, for example, the single timer were kept in a -free-running at all times. Some timer/counters have the capability -to generate a compare interrupt when the timer matches a -comparison value but also to continue counting without stopping. -If your hardware supports such counters, one might used the -``CONFIG_SCHED_TICKLESS_ALARM`` option and be able to simply set -the comparison count at the value of the free running timer *PLUS* -the desired delay. Then you could have both with a single timer: -An alarm and a free-running counter with the same timer! +Since timers are a limited resource, the use of two timers could be an +issue on some systems. The job could be done with a single timer if, for +example, the single timer were kept in a free-running mode at all times. +Some timer/counters have the capability to generate a compare interrupt +when the timer matches a comparison value but also to continue counting +without stopping. If your hardware supports such counters, one might use +the ``CONFIG_SCHED_TICKLESS_ALARM`` option and be able to simply set the +comparison count at the value of the free running timer *PLUS* the +desired delay. Then you could have both with a single timer: An alarm +and a free-running counter with the same timer! In addition to these imported interfaces, the RTOS will export the following interfaces for use by the platform-specific interval