Estoy teniendo el problema más peculiar. Cuando cambia el tamaño de una matriz global, altera la frecuencia de reloj del ATmega164a. Esto está en Linux. Cuando se compila en Windows, este problema no se produce (independientemente de si el archivo .hex está realmente programado en el ATmega164a en Windows o Linux alias, no creo que avrdude contribuya a este problema). Incluso ejecuté en Linux los comandos exactos ejecutados por AVR Studio para crear el objetivo, y aún encontré este problema.
El fusible CLKDIV8 no está configurado, y el fusible RC interno está configurado, por lo que el ATmega164a debería estar funcionando a 8MHz nominal.
Este es el ejemplo mínimo de funcionamiento del código que se ejecuta correctamente:
#include <avr/io.h>
uint8_t bytes[6];
int main(void){
DDRB = (1<<PB5);
while(1){
PORTB |= (1<<PB5);
PORTB &= ~(1<<PB5);
}
}
Un osciloscopio muestra que el pulso resultante tiene un ancho de 250 ns (2 ciclos).
Sin embargo, aumentar el tamaño de la matriz global en uno da como resultado un comportamiento impar.
#include <avr/io.h>
uint8_t bytes[7];
int main(void){
DDRB = (1<<PB5);
while(1){
PORTB |= (1<<PB5);
PORTB &= ~(1<<PB5);
}
}
Un osciloscopio muestra este ancho de pulso como 444ns, y el tiempo entre los pulsos aumenta en la misma proporción que indica que la frecuencia del reloj ha disminuido.
No tengo ni idea de dónde ir desde aquí. Me tomó mucho tiempo limitarlo a este ejemplo mínimo de trabajo. He pegado mi Makefile en pastebin .
EDIT
Aquí están los archivos de listado para los dos casos. bytes [6]: pastebin bytes [7]: pastebin
He verificado con un temporizador de 16 bits que la frecuencia del reloj está disminuyendo de hecho por el factor anteriormente citado (250ns - > 444ns).