los tiempos de avr-gcc _delay_ms están desactivados; ISP a la culpa?

Acabo de construir un AVRISP con un viejo Arduino Nano (ATmega328p), y traté de flashear un programa de parpadeo simple en un ATmega328 (no picopower). La primera vez que actualicé el programa, todo funcionó muy bien: el intervalo de 1000 ms encendido y 1000 ms apagado fue como esperaba. Sin embargo, cambié el intervalo de apagado a 100 ms y, de repente, el período fue de casi 9 segundos en total: unos 8 segundos encendido y 0,8 segundos apagado. El parpadeo de los intervalos originales de encendido y apagado de 1000 ms resultó en un período prolongado también.

Estoy usando el Makefile de un simple tutorial de parpadeo ; lo único que he cambiado es la designación del puerto y la MCU. Dado eso, creo que el problema radica en mi ISP... pero ¿qué podría causar un éxito inicial y luego una falla repetida? Si necesita más información (encabezado o volcado hexadecimal, etc.), hágamelo saber y estaré encantado de complacerlo.

Respuestas (1)

El problema es que su definición de F_CPUno coincide con el hardware. En los MCU nuevos de Atmel, el CKDIV8fusible (que divide el reloj de la CPU por 8) está programado, así que asegúrese de desprogramarlo si es necesario si aún no lo ha hecho.

¿Una falta de coincidencia de F_CPU no afectaría solo la frecuencia de parpadeo pero no el ciclo de trabajo? El ciclo de trabajo de parpadeo del 50 % cambió a ~90 % después de programar la segunda vez.
@JRobert: "Sin embargo, cambié el intervalo de apagado a 100 ms ..." "... lo único que cambié es el [...] MCU.
Perdona el seguimiento amateur, pero... Seguí tu consejo, y definitivamente parece que F_CPU es el culpable. Desprogramé CKDIV8 y luego configuré F_CPU en 20000000 (m328 funciona a 20 MHz). Sin embargo, ahora parpadea demasiado rápido. ¿Qué hice mal?
Ah, no importa, no generó encabezados limpios. ¡Gracias por el consejo!
@IgnacioVazquez-Abrams: Cierto, me lo perdí.