Forum: Mikrocontroller und Digitale Elektronik Timer-Einheit zerschossen?


von Justus S. (jussa)


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...

1
#include <avr/io.h>
2
#include <avr/interrupt.h>
3
#include <util/delay.h>
4
5
volatile uint8_t timecounter0 = 0;
6
 
7
ISR(TIMER0_OVF_vect)
8
{
9
  timecounter0++;
10
}
11
12
int main()
13
{
14
  DDRC |=(1<<DDC6)|(1<<DDC5);           //C5 C6 als Ausgang 
15
16
  TCCR0B |= (1 << CS00) |(1 << CS02);  // Timer 0 starten, Prescaler = 1024
17
  TIMSK0 |= (1<<TOIE0);  
18
19
  PORTC = (1<<PORTC6)|(1<<PORTC5);
20
21
  sei();
22
  while (1)
23
  {
24
    if (timecounter0 == 32)     
25
    {
26
      //_delay_ms(500);
27
      PORTC ^= (1<<PORTC6);
28
    }
29
    
30
  }
31
}

von Knut B. (Firma: TravelRec.) (travelrec) Benutzerseite


Lesenswert?

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

Nö - jedenfalls nicht per Software.

von Johannes M. (johnny-m)


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...

von Justus S. (jussa)


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

von Karl H. (kbuchegg)


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.

von Johannes M. (johnny-m)


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.

von Karl H. (kbuchegg)


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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.