Some more thoughts (sorry I drop emails as I read code, I could sum up in a
final email, but I tend to forget things then...)
-- sample code
var byte alarm_period = 0 -- alarm-period, init: 0
I understand it's used to set the alarm period when repeating. I read this
as: "don't use period", but it's actually "period is 1/2s", isn't it ?
You've defined nice constants for this:
const byte RTC_ALARM_PERIOD_HALF_SECOND = 0b0000
const byte RTC_ALARM_PERIOD_SECOND = 0b0001
const byte RTC_ALARM_PERIOD_10_SECONDS = 0b0010
const byte RTC_ALARM_PERIOD_MINUTE = 0b0011
const byte RTC_ALARM_PERIOD_10_MINUTES = 0b0100
const byte RTC_ALARM_PERIOD_HOUR = 0b0101
const byte RTC_ALARM_PERIOD_DAY = 0b0110
const byte RTC_ALARM_PERIOD_WEEK = 0b0111
const byte RTC_ALARM_PERIOD_MONTH = 0b1000
const byte RTC_ALARM_PERIOD_YEAR = 0b1001
Why not using a constant, instead of "alarm_period = 0" ? More meaningful...
Also, check ~ line 554:
if (kbd_count > 0) then -- alarm clock prepared
rtc_set_alarm_hhmmss_bcd(nalarmtime) -- store new
alarmtime
rtc_pin_signal(RTC_PIN_ALARM) -- output: alarm signal
rtc_set_alarm_repeat(alarm_repeat) -- blinks
rtc_set_alarm_repeat(RTC_ALARM_PERIOD_DAY)
rtc_set_alarm(true) -- activate alarm function
else
you're calling rtc_set_alarm_repeat() twice, the second time with a period
constant: rtc_set_alarm_repeat(RTC_ALARM_PERIOD_DAY).
Maybe rtc_set_alarm_period(RTC_ALARM_PERIOD_DAY) ?
Quick read, I may have mistaken/misunderstood...
Cheers,
Seb
2011/4/5 Sebastien Lelong <[email protected]>
> Hi again,
>
> It seems there's something wrong in the sample, when setting alarmtime:
>
> var byte*3 alarmtime = 0x003007 -- actual alarmtime, init:
> 07:30:00
> rtc_set_alarm_hhmmss_bcd(alarmtime)
>
> But:
> -- input: hour-minute-second in bcd format
> procedure rtc_set_alarm_hhmmss_bcd(byte*3 in hhmmss_bcd) is
>
> So, to set alarm @ 7h30 and 0 seconds, I would have:
>
> var byte*3 alarmtime = 0x073000
> rtc_set_alarm_hhmmss_bcd(alarmtime)
>
>
> In doc, you say:
>
> -- PICs use little endian notation (store multi-byte variables with
> -- low order byte first)! So when you want to set the date to 10:07:28
> -- you must specify:
> -- rtc_set_yymmdd(0x280710) -- 'reversed' sequence!
>
> Then why not naming the procedure rtc_set_ddmmyy(0x280710)
>
> (btw, you're setting time -- 10:07:28 --, not date in this example --
> calling rtc_set_yymmdd() --)
>
>
>
> Also, you should take another date than 10/01/01 in sample, because
> depending on the country habits (locale), it can be read:
>
> - January 1st 2001
> - October 1st 2001
> - and even January 1st 2010
>
> A little bit confusing, isn't it ? April 23rd 2011 is a good one, you can't
> get confused: 04/23/11 or 23/04/11.
>
>
> Cheers,
> Seb
>
>
> 2011/4/5 Sebastien Lelong <[email protected]>
>
>> Hi Rob,
>>
>>
>> 2011/4/5 Rob Hamerling <[email protected]>
>>
>> OK with me. But I would like to make a distinction between this builtin
>>> module and external or software RTCs. So I think I'll rename it to
>>> 18f26j11_rtcc_kbd_lcd.jal
>>>
>>
>> Then you should add "hardware" somewhere, because currently you can't know
>> if it's builtin or not (rtcc: real time clock/calendar)
>>
>> 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.
