I've been playing with the AVR XMega controllers on another project and I've decided to try replacing the ATTiny841 with one.

The only issue with the clock as it is today (and you can argue how big a deal it really is) is the latency between the rising edge of PPS from the GPS module and the display update. With the current design, that latency is on the order of 180 µs. About half of that latency is interrupt processing time, and the other have is the SPI transactions with the MAX6951. AVR SPI systems have a maximum clock speed of half of the system clock, so both sources of latency can benefit from an increase in system clock speed, but it's conceivable that the XMega instruction set might improve the efficiency. The only way to know is try. But since the XMega can run at 32 MHz instead of 8 MHz, so even the SPI portion of the latency can be reduced from ~90 µs down to just ~22.5 µs (the resulting SPI clock will be 16 MHz - well under the ~25 MHz maximum of the MAX6951). It's entirely possible when all is said and done that the final latency may be 40 µs or perhaps less.

The ATXMega32E5 comes in a TQFP-32 package - same size as an ATMega328 - and has a UART (actually, more than 1) and an SPI interface, so it's perfectly equipped for this job.

Of course, since the chip runs at 32 MHz, it's entirely possible that we might attempt to do away with the MAX6951 and just use the two 8 bit ports directly to multiplex the displays directly. But that's going to have to wait for another iteration.