2011/4/6 Rob Hamerling <[email protected]>
>
> When I built my clock, the rtcc library (must be about a year ago) and
> program, I wasn't so interested in the alarm-function. But I wanted to make
> the library complete and added code later in both the library and my
> program.
> I remember that I had to read the datasheet several times and still didn't
> understand the different possibilities and combinations of the alarm
> function parameters (repeat,period,chime,etc.).
> So it may be very well that the library has less functionality than the
> rtcc module itself, or that I made interpretation errors.
>

>From what I can understand:

  - alarm can be set to a specific time
  - alarm can be enabled (it will "ring" when active) or not (it'll just do
nothing)
  - once it's active (ringing), alarm can repeat, several times
  - this repeat is done according to a period (so it'll repeat each half
seconds, each seconds, each minute, etc...), for a given number of time
specifiied by the repeat parameter
  - this repeat parameter is decreased each time the alarm repeats (...)
  - when if reaches 0, alarm is active one last time.
  - then, if chime is 1, repeat counter is rolled over from 0h00 to 0hFF,
making it ring infinitely, until alarm is disabled

So your lib sounds ok to me. rtc_set_alarm_signal(), which acts on chime,
may be renamed in something more meaningful, but "chime" isn't meaningful to
me either... Also, wordings regarding alarm state can be confusing. For me:

  - active: means it's ringing (but libs uses this word for "enabled"
  - enabled: means alarm is programmed.

But that's my point of view...


Another comment: it's not clear when RTCC peripheral is enabled or not. I
understand (from API point of view) rtc_init() actually enable the
peripheral. But reading code, it's also enabled each time _rtc_write() is
called, this means at each RTC setting (rtc_set, ...). User (like me),
could:

rtc_set_date(...)
rtc_set_time(...)
-- then
rtc_init() -- let's go !

Ultimately, user could retrieve date & time from outside (serial comms,
ethernet w/ RTP server, who knows) and get control on when to enable the
module. This is arguable though... One missing procedure would still be one
which actually disable the peripheral...


Cheers,
Seb



cheers,
Seb

-- 
You received this message because you are subscribed to the Google Groups 
"jallib" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/jallib?hl=en.

Reply via email to