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