If you get to choose, which type of RTC chip would you prefer to use? - Page 1
Forum section: electronics / projects

author: technix
author_rank: Super Contributor
timestamp: February 04, 2020, 06:24:35 am
content: I have been using RTC chips in projects, and so far I have seen two types of those: most chips uses a calendar representation internally, and from time to time there is a chip that uses a binary counter as RTC. Which type do you prefer?In my opinion I would prefer a binary counter, as it allows me to use UNIX time directly on it, without any regard to nuances like time zones, leap seconds etc. This also allows easy use with various library functions since the RTC returns time_t directly.

author: AndersJ
author_rank: Frequent Contributor
timestamp: February 04, 2020, 07:09:14 am
content: I appologize for hijacking your thread,but I can’t resist now that you mention ”time_t”.Assuming you refer to the time type in C,what is the correct/preferred way to interfacethe RTC to the C library that uses time_t?

author: RoadRunner
author_rank: Frequent Contributor
timestamp: February 04, 2020, 07:13:05 am
content: Quote from: technix on February 04, 2020, 06:24:35 amI would certainly prefer binary for the same reason you mention. It allows UNIX time stamp which make its really easy to handle with standard lib functions. When I implement a firmware with those old BCD RTC I always handle time as Unix time stamp throughout the system and just convert into UNIX time stamp and back only by two function on the driver layer. So if I have binary RTC it would save hassle of fetching BCD and getting time stamp outof it.From where I see those old BCD RTC were initially meant for dumb digital clocks and for system who have really low processing power. Firmware or digital logic would have directly fetch date and time and without any calculation would have put onto a dumb display.I would still not touch any STM32 mcu though.Regards

author: magic
author_rank: Super Contributor
timestamp: February 04, 2020, 09:51:16 am
content: Those "smart" RTCs are used in PC computers and have problems with tricky edge cases like time zones, leap seconds and DST. Any sophisticated software still needs to know a thing or two about timekeeping and correct the RTC's internal logic every now and then.I like the UNIX system of counting time in seconds and only converting to calendar date for UI purposes.

author: iMo
author_rank: Super Contributor
timestamp: February 04, 2020, 09:56:19 am
content: QuoteDS3231SN

author: nctnico
author_rank: Super Contributor
timestamp: February 04, 2020, 10:00:45 am
content: One thing to look out for is that your RTC supports dates beyond 2038. A 32 bit counter may be of use if you can use it unsigned otherwise your gadget will run into trouble in less than 20 years.

author: NivagSwerdna
author_rank: Super Contributor
timestamp: February 04, 2020, 12:06:00 pm
content: To date DS3231 but I feel I shouldn't. Really depends on the uP part you are using.

author: Gribo
author_rank: Frequent Contributor
timestamp: February 04, 2020, 07:50:55 pm
content: A GPS module.

author: technix
author_rank: Super Contributor
timestamp: February 04, 2020, 08:07:29 pm
content: Quote from: AndersJ on February 04, 2020, 07:09:14 amFor a RTC chip that is internally a binary second counter, that counter is time_t directly. If it is the calendar type, you get a struct tm out of the RTC and has to convert that to time_t.

author: TomS_
author_rank: Frequent Contributor
timestamp: February 04, 2020, 08:09:53 pm
content: For me it would depend on the project.Im working on a project right now and using a DS1306 which presents BCD values. In this case I would not want something that returned a UNIX timestamp like value, since handling that in 8 bit assembly would be a pain in the .....For my project I only need to read the hour, look up a value in a table, and do something based on that value. So BCD is much more preferable for me in this case.

author: technix
author_rank: Super Contributor
timestamp: February 04, 2020, 08:16:27 pm
content: Quote from: Gribo on February 04, 2020, 07:50:55 pmThis has a high power draw, and requires signal reception though.Quote from: nctnico on February 04, 2020, 10:00:45 amIt is very doable to detect the overflowing and use some battery-backed SRAM to provide a few extended bits. Then for the internal code sign extend that into a 64-bit signed time_t. Even a 40-bit UNIX timestamp won't overflow before the devices cease to function if started now.

author: ejeffrey
author_rank: Super Contributor
timestamp: February 04, 2020, 10:21:20 pm
content: The only reason I can think for wanting a BCD counter is if you were just using it to drive a display with minimal logic. If you want to do any timekeeping duties in a microcontroller it seems like keeping a binary timer and converting to the appropriate format for IO makes more sense.

author: aix
author_rank: Regular Contributor
timestamp: February 05, 2020, 06:34:37 am
content: Quote from: nctnico on February 04, 2020, 10:00:45 amWith respect, that's not necessarily true. It all depends on how the code that receives that (potentially negative) number chooses to interpret it. If the OP is the person writing that code, they potentially have quite a bit of leeway here. (It could be as simple as casting the signed number to unsigned.)

author: NivagSwerdna
author_rank: Super Contributor
timestamp: February 05, 2020, 04:36:50 pm
content: FWIW one advantage of having a separate time keeper is that it keeps time even when the main uP is unavailable... specifically during firmware update... depends on your requirements I guess.

author: nctnico
author_rank: Super Contributor
timestamp: February 05, 2020, 04:51:02 pm
content: Quote from: aix on February 05, 2020, 06:34:37 amBut this can get problematic when you need to add or subtract time. Nowadays I like to avoid working with unsigned numbers. The advantage of using an (signed) 64 bit integer is that you can keep the time in milli-seconds.

author: Marcus Bockting
author_rank: Newbie
timestamp: May 11, 2020, 09:04:42 am
content: I would use the RV-3028-C7.It has a UNIX counter and a BCD counter. So you can use it with both architectures.Advantage of signed numbers is, that you can calculate with early dates like January 1st 1874.That could be solved in the application of course like already proposed by aix. The handling of times before 1970 is not everywhere needed.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 11, 2020, 01:17:04 pm
content: It would depend on the project really.Sometimes all you need is local date/time in a simple way, and especially on small targets, you don't necessarily want to bother fiddling with code that implements going from binary to calendar and conversely, you may not have access to a working and *non-bloated* library that does so correctly, you don't want to have to deal with potential bugs, etc.And OTOH if you're using some kind of embedded OS that already has everything to do this, binary would be more adapted. Just a thought.I for one have never used standard time functions on small targets, I'd be curious to see how often they are available, if so, what's the code size, if they are 100% bug-free, etc.

author: hans
author_rank: Super Contributor
timestamp: May 11, 2020, 01:23:35 pm
content: I like the counter modes.Besides RTC standing for real-time clock; it's also in essence a low-power timer. Being able to have access to a raw tick counter of a known frequency source allows synchronisation of devices to TDMA schedules and such.Having to do that through a RTCC (e.g. with calender representation) is a mess.Besides, if you're using the RTC for local time tracking, then doing so in a raw fashion is simpler for the embedded code. Complex formatting w.r.t. timezones and leap years can often be done on a PC.

author: splin
author_rank: Frequent Contributor
timestamp: May 12, 2020, 09:43:10 pm
content: Julian Ilett discusses a complaint he had with the calendar types DS1307 and DS3231, starting at 3:00, here:It seems that reading the time from the chip is simple, but the time/date setting is not.

author: SL4P
author_rank: Super Contributor
timestamp: May 12, 2020, 10:37:33 pm
content: DS3231 has never let me down, but I develop a lot of cellular projects, and in that case, I take the cellnetwork time - which is conveniently location aware!

author: Evangelopoulos Panagiotis
author_rank: Contributor
timestamp: May 13, 2020, 07:29:23 am
content: DS3231 is the best for me so far. I've used it in quite a few projects and I've never had a problem with it.

author: Boscoe
author_rank: Frequent Contributor
timestamp: May 13, 2020, 04:45:13 pm
content: My dream RTC would just be a large counter for UNIX time. With this it would have many configurable interrupts for integer increments in the counter (every 30s say) and many alarms. A an interrupt status register would be needed of course. Add in time.h and you can easily convert between UNIX time and a time and date. This would suit applications like my down to the ground as I have quite a powerful MCU that can easily fit the time library. I've implemented the above in an FPGA however it has far too high power consumption.

author: wizard69
author_rank: Super Contributor
timestamp: May 19, 2020, 04:54:01 am
content: The first thing I noticed about that chip is that leap year counting only goes to 2099. Now I might not make it to 2099 but I could see a lot of electronics lasting that long.Quote from: Marcus Bockting on May 11, 2020, 09:04:42 am

author: cgroen
author_rank: Unknown
timestamp: May 19, 2020, 09:47:36 am
content: Quote from: wizard69 on May 19, 2020, 04:54:01 amAlot?