Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add a real time clock to the pi-parport board #43

Open
garlick opened this issue Nov 11, 2020 · 8 comments
Open

add a real time clock to the pi-parport board #43

garlick opened this issue Nov 11, 2020 · 8 comments

Comments

@garlick
Copy link
Collaborator

garlick commented Nov 11, 2020

Quoth @quorten in #4:

Just wanted to comment, I also really like the idea of an board variant with an RTC on it too. Probably the best way to do this is with a single AVR microcontroller on the ID EEPROM I2C bus that acts as both an ID EEPROM and a RTC: you simply access the proper memory address to read/write the current time register. The 32.768kHz watch crystal clocks an asynchronous timer in the AVR. There would also be a 1-second interrupt pin too... that's important but unfortunately missing from some other Raspberry Pi RTC HATs because the SoC 19.2MHz oscillator has considerable long-term timing instability.

I think an RTC would be a nice thing to tack onto a future board revision. The AVR hack seems a bit elaborate and I think it might be best to avoid doing anything too hackish on the ID I2c to avoid running afoul of the HAT spec. However, I just noticed, apparently raspbian has the i2c-rtc-gpio overlay that allows a number of common i2c RTC chips with kernel support to be driven by a bit-banged i2c port on any(?) GPIO pins, handy since we've used the main one on GPIO2 and 3:

https://www.raspberrypi.org/forums/viewtopic.php?t=187092

Alternatively we could try to free up GPIO2 and 3 in a future board revision.

@quorten
Copy link
Collaborator

quorten commented Nov 13, 2020

For a less hackish solution, the MCP79410T-I/SN chip almost perfectly fits the bill, just that it's internal EEPROM expects I2C subaddress "0b111" instead of "0b000" and it only has 125 bytes of EEPROM. Just barely enough to use for our purposes. It's also supported by i2c-rtc-gpio (mcp7941x). Same 8-pin SOIC package too.

https://www.digikey.com/en/products/detail/microchip-technology/MCP79410T-I-SN/2486436

So, so close on that one.

@quorten
Copy link
Collaborator

quorten commented Nov 13, 2020

Actually, if we could make an inquiry to get the Raspberry Pi HAT specification (and bootloader code) changed to also support 0b111 subaddress, that would allow us to use this chip for that purpose. Might be too much to ask for, but who knows.

@garlick
Copy link
Collaborator Author

garlick commented Nov 13, 2020

How bout this one?

https://www.renesas.com/us/en/www/doc/datasheet/isl12026-a.pdf

512 bits x 8 EEPROM and linux driver

https://github.com/torvalds/linux/blob/master/drivers/rtc/rtc-isl12026.c

Haven't looked much futher than that.

@quorten
Copy link
Collaborator

quorten commented Nov 13, 2020

Bigger EEPROM is better, but that also uses the subaddress 0b111. Come to think of it, Raspberry Pi Foundation probably made a mistake by specifying subaddress 0b000 because 0b111 would be easier to wire on the board with the CAT24C32 EEPROM chip. And I'm guessing it's apparently more common in the industry, which is why there are several RTC chips that use this as the subaddress.

EDIT: Or maybe it's not easier to wire, just that it's more commonly used.

@quorten
Copy link
Collaborator

quorten commented Nov 13, 2020

After doing some looking around, I'd vouch that the MCP794* series RTC chips seem to have the best combination of features, price, availability, accuracy, and compatibility. If we think the integrated EEPROM is moot, we can choose a version without it. Otherwise, DS3231 is touted to be more accurate but it is more expensive and possibly not as easily available.

@garlick
Copy link
Collaborator Author

garlick commented Nov 13, 2020

Yeah it might be best to leave the ID EEPROM alone and go with a dedicated RTC on either the main I2C (changing parport wiring) or using the bit-banged driver mentioned above. I would probably favor rewiring.

@quorten
Copy link
Collaborator

quorten commented Feb 12, 2021

Looking at other options, another approach would be to provide pin breakouts that attach to a stacked board that could provide both RTC and GPS.

@garlick
Copy link
Collaborator Author

garlick commented Feb 12, 2021

Hmm, maybe a nice way to do that would be to add a quiic or grove connector, after freeing up the I2C? Then people could interface with many off the shelf modules?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants