DS3231 on BeagleBone Black with FreeBSD 13-CURRENT exactly 20 h off backwards
Dr. Rolf Jansen
freebsd-rj at obsigna.com
Sun Jul 19 21:12:58 UTC 2020
> Am 19.07.2020 um 15:57 schrieb Ian Lepore <ian at freebsd.org>:
>
> On Wed, 2020-07-15 at 12:15 -0300, Dr. Rolf Jansen wrote:
>>> BTW: the following looks strange:
>>>
>>>
> https://github.com/freebsd/freebsd/blob/b2d136be8c26e5efaf82b7bb25432207a682e250/sys/dev/iicbus/ds3231.c#L526
>>> 6 <https://github.com/freebsd/freebsd/blob/b2d136be8c26e5efaf82b7bb
>>> 25432207a682e250/sys/dev/iicbus/ds3231.c#L526>
>>>
>>> This would add 256 instead of 100 when rolling over the century,
>>> really? On real world systems this will let to a Year-2100 problem,
>>> better we solve this quickly, since the time is running, and 80
>>> years compares to nothing on the geologic time scale :-D
>
> I overlooked this part of your message previously. Actually, the value
> 0x100 is correct because the numbers here are expressed in bcd. So 99
> years is 0x099 and 100 years is 0x100. In practice, all this century
> rollover stuff is moot, because the next century rollover is 2099->2100
> and the datasheet says they only handle leap years correctly through
> 2099.
>
>> DS3231_HOUR_MASK_24HR is definitely wrong, since this prevents the
>> setting of times above 20 h. Reading said data sheet, I am almost
>> sure, that DS3231_HOUR_MASK_24HR must be the same as
>> DS3231_HOUR_MASK_12HR = 0x3f.
>
> Actually, it looks like the entire problem is that I simply swapped the
> values for DS3231_HOUR_MASK_12HR and DS3231_HOUR_MASK_24HR when I added
> those constants. Fixed in r363330.
It does work now. Thank you very much for fixing it that quickly.
I didn't recognize that the century rollover was done in BCD. You are correct of course. Sorry for the false alarm.
Stay healthy!
Best regards
Rolf
More information about the freebsd-arm
mailing list