RTC without clock?

[lpcware]

Content originally posted in LPCWare by R2D2 on Tue Nov 25 13:14:05 MST 2014
UM10736 Chapter 18: LPC15xx Real-Time Clock (RTC) is talking about Real-Time Clock,

but there are no clock registers ( SEC / MIN / HOUR / DOM / DOW / DOY / MONTH / YEAR)  :quest:  :((  |(

[lpcware]

Content originally posted in LPCWare by CaryDubois on Mon Jun 06 10:00:00 MST 2016
Hi everyone, i used the RTC in many of my projects and as per my experience this kind of RTC is better than the BCD ones. When speaking about efficient code I'd prefered to increment a single integer than passing through all awkward nested if's.
And just only when requiring the BCD format then one should apply the conversion formulae.

[lpcware]

Content originally posted in LPCWare by xavas on Fri May 13 10:11:45 MST 2016
Hi David.

I´m working on it. As soon as I finish I will send you my suggestions.

[lpcware]

Content originally posted in LPCWare by DavidKiryat8 on Wed Apr 13 03:33:21 MST 2016
Does anyone have the c source code which implements the RTC day-month-year along with the correct day of week?
Thanks

[lpcware]

Content originally posted in LPCWare by MarcVonWindscooting on Tue Dec 09 15:34:20 MST 2014

---

Quote: R2D2
It's nearly 2015 here, and I would expect that a chip with 'Real Time Clock' peripheral (released 2014) has clock / calendar registers...

---

That's the price we pay for the increased processing power!  :p
It's too easy for the core to calculate the values you need...

I'm a big fan of 'getting/setting all information in one atomic read/write'. Consequently, I'm a supporter of then new simplified design.
Trading it under a false name wasn't a good idea, though.

[lpcware]

Content originally posted in LPCWare by R2D2 on Sat Dec 06 15:22:25 MST 2014
It's nearly 2015 here, and I would expect that a chip with 'Real Time Clock' peripheral (released 2014) has clock / calendar registers...

Back in the 90s I had to calculated minutes, hours , leap year, day of week... with an 8051  :O  

Today I'm used that RTC peripheral is doing that, so to name this LPC15 timer 'Real Time Clock' is a joke  :((

That's a 'Real Time Counter without clock/calendar function' and unusable, if a Real Time Clock is required...

[lpcware]

Content originally posted in LPCWare by 1234567890 on Sat Dec 06 07:02:26 MST 2014
Of course it depends on the way using the RTC. And usually this changes with the actual application. When you just need an interrupt every 3600 seconds or so 'low level' is the choice. This can be done with a simple timer as well (like this implementation of a RTC...).

But with more complex things or just for convenience (e.g. timestamps) 'high level' is better.
So one should have the choice to select between 'low level' and 'high level'. And therefore LPCOpen should implement this.

Code efficiency is one more theme.

[lpcware]

Content originally posted in LPCWare by fjrg76 on Thu Dec 04 11:28:03 MST 2014

---

Quote: 1234567890
18.4.1Real-time clock
The real-time clock is a 32-bit up-counter which can be cleared or initialized by software.
Once enabled, it counts continuously at a 1 Hz clock rate as long as the RTC module
remains powered and enabled.

Yuk! Back to 1970-01-01. So some functions should be added to LPCOpen.

---

In fact, this kind of RTC is better than the BCD ones. When speaking about efficient code I'd prefered to increment a single integer than passing through all awkward nested if's. And just only when requiring the BCD format then one should apply the conversion formulae. (I do agree that LPCOpen should provide such code just for standardization, 'cause it's not difficult to write our own.)

[lpcware]

Content originally posted in LPCWare by 1234567890 on Tue Dec 02 13:34:41 MST 2014
18.4.1Real-time clock
The real-time clock is a 32-bit up-counter which can be cleared or initialized by software.
Once enabled, it counts continuously at a 1 Hz clock rate as long as the RTC module
remains powered and enabled.

Yuk! Back to 1970-01-01. So some functions should be added to LPCOpen.