A driver for the Epson RX8130CE Real Time Clock, fully featured and 'pure' micropython

[easytarget]

I have written a 'pure' micropython driver for the Epson RX8130 I2C Real Time Clock chip that came with my M5Stack Tab5.

https://codeberg.org/easytarget/rx8130ce-micropython

rx8130ce.py provides init(), datetime() and memory(), methods directly compatible with machine.RTC()

• Setting and controlling alarms + timers and interrupts is handled separately by methods specific to this chip and features.

It supports all the chip features:

• Clock setting and reading; time, date, day of week.
• Setting a countdown timer and/or an alarm for specific min/hr/day combinations.
• • Enabling/disabling their respective /IRQ pin interrupts
• Closely syncing from and to the main machine.RTC() class.
• Hardware features:
• • Enabling backup battery switchover and charge modes for coin cells, rechargables and (super)capacitors.
• • Flagging VDD low volt events, Flagging clock oscillator problems (low battery)
• • Enabling hardware FOUT and /RST pin functions (reference frequency and low-volt reset).
• • Setting an offset to correct clock drift.
• • Enabling 'clock update' /IRQ's every second / minute.

There is a 'interactive demo' for the driver that (frankly) got a bit out of hand.. most chip features are available. It makes a good tool for exploring and testing the chip.

An example; adapted from the README

from time import sleep
from machine import I2C, Pin
# set sda/scl as needed, example below for esp32p4/Tab5
i2c = I2C(sda = Pin(31), scl = Pin(32))

from rx8130ce import RX8130
clock = RX8130(i2c)

print(clock.timestring())

# set a timer for 10s at 64Hz countdown, wait for it, then disable again
clock.timer_enable(count = 640, tsel = 1)
while not clock.timer_interrupt():
  sleep(0.1)
  print('.', end='')
print('\nTimeout: ', clock.timestring())
clock.timer_enable(0)

This gives:

>>> import test.py
Fri, 30 Jan 46, 17:16:06
....................................................................................................
Timeout:  Fri, 30 Jan 46, 17:16:16
>>>

[ekspla]

Because I do not have this device on hand to test your code, these are general comments
regarding RTC/I2C device.

As described in almost all of the datasheets of RTC chips, accessing a continuous
set of registers (e.g. calender, clock) via automatic increment is always recommended.
This applies to your case as well, as described in the application manual (see page 26,
for example).

[easytarget]

via automatic increment is always recommended

My code does this for all reads and the sync write where maximum speed is needed. See _get_time() and sync_from_sys_rtc() which use readto_mem() and writefrom_mem() respecively.

The alternative is to apply the Hold flag (also described in the application manual) and set the registers at your leisure while it is applied. This is what I do for validating new time tuples in init() and datetime().
For these I use the explicit date/time/weekday functions (which do range and validity checking on the inputs, but then update each register individually). And the Hold flag is set during the whole write; but I note that I fail to do this in the demo, or explicitly document it.

So that's a good point; these methods are a holdover from when I started on the driver. I'm going to depreciate the time(), date(), weekday() split functions and fold them into datetime()`, in a way that still checks ranges etc, but then 'holds and modifies' the whole clock register block in a single operation.

• I want to do this in a way that still allows specifying None for a value, implying 'leave as is'.

edit: sorry for editing this a few times, I was thinking it through ;-)

[peterhinch]

Fri, 30 Jan 46, 17:16:06

Fire up the DeLorean...

[KnorkFox]

I want to thank easytarget for his work. Two digits for the year, are not enough, imho. Could someone correct it to four digits?
This is a very precise clock, but really really tiny! Package size… CE：3.2 x 2.5 x 1.0mm

[easytarget]

@KnorkFox The chip itself only stores two digits for the year.. So no; nobody can 'correct it'. Sorry.

My driver does handle centuries; but does that by the user needing to supply it and/or extracting from datetime tuples.

Idisagree about it being very accurate; It's a quartz oscillator without temperature compensation. Accurate to a few seconds per month, no better. There are much more accurate RTC chips available

What is is, is extremely low power; it is a backup chip for systems to hold the time while they are powered off or disconnected from NTP etc. It is not a precision timing device; for those you pay a lot more money.

[easytarget]

I wonder; could the backup superfarad capacitor be replaced by a flux capacitor? probably a bad idea since every time it hits 88mph the time will drift..

[easytarget]

Err; badly offtopic I fear

[easytarget]

So; I just released V2.0.0

The comments from @ekspla and @KnorkFox got me thinking. Writing to the clock now all happens in a single location. And the driver now uses a byte from its free 'RAM' to store the century without needing to supply it at init. It wont get incremented in 73 years, but I wont be there to worry about that.

I also added a 'AscII Clock' demo built using this driver and some fonts + tools I wrote for the framebuffer to render a large format LCD clock in a terminal.

It's silly, but fun. This also works with machine.RTC() if you just change a couple of lines in the init code. It currently uses my repl_1306 console 'display' driver, but can work with any display with an framebuffer driver