-
Notifications
You must be signed in to change notification settings - Fork 11
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
Comments
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 https://www.digikey.com/en/products/detail/microchip-technology/MCP79410T-I-SN/2486436 So, so close on that one. |
Actually, if we could make an inquiry to get the Raspberry Pi HAT specification (and bootloader code) changed to also support |
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. |
Bigger EEPROM is better, but that also uses the subaddress EDIT: Or maybe it's not easier to wire, just that it's more commonly used. |
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. |
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. |
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. |
Quoth @quorten in #4:
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.
The text was updated successfully, but these errors were encountered: