Por qué el led parpadea en lugar de seguir encendido atmega8

Escribí un código de muestra muy simple en mi atmega8 a través de avrstudio aquí está:

#include <avr/io.h>

#ifndef F_CPU
#define F_CPU 1000000UL
#endif

int main(void)
{
    DDRC = 0xff;
    while (1)
    {
        PORTC = 0xff;
    }
    return (0);
}

Espero que todos los pines de PORTC proporcionen un voltaje alto (también conocido como 5v) para que el LED se mantenga encendido (todo el tiempo), pero el resultado es que todos los pines de PORTC reciben una onda cuadrada de 160 Hz con un alto voltaje de alrededor del 25 %. .

ingrese la descripción de la imagen aquí

Para el registro, el bit de fusible se estableció como: [Bajo: E1Alto: 99] y sin cristal.

Entonces, ¿cuál será el problema?

EDITAR

La salida de avrdude con la que subo el HEX al chip:

avrdude.exe: set SCK frequency to 32000 Hz
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude.exe: Device signature = 0x1e9307
avrdude.exe: NOTE: "flash" memory has been specified, an erase cycle will be performed
             To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: set SCK frequency to 32000 Hz
avrdude.exe: warning: cannot set sck period. please check for usbasp firmware update.
avrdude.exe: reading input file "C:\Users\ximing\Documents\Atmel Studio\6.2\GccBoardProject1\GccBoardProject1\Debug\GccBoardProject1.hex"
avrdude.exe: writing flash (68 bytes):

Writing | ################################################## | 100% 0.10s

avrdude.exe: 68 bytes of flash written
avrdude.exe: verifying flash memory against C:\Users\ximing\Documents\Atmel Studio\6.2\GccBoardProject1\GccBoardProject1\Debug\GccBoardProject1.hex:
avrdude.exe: load data flash data from input file C:\Users\ximing\Documents\Atmel Studio\6.2\GccBoardProject1\GccBoardProject1\Debug\GccBoardProject1.hex:
avrdude.exe: input file C:\Users\ximing\Documents\Atmel Studio\6.2\GccBoardProject1\GccBoardProject1\Debug\GccBoardProject1.hex contains 68 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 0.07s

avrdude.exe: verifying ...
avrdude.exe: 68 bytes of flash verified

avrdude.exe: safemode: Fuses OK (H:FF, E:99, L:E1)

avrdude.exe done.  Thank you.
¿Hubo algún problema con la programación?
@BattleHamster Gracias por el aviso, pero las cosas parecen funcionar bien para mí, publico el resultado del avrdude en la sección EDITAR, échale un vistazo.
¿Los chips Avr tienen un perro guardián que debe desactivarse, como los chips msp430? Creo que el chip se está reiniciando, colocando los pines en la entrada predeterminada alta z antes de ejecutar su código, luego enjuague repetir
También creo que puede ser el perro guardián. Los fusibles altos configurados en 0x99 tendrán habilitado el perro guardián, así que supongo que se está reiniciando ...
@Passerby ¡Sí! ¡Desactivé el perro guardián y ahora las cosas funcionaron como se esperaba! gracias, deberías publicar tu consejo como respuesta si no molestas demasiado: D

Respuestas (1)

Como se confirmó en los comentarios, el AVR tenía un temporizador de vigilancia que debe ser acariciado o puesto a dormir. Sin esto, el perro guardián hará su trabajo debidamente y restablecerá el microcontrolador una vez que transcurra el tiempo. Esto da como resultado que el AVR establezca sus pines en su estado predeterminado, que suele ser un estado de entrada Z alto. Esto explica el encendido y apagado de los pines que vio OP.

Por qué el led parpadea en lugar de seguir encendido atmega8
RespuestasAquíPolítica de privacidad1y, 0v