Warum die LED blinkt, anstatt atmega8 eingeschaltet zu lassen

Ich habe über avrstudio einen sehr einfachen Beispielcode in meinen atmega8 geschrieben, hier ist er:

#include <avr/io.h>

#ifndef F_CPU
#define F_CPU 1000000UL
#endif

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

Ich erwarte, dass alle Pins von PORTC eine hohe Spannung (auch bekannt als 5 V) liefern, damit die LED (die ganze Zeit) eingeschaltet bleibt, aber das Ergebnis ist, dass alle Pins von PORTC eine 160-Hz-Rechteckwelle mit einer Hochspannung von etwa 25% erhalten .

Geben Sie hier die Bildbeschreibung ein

Für die Aufzeichnung wurde das Fuse-Bit wie folgt eingestellt: [Low: E1High: 99] und kein Kristall.

Was wird also das Problem sein?

BEARBEITEN

Die Ausgabe von avrdude mit der ich das HEX auf den Chip hochlade:

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.
Gab es Probleme mit der Programmierung?
@BattleHamster Danke für die Benachrichtigung, aber die Dinge scheinen mir gut zu funktionieren, ich poste die Ausgabe des avrdude im EDIT-Bereich, schau es dir an.
Haben Avr-Chips einen Watchdog, der deaktiviert werden muss, wie dies bei msp430-Chips der Fall ist? Ich denke, der Chip wird zurückgesetzt, indem er die Pins in die Standardeingabe hoch z setzt, bevor Sie Ihren Code ausführen, und dann die Spülung wiederholen
Denke auch, dass es der Wachhund sein könnte. Die auf 0x99 eingestellten hohen Sicherungen haben den Watchdog aktiviert, also schätze ich, dass er zurückgesetzt wird ...
@Passant Ja! Ich deaktiviere den Watchdog und jetzt funktionierten die Dinge wie erwartet! danke, Sie sollten Ihren Rat als Antwort posten, wenn Sie nicht zu viel stören: D

Antworten (1)

Wie in den Kommentaren bestätigt, hatte der AVR einen Watchdog-Timer, der gestreichelt oder eingeschläfert werden muss. Ohne dies erledigt der Watchdog pflichtbewusst seine Arbeit und setzt den Mikrocontroller zurück, sobald der Timer abgelaufen ist. Dies führt dazu, dass der AVR seine Pins auf ihren Standardzustand setzt, der meistens der hohe Z-Eingangszustand ist. Dies erklärt das Ein- und Ausschalten der Stifte, die OP sah.

Warum die LED blinkt, anstatt atmega8 eingeschaltet zu lassen
AntwortenHierDatenschutz-Bestimmungen1y, 0v