mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Timer-Einheit zerschossen?


Autor: Justus Skorps (jussa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

kann man sich bei einem AVR die Timer-Einheit kaputt machen, und der 
Rest läuft noch?

Ich hab ein längeres Programm, was bzgl. Timer problemlos lief, hab 
etwas anderes am Code geändert und nun spielen die Timer (bzw. Timer0 
und Timer2 hab ich versucht) verrückt:

Eine LED (an C6), die eigentlich mit einer konstanten Frequenz blinken 
sollte, macht das nicht: Zuerst ist sie etwas länger(3-4 Sekunden) an, 
dann ganz kurz aus, so dass man es gerade erkennen kann. Das wiederholt 
sich dreimal, dann vertauschen sich die Zeiten, d.h. sie ist länger aus 
und geht ganz kurz an. Nach dreimal wieder zurück zu lange an-kurz 
aus...

Unten ist der zusammengekürzte Code, bei dem das Problem auftritt. Wenn 
ich statt dem Timer ein delay für das Blinken nehme, geht das wie 
erwartet, der Quarz ist also in Ordnung. Auch USART-Kommunikation 
geht...

µC ist ein ATmega644p mit 20MHz-Quarz. Das Problem tritt bei zwei 
verschiendenen Platinen auf, an der äußeren Beschaltung kann es also 
eigentlich nicht liegen, hab auch zig mal stromlos gemacht und/oder neu 
programmiert...

Fuses sollten auch stimmen (low F7-high D9-ext FF), da es mit denen bis 
jetzt geklappt hat...

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

volatile uint8_t timecounter0 = 0;
 
ISR(TIMER0_OVF_vect)
{
  timecounter0++;
}

int main()
{
  DDRC |=(1<<DDC6)|(1<<DDC5);           //C5 C6 als Ausgang 

  TCCR0B |= (1 << CS00) |(1 << CS02);  // Timer 0 starten, Prescaler = 1024
  TIMSK0 |= (1<<TOIE0);  

  PORTC = (1<<PORTC6)|(1<<PORTC5);

  sei();
  while (1)
  {
    if (timecounter0 == 32)     
    {
      //_delay_ms(500);
      PORTC ^= (1<<PORTC6);
    }
    
  }
} 

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>kann man sich bei einem AVR die Timer-Einheit kaputt machen, und der
>Rest läuft noch?

Nö - jedenfalls nicht per Software.

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn Du die Zählvariable nach dem Toggeln nicht zurücksetzt, ist es 
klar, dass da komische Dinge mit "vertauschten Zeiten" passieren...

Nach dem ersten Toggeln läuft das ganze eine Runde weiter, bis 
timecounter0 überläuft und dann wieder bei 32 anlangt. Dann wird 
wieder getoggelt und das Spielchen geht von vorne los. Ab da müsstest Du 
aber eigentlich zumindest konstante Intervalle bekommen, nur das erste 
ist eben kürzer...

Abgesehen davon ist ein Vergleich auf exakte Gleichheit in vielen Fällen 
ziemlich riskant (auch wenn es hier höchstwahrscheinlich funktioniert). 
Mach lieber ein ">=" draus...

Autor: Justus Skorps (jussa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johannes M. wrote:
> Wenn Du die Zählvariable nach dem Toggeln nicht zurücksetzt, ist es
> klar, dass da komische Dinge mit "vertauschten Zeiten" passieren...
>

F###...

genau die Zeile stand mal drinnen und ich hab sie aus Versehen mit ein 
paar anderen auskommentierten Zeilen gelöscht...

Vielen Dank für den Hinweis

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Nach dem ersten Toggeln läuft das ganze eine Runde weiter, bis
> timecounter0 überläuft und dann wieder bei 32 anlangt. Dann wird
> wieder getoggelt und das Spielchen geht von vorne los. Ab da müsstest Du
> aber eigentlich zumindest konstante Intervalle bekommen, nur das erste
> ist eben kürzer...

Nicht ganz. Bei der Vorteilereinstellung wird die Abfrage (übrigens auch 
bei >=) eine regelrechte Toggelorgie veranstalten. Denn timecounter0 
wird lange auf 32 stehen bleiben, bis sich der Timer dazu bequemt die 
Variable mal zu erhöhen.

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger wrote:
> Nicht ganz. Bei der Vorteilereinstellung wird die Abfrage (übrigens auch
> bei >=) eine regelrechte Toggelorgie veranstalten. Denn timecounter0
> wird lange auf 32 stehen bleiben, bis sich der Timer dazu bequemt die
> Variable mal zu erhöhen.
Au ja, da haste natürlich Recht. So weit hatte ich das jetzt gar nicht 
mehr nachzuvollziehen versucht...

Dementsprechend ist es natürlich schon fast Zufall, welchen Status der 
Portpin hat, wenn der Timer dann mal die Variable weiterzählt.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johannes M. wrote:

> Dementsprechend ist es natürlich schon fast Zufall, welchen Status der
> Portpin hat, wenn der Timer dann mal die Variable weiterzählt.

Darüber hab ich nachgedacht. Das ist wirklich ein seltsamer Effekt der 
da entsteht. Wie sich die Durchlaufzeiten der Hauptschleife und der ISR 
zu so einer, ich möchte es schon fast Schwebung nennen, überlagern. Wenn 
man sowas erreichen will, kriegt man es nicht hin.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.