The v5 prototype boards haven't yet arrived, but I got an opportunity to test the firmware in advance.

I designed a breakout board for the ATXMega32E5, and they arrived today. After writing the de rigueur LED blink program, I decided to load the code for the v5 GPS clock in and see if I could do some debugging with my oscilloscope.

That worked out better than I had hoped. By triggering on one cathode line and watching one anode line, I could see the display in action. I found and fixed a few bugs in the code and even characterized the performance. The worst-case display update latency for the "0 tenth" update is about 170 µs, which is inside of the 200 µs spec.

To prove this, I modified the code to set an unused pin (C7) high at the end of the capture ISR right after the display buffers were filled with the new time. I added another line to clear that pin later in the main loop (after the first NMEA sentence is received). I then triggered the scope on the PPS output from GPS and sampled that unused pin. That measurement is the processing latency for the capture ISR - that is, the time it takes for the display buffers to have the new time copied into them.

You can see that's around 68 µs. It's a bit jittery, but that's a worst-case.

But to get the worst-case true display update, you have to assume that you just missed the time-slot for the least significant digit and must wait a full update cycle.

To verify how long that takes, you simply trigger on one of the cathode lines and measure the time between adjacent rising edges.

This picture shows activity on one of the anode lines in blue as well. The display update time is, as expected, almost exactly 100 µs - a 10 kHz refresh rate for the display. Again, it's slightly jittery because there are times during the process when interrupts are disabled, and the display update delayed ever so slightly.

So with that, I've validated the operation of the firmware. The only thing left is to verify that the hardware works and that the display looks acceptable.