I played with the timer registers to change the clock speed and verified that the output pin was toggling at the rate I'd expect. So then it was time to use this to time the display update. When I previously mentioned that I was using Timer0, this was incorrect. I was using Timer1, the 16 bit timer. For timing, I grabbed the timer count before the display loop and then grabbed it again at the end. Subtracting these, I came up with the elapsed counts that the display loop took. I sent this out the serial port. I also inserted a 100 ms delay between updates so that I wouldn't overrun things. Here's a screenshot of the data I received:

The first number is the elapsed count, the second number is the starting count and the third is the ending count. I was at first having some difficultly getting the AVR to do math right,. When it subtracted the the start from the end the result was always the same as the end value. ??? I looked into that a bit, and then it started working. I'm not sure what I did differently.

Anyway, the clock speed is 16 MHz. The above timings were with the clock select bits set to 1/64. So 16,000,000/64 = 250,000 Hz, which is 4 microseconds per cycle. 0.000004 * 35698 = 142.8 milliseconds. That's kind of a long time. I verified that the counter wasn't wrapping around in 2 ways. First, I logged the data into RealTerm, appending a timestamp. The values came in about every 1/4 second. Subtracting the 100 ms delay, that works out to close to 142 ms. Second, I changed the divider to 1/256. At this speed it would take a little over a second to wrap the 16 bit counter, and I was definitely getting my data at faster than once a second.

So 143 ms it is. That's pretty slow. About 7 times per second if that's all I'm doing. But I also need to be receiving data from the GPS, reading the control inputs, and perhaps managing an acceleration or deceleration. Since my cruise control needs 1-2 seconds between button presses, that shouldn't need much processing time or a quick response rate. I'm not sure how long parsing the GPS data will take. I'll need to set up an ISR to read the serial port and place the data in a buffer, but that's probably a good thing to do anyways. And if I can set up interrupts for the control pins, I should be okay.

But this does suggest that I could go another route. I could have one AVR control the display, and another to parse the GPS data and handle the control inputs. I do have a little concern of the length of wire I'll need if I use just one. I want the display to be up in my rearview mirror. But the controls will be down between the two front seats. There's probably at least a 10 ft run between those two. Will electrical noise interfere with the signals from the rotary encoder? I'm pretty sure I couldn't get away with putting the OLED display at the end of a 10 ft long wire and get IIC to work.

While I think through those things, I'm going to move on to parsing the GPS data.