The next task was to use a faster master clock. Many Atmel uCs have a built-in clock or two, but they're either really slow and/or terribly inaccurate. Thus, many people opt to use an external oscillator. In my application, I want to use an external clock (i.e. a 0:5 volt square wave generated elsewhere outside the chip, not by a crystal or resonator). My uC is an Atmel Atmega64M1, which requires me to program 'fuses'* to use an external clock.
...
*This is a relic from eons ago, when small strips of metal were built into the CPU metal masks, and then programmers burned the desired 'fuses' with a high current pulse. Obviously, these were one-time-write, but today the name 'fuse' persists even though they're reprogrammable (they're typically just a dedicated portion in the SLC Flash memory).
...
So I go to program the fuses using a handy online calculator. Afterwards, I'm no longer able to communicate with my uC, but I'm fairly certain it's running because the power consumption has increased by the expected amount (~5 mA), a hint that the faster clock is running throughout the chip now, whereas before it was blocked at the input.
After verifying the external clock met required input specifications, and that the clock was connected to the correct pin, I found the issue: the clock frequency of debugWIRE - the serial interface I used to program the fuses - is a divided down function of the CPU clock frequency. Whereas before the clock frequency was 125 kHz or so, now it was running at 8 MHz (the external clock frequency). Since debugWIRE communicates through the RESET pin (only), and since I had added a 10 nF capacitor to that pin, the serial data was getting corrupted. So I drove up to my shop, took the capacitor off, and was back in business.
Next up I'm going to:
-figure out how to use the PSC PWM output module
-configure counter1 to output a 24 Hz clock, which is used by an exceptionally slow OEM data bus.
-configure interrupts and validate interrupt handling time.
