The oneshot and free-running OS timers have value even without tickless
mode. But they are not required by the OS. I think you have a complete
BSP without them.
The single timer approach is a lot more difficult. The free-running and
oneshot timers are very easy to program. the first is just a count that
runs forever with no interrupts or events. The second is usually a
count up/down timer with an interrupt either on (1) count up to the
value in some match register, or (2) count down to zero. The interrupt
signals the end of the oneshot interval.
The single timer approach is more complex: You have to have a
free-running timer with an interrupt when the count is equal to the
value in a match register to measure intervals. The match value is more
difficult to calculate since it is relative to the current time and
there is some risk for short intervals of setting the match value in the
"past." That latter error is fatal.
On 3/16/2021 12:54 PM, Sara da Cunha Monteiro de Souza wrote:
Hummm.. I see.
For the tickless implementation with 2 timers it's interesting to have the
<chip>_oneshot.c to help implement the System Interfaces along with the
<chip>_freerun.c.
The 2 timers approach is intended to keep one timer to track time and the
another to drive the events?
What would be the hardware timer requirements to implement the first
approach?
Is the first approach preferable only because it saves more hardware
resources
or is there something else?
Em ter., 16 de mar. de 2021 às 14:49, Gregory Nutt <spudan...@gmail.com>
escreveu:
Most architectures support a timer library. The <chip>_oneshot.c file
is a wrapper around the library that creates an internal one shot
driver. That oneshot does not depend on the onshot driver and can be
used anywhere in the OS architecture-specific code where you need a
oneshot. The <chip>_lowerhalf.c file is another wrapper around the
oneshot implementation that implements the lower half of the oneshot
character driver that is used only by applications. So those are
different things: One is for the OS and one is for applications.
That file structure also used to support the tickless mode. Tickless
mode may be implemented in one of either two ways: With one or two
timers. See https://cwiki.apache.org/confluence/display/NUTTX/Tickless+OS
When tickless mode is implemented with a single timer, it is usually in
a file called <chip>_tickless.c. when it is implemented with two
timers, it is usually implemented in three files: <chip>_freerun.c,
<chip>_oneshot.c, and <chip>_tickless.c. If the hardware can support
the single timer tickless solution, that is a better way to go. In most
cases, the two timer implementations have been converted to one timer
implementations but these two file remain in the directories for the
free-running and oneshot timers, but are otherwise not used for tickless
mode by the OS.
On 3/16/2021 11:12 AM, Sara da Cunha Monteiro de Souza wrote:
Hi all,
I've been working on the oneshot driver implementation for ESP32
and
I've noticed that other chips split the implementation into 2 files:
- <chip>_oneshot_lowerhalf.c
- <chip>_oneshot.c
The second file is not used at all besides the lowerhalf. And the
lowerhalf file seems more like a wrapper for the API that is
in <chip>_oneshot.c.
That stated, is it fine if I keep only the lowerhalf file?
Why the <chip>_oneshot.c was created in the other implementations
instead of only keeping everything on the lowerhalf file?
Thanks in advance for reading it.
My best regards,
Sara
