Hello everyone , I hope you guys can help me out ... I'm gonna try to port
riot to the smaller variations of atmel processors ( I'm thinking atmega16
) .. I'm more of a software guy , I haven't worked with embedded stuff a
lot .. hope you guys help me out ..
Thanks
On 09-Dec-2015 6:21 pm, "Kaspar Schleiser" <kas...@schleiser.de> wrote:
>
> Hey,
>
> On 12/09/15 12:57, ROUSSEL Kévin wrote:
> > 1] Is RIOT OS kernel still *tickless*?
> > Does it mean that there will be an interrupt every microsecond when
> > 'xtimer' is used, or will we still have only an interrupt when a
> > time-related event actually happens (which means RIOT still qualifies as
> > a tickless OS) ?
>
> ("tickless" refers to the scheduler. That said:)
>
> Well, in order to keep the notion of "time" for periods larger than a
> timer register, xtimer has to wakeup whenever the timer register
> overflows in order to count exactly those overflows. At 1MHz accuracy on
> 32bit timers, that's one tick every ~71minutes. On 16bit platforms, it's
> more often.
>
> I would still call that 'tickless' in the former case.
>
> Also, there are plans to remove those wakeups if an RTC/RTT/slow low
> power timer is present.
>
> > 2] Unless I'm mistaken, the 'hwtimer' feature that allowed to use as
> > much 'hwtimer' instances (as the underlying hardware timers could offer
> > counters/comparators is now gone, 'xtimer' being based on an unique
> > (high-resolution) hardware timer onto which every 'xtimer' instance is
> > multiplexed.
> > Can someone confirm me that the previous statement---based on what I
> > understand---is correct?
>
> Remember that xtimer provides multiplexing and wider-than-hardware-timer
> periods on top of 'periph/timer'.
> 'periph/timer' can be used as replacement for hwtimer.
>
> We replaced hwtimer (which abstracted timer hardware) and vtimer (which
> provided multiplexing and long-term timers) with periph/timer and
> xtimer. hwtimer had a "lifo queue", which we dropped in periph/timer to
> keep that interface slim.
>
> Together, they have a much more sane design:
> periph/timer is the slimmest possible abstraction of the different
> hardware timers that we could come up with.
> xtimer adds the timer functionality needed in most systems, like
> multiplexing, long term timers, LPM abstraction, convenience like
> sending message, unlocking mutex, ...
>
> They've been designed from the ground up, with the experience from
> hwtimer/vtimer.
>
> So while still young compared to hwtimer, I think the combination will
> be better suited for all applications compared to the old code.
>
> > 3] 'xtimer' is said to be based on a 1-MHz hardware timer, but does it
> > mean we *really* have a granularity/jitter of the order of the
microsecond?
>
> xtimer tries to offer a usable timer API that allows the use of natural
> time values ("sleep 100 microseconds") on hardware that allows only
> "sleep n timer ticks".
> In order to simplify (and thus make more efficient) the implementation,
> it assumes that the underlying hardware timer runs at 1MHz. (that will
> change soon in some way).
> If 1us accuracy is actually possible depends a lot on the hardware.
>
> If you check the "timer_periodic_wakeup" example, you will see that on
> most hardware (and depending on correct xtimer tuning values) the wakeup
> is extremely periodic (when waking up every second, the jitter is less
> than can be measured with the same timer).
>
> native is a notable example, because when run under Linux, the acuracy
> goes to hell.
>
> A single timer might arrive a little (constant) time late. I've got a
> patch to mitigate that (trigger timer a couple of microseconds early,
> then spin before shooting).
>
> xtimer as of now is only as exact as the underlying timer, so if 1*10^6
> timer ticks are not 1sec, xtimer is doomed.
>
> > Dianel Krebs warned me (during the discussion on PR #4178) that
> > xtimer_usleep() was dependent on the scheduler and the delay for its
> > next context switch, and that consequently, the delay passed as a
> > parameter could suffer for an undetermined and potentially *big* jitter.
> Whenever the timer triggers, if it executes a callback function, the
> time from hardware interrupt until timer execute will be constant
> (unless user code disables interrupts).
>
> If the callback wakes up a thread, there's jitter of a couple
> instructions for the time needed by the scheduler to find the thread and
> set it awake, but that jitter will not nearly approach a microsecond.
>
> There's also a slight delay (timers might trigger a little late), which
> xtimer tries to compensate within the "convenience functions" like
> xtimer_set_msg(). But, there's room for improvement.
>
> > In that case, what kind of jitter can we expect relative to the delays
> > we pass as parameters to the xtimer functions? If this jitter is too
> > high or too hard to predict, the status of RIOT OS as a real-time OS
> > could be put in jeopardy?
> xtimer as is needs some optimization in some corner cases, but if used
> correctly, is very exact with little jitter.
>
> Concerning "real-time os status", xtimer does not offer strong real-time
> guarantees, just as vtimer didn't. Use periph/timer if that is needed.
>
> > Since be able to have fine-grained real-time features is necessary to my
> > work, can someone reassure me about the 'xtimer' module and its
abilities?
> I'm pretty sure xtimer will suit your needs. It can probably used as
> drop-in replacement for hwtimer.
>
> If you need extreme predictability, you should use periph/timer.
>
> What kind of granularity and predictability do you need? Could you tell
> us more about your application?
>
> Kaspar
> _______________________________________________
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
