Ayuda para comprender el tiempo de ejecución de AVR

Este es un mal enfoque. Idealmente, mediría una gran cantidad de comandos NOP, digamos, un millón, en lugar de solo uno. Creo que es la primera tontería que puedo encontrar. No me sorprendería mucho si su número cambia justo después de implementar ese cambio.

Además, ¿puedes ver el desmontaje de tu código C? Ni siquiera intentaría juzgar el tiempo sin ver exactamente qué código ensamblador se generó a partir de mi código C. Intentaría trabajar hacia atrás desde el ensamblaje para calcular cuál debería ser el tiempo de ejecución (a través del manual del conjunto de instrucciones que encontró). De esa manera, puede ver si la medición del alcance se desvía un poco o mucho. Un poco podría significar que cometiste un error matemático. Muchas pueden significar que una de sus suposiciones es incorrecta.

Verifiqué varias configuraciones de reloj de un ATtiny45 hace un tiempo con el código C a continuación. Aunque no es perfecto con el bucle while, las rutinas de retardo vienen bastante bien optimizadas con las bibliotecas avr-gcc. Llamo al programa '1kHz.cpp'. Verifique con la hoja de datos qué pin exacto genera la onda de bloque.

#include <avr/io.h>
#include <util/delay.h>

int main(void)
{
  DDRB = 0x10;
  PORTB = 0x00;

  while (1)
  {
    PORTB = 0x00; _delay_us(500);  // pin low, then wait
    PORTB = 0x10; _delay_us(500);  // pin high, then wait
  }
}

El truco con el reloj es compilar el código con la configuración de reloj adecuada. En Linux se ve así, pero Windows debería ser razonablemente similar. Como puede ver, el ATtiny45 tiene un reloj predeterminado de fábrica de 1 MHz.

freq=8000000/8
baud=19200
src=1kHz.cpp
avr=attiny45
port=/dev/ttyUSB1

# Compile
avr-gcc -g -DF_CPU=$freq -Wall -Os -mmcu=$avr -c -o tmp.o $src
# Link
avr-gcc -g -DF_CPU=$freq -Wall -Os -mmcu=$avr -o tmp.elf tmp.o
# Convert to Intel .hex (required for my programmer)
avr-objcopy -j .text -j .data -O ihex tmp.elf tmp.hex
# Program the device
avrdude -p $avr -c stk500v1 -P $port -b $baud -v -U flash:w:tmp.hex

Por cierto, experimentar con la configuración del reloj puede bloquear tu dispositivo, así que ten cuidado con los fusibles que configuras o desactivas. El desbloqueo solo se puede hacer con un programador de alto voltaje (que se puede hacer con un Arduino de repuesto).

Si está haciendo un análisis de tiempo en el nivel de instrucciones individuales, ciertamente debe mirar el desensamblado de su programa, o escribirlo en ensamblador en primer lugar. Luego puede saber las duraciones exactas de la hoja de datos contando los ciclos para cada instrucción:

Sin embargo, si solo desea verificar que la frecuencia del reloj principal es correcta, hay una solución más fácil: simplemente genere una salida de baja frecuencia. (De 0,1 Hz a algunos kHz, dependiendo de lo que use para medirlo, un LED parpadeante y un cronómetro pueden ser suficientes). Puede usar uno de los temporizadores de 16 bits para eso, o simplemente usar un bucle con un tiempo ocupado largo. espera, por ej _delay_us(). El tiempo dedicado a los saltos del bucle será despreciable.