RTC demo

[FrenkR]

on SDK, there is very little documentation about RTC. system_get_rtc_time() returns counter value. Return value is 32 bit only(uint32), which means that very short period of time elapses before counter restarts.
From test on ESP-03, RTC resolution is approx. 160000 ticks/sec. Hence, it takes 7.45h for counter to restart.
Is there any API where you would set "current" time/reset counters and then get at least 64bit value? is there any callback/interrupt when counter is restarted?
Is there any API where I could set time and retrieve it (on GPIO interrupt) in 0.1sec density(1/100 sec would be even better)?
Rgds,
Frenk

[costaud]

on SDK, there is very little documentation about RTC. system_get_rtc_time() returns counter value. Return value is 32 bit only(uint32), which means that very short period of time elapses before counter restarts.
From test on ESP-03, RTC resolution is approx. 160000 ticks/sec. Hence, it takes 7.45h for counter to restart.
Is there any API where you would set "current" time/reset counters and then get at least 64bit value? is there any callback/interrupt when counter is restarted?
Is there any API where I could set time and retrieve it (on GPIO interrupt) in 0.1sec density(1/100 sec would be even better)?
Rgds,
Frenk

Hi Frenk,
This RTC clock means a low-power counter/timer which can still work during light-sleep and deep-sleep mode. Actually , as long as the 3v3 supply is on , it works.
system_get_rtc_time() returns this RTC( low-power clock indeed) counter value, a relative time.It still counts when the chip is reset by watchdog.
system_rtc_clock_cali_proc() returns a number that represents the equivalent system clock ticks of one RTC clock cycle.
Maybe we should arrange for this 64bit value API

[FrenkR]

where is 64bit API?

[kingfisher]

Maybe we should arrange for this 64bit value API

They are considering..
anyway +1 for me, it would solve also one of my problems

[scargill]

The SDK REALLY needs a proper 64 bit RTC value that can be SET and read. With the likes of LUA and MQTT, it is possible to go off and get a 64 bit TIMESTAMP - we need to be able to set a value that is incremented once a second by an internal system clock - that way we will be able to get the time on powerup and then maintain a simple TIME library - as you might find for example in the Arduino libraries.

I see more and more applications which would require ONLY the ESP board - and so it's vital these can maintain a real time clock.

[ESP_Sprite]

The SDK REALLY needs a proper 64 bit RTC value that can be SET and read. With the likes of LUA and MQTT, it is possible to go off and get a 64 bit TIMESTAMP - we need to be able to set a value that is incremented once a second by an internal system clock - that way we will be able to get the time on powerup and then maintain a simple TIME library - as you might find for example in the Arduino libraries.

I see more and more applications which would require ONLY the ESP board - and so it's vital these can maintain a real time clock.

Erm, why? The ESP probably has internal stuff tied to the monotonic-ness of the timer, which you mess up if you change the time under its nose. If you add some offset to the time, just keep your own 64-bit offset value and add that to the time every time you need it.

[FrenkR]

problem is if you are in deep_sleep mode(CH_PD on GND or folating). RTC is ticking, but your code is not running. So 32 bit RTC will overflow in 7.5h. If timer would be 64 bit, you have more than enough time (many, many years)to check for timer overflow. with 64bit RTC I don't see any need to have real RTC support on chip(as DS1302 is).

[ESP_Sprite]

problem is if you are in deep_sleep mode(CH_PD on GND or folating). RTC is ticking, but your code is not running. So 32 bit RTC will overflow in 7.5h. If timer would be 64 bit, you have more than enough time (many, many years)to check for timer overflow. with 64bit RTC I don't see any need to have real RTC support on chip(as DS1302 is).

If that was a reply to me: No, I understand the need of a 64-bit rtc and I fully agree with that sentiment It's just that setting it (as scargill suggests) seems like a superfluous and needlessly complex feature.

[bojanpotocnik]

Any news about 64-bit RTC, setting RTC resolution and setting RTC value?

[scargill]

If it is of interest, I didn't bother with any of this - I ended up having my ESP boards log onto a server whenever they power up (a Raspberry Pi for now) and they are always sent the time as a 64 bit value which they maintain internally in 1 second callbacks. That allows the boards then to know time, date and I also supply dusk and dawn (minutes from midnight for simplicity). The boards can then work "autonomously" from there up but I update the information via MQTT every day, regardless.

Pete.
http://tech.scargill.net