Re: [avr-libc-dev] timer.h

[Theodore A. Roth]

On Mon, 30 Sep 2002, Joerg Wunsch wrote:

:) As E. Weddington wrote:
:)
:) > > IMHO, we should drop this file.  It's incomplete enough so i doubt
:) > > anybody is actually using it at all.
:) > >
:) > > Opinions?
:) > >
:) >
:) > Please, drop it.
:)
:) Would anybody here object?
:)
:) > Or, make it totally complete and worthwhile to use.
:)
:) IMHO, it's hard to even make it `complete', since the notion of
:) completeness might vary much between different environments.  Also,
:) newer ATmegas use different names for the bit descriptions.
:)
:) > I'm sure that there would be people interested in
:) > a timer module. If AVRGCC doesn't provide it, they'll have to roll
:) > their own anyway. If AVRGCC does provide it, then it will save
:) > programming time.
:)
:) Well, since all the contained functions are one-liners anyway, i guess
:) the need to rewrite them is not more than just the "programmer's
:) warm-up" before actually starting even the simplest AVR project. ;-)
:)
:) > I have some code that might be a starting point for a timer module.
:)
:) In what sense?
:)
:) I've got a timer module as well, but one that's fairly hardware
:) independent.  I need to polish it up a bit, and will post it here.
:) Basically, it's an implementation for one-shot timers that can trigger
:) a callback function, and that also can be cancelled before they are
:) expired.  (Repeated timers can easily be achieved by re-adding a new
:) timer event within the callback.)  Hardware independence is maintained
:) by simply providing a function timertick() that needs to be called by
:) an actual timer interrupt service.  (In the application i wrote this
:) for, the timer ISR does a bit more than only calling this function,
:) e. g. it fetches the current value of another counter channel into a
:) temporary variable since this action is time-critical.)
:)
:) I intent to at least supply these functions for the "examples" section
:) of the avr-libc documentation.

I like the sound of this. Give the user a documented example/reference
implementation in the dox examples. Explain the pros, cons and gotchas of
using it. With this approach, we take a lower priority stance than the
core library (interfaces like this might bit rot as new devices come out,
but I'd rather have example bit rot than core bit rot), we still add value
(they can cut/paste if they want) and we reduce bloat in the core lib
(always a good thing).

BTW: I'm not too excited about the existing examples in doc/examples.
Those files look a bit random and disconnected. Personally, I think
example should be in it's own subdirectory and completely self contained.
See the (soon to be committed) doc/examples/demo project for a reference.
Also, if all the examples are built at compile time, we _might_ be able
use them for part of test system that Joerg discussed previously.

Ted Roth