add a real time clock to the pi-parport board

[garlick]

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]

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]

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]

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]

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]

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]

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]

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]

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?

[quorten]

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.