I got it Mr Nutt, thanks for the detailed explanation!
Em ter., 16 de mar. de 2021 às 16:04, Gregory Nutt <spudan...@gmail.com> escreveu: > 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 > >>> > >> > >
