AVR Studio Simulator Timer ???

Tobias Gast #361165
Lesenswert?
• ▲
▼ 
Da meine Harware noch nicht fertig ist, arbeite ich zur Zeit mit dem AVR
Studio 4 Simulator. Controller ist der ATMEGA2561.
Ich habe einen 16Bit Timer zur PWM erzeugung Initialisiert und er zählt
auch und zum Compare Match wird der PIN auf High gesetzt. Wie es auch
sein sollte. Erreciht der Timer jedoch das TOP Level wird der PIN nicht
wieder auf LOW gesetzt. Ist das ein BUG im Smulator? Kennt das jemand,
oder ist da einfach ein Fehler, den ich nicht blicke?
Compiler ist der CodeVison AVR 1.25.1.

Hier der C-Code

#include <mega2561.h>

void main()

{
    #asm("sei");

    GTCCR=0x00;

    //Timer für Soundausgabe über PWM
    // PB6 OC1 SIG_PWM 16BIT
    TCCR1A= 0b00110011;     //Fast PWM Mode, Set OC1B on Compare Match,
clear on TOP. OC1A/C not active
    TCCR1B= 0b00011000;     //No Clock, Timer Stoped. Fast PWM Mode
    TCCR1C= 0b00000000;     //only active if "non PWM Mode"

    OCR1AH= 0x00;           //Define TOP Value
    OCR1AL= 0x7A;           //
    OCR1BH= 0x00;           //Define Compare Level
    OCR1BL= 0x56;
    TIMSK1= 0b00000000;     //Timer Overflow Interrupt enabled

    TCCR1B|=0x01;           //Starts the timer

    while(1)
    {
    #asm ("nop");
    }
}

Vielen Dank,

Tobias
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
johnny.m Gast #361166
Lesenswert?
• ▲
▼ 
Fehler finde ich im Code jetzt nicht. Der Timer scheint nach Abgleich
mit dem Datenblatt korrekt initialisiert zu sein. Ein Bug im
AVRStudio-Simulator ist durchaus denkbar. Wäre nicht der erste.

Es wäre (für die Zukunft) sinnvoll, wenn Du die Steuerregister nicht
mit binären Bitmasken beschreibst sondern die Namen der Steuerbits
verwendest. Das macht den Code wesentlich leichter lesbar. Also z.B.

TCCR1B = (1 << WGM13) | (1 << WGM12);
statt
TCCR1B= 0b00011000;


> TIMSK1= 0b00000000;     //Timer Overflow Interrupt enabled

Vielleicht auch drauf achten, dass der Kommentar zum Code passt, und
nicht wie hier Verwirrung stiftet...

BTW:
Hinter Präprozessor-Direktiven kommt kein Semikolon (in diesem Fall
hieße es #asm("nop")). Ist hier nicht schlimm, aber es kann, wenn man
nicht drauf achtet, zu Fehlern führen, v.a. bei #define.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Tobias Gast #361167
Lesenswert?
• ▲
▼ 
Danke erst mal für die Tips. Das mit dem Kommentar kommt durch das
ständige Probieren und Ändern.
Der Code ist echt viel besser lesbar wenn man das so macht.
Also lass ich mich dadurch erst mal nicht beirren und warte auf die
Hardware.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
crazy horse Gast #361172
Lesenswert?
• ▲
▼ 
hast du auch den vom Compiler/Wizzard erzeugten Code mit dem Datenblatt
verglichen, insbesondere TCCR1? Auch da könnte natürlich schon ein
Fehler vorliegen, noch dazu, da der support für den 2561 noch recht neu
ist?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Tobias Gast #361173
Lesenswert?
• ▲
▼ 
Also die Adressen im Header stimmen mit dem im Datenblatt überein. Es
Funktioniert ja auch ein Mode, bei dem der Ausgangspin im Compara Match
Toggelt. Es könnte nun noch am Compiler liegen, dass der bei der
Umsetzung von C in Assembler was falsches macht, aber davon gehe ich
nicht aus, oder sollte man das auch überprüfen?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
crazy horse Gast #361175
Lesenswert?
• ▲
▼ 
darum gehts doch gar nicht, sondern darum, was der code-wizzard aus der
von dir gewünschten Funktion gemacht hat. Diese Zuordnung
Funktion->TCCR1A,TCCR1B kann durchaus Fehler enthalten. Entweder
Unachtsamkeit beim Compilerbauer oder Benutzung von vorläufigen
Datenblättern.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren