Open garlick opened 3 years ago
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.
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.
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 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.
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.
Freeing up the I2C connectors and delegating the RTC to a separate board seems to be the best solution, re #64. It also looks like some of the stacking Raspberry Pi RTC HATs would be compatible too.
We can test one off-the-shelf module and document that it is known to work together with pi-parport on the same system. Then, I think that would be sufficient to close this feature as complete.
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.