Seltsames Verhalten der Timer

Wie schalten deine Taster?
Nach Masse oder nach Vcc?

(Was ist der Grundzustand der Bits an denen die Taster hängen. 0 oder 
1?)

Wie schalten deine LED ein? Portbit auf 0 oder 1 für einschalten?

Luge schrieb:

> Und dann noch eine eher allgemeine Frage.
> Wie sieht den eigentlich eine "gute Programmstruktur" aus?

Deine Programmstruktur ist nicht schlecht.

> Da ich mir bisher alles selbst beigebracht habe mit diversen Tuts weis
> ich nicht wie guter Programmierstil eigentlich ausschaut.

Ist ok.
Für einen Autodidakten eigentlich sogar ziemlich gut.

> Wie liest man denn am besten Taster ein? Mainschleife? ISR? Funktion die
> ab und zu aufgerufen wird?

Über die PeDa Tastenentprellung :-)
http://www.mikrocontroller.net/articles/Entprellung#Komfortroutine_.28C_f.C3.BCr_AVR.29


> Wo löscht man am sinnvollsten LEDs?

So wie du das hast, ist das schon ok.

Luge schrieb:
> Eingänge:
> 0 = GND
> 1 = VCC
>
> Ausgänge:
> 0 = GND
> 1 = VCC
>

:-)
Lol das hab ich mir schon gedacht, dass 0 einem GND Pegel entspricht.

Ich formuliere anders:
Wenn du nichts drückst, liefert dann der Tasterpin eine 0 oder eine 1?

Zusatzfrage:
Bist du dir da ganz sicher?

Bonuspunkte:
Kannst du mal die externe Beschaltung in Form eines (nicht von dir 
gezeichneten) Schaltbildes zeigen bzw. wenn es ein fertiges Board ist 
den Namen des Boards nennen?

> Aber ich spiel schon seit Tagen mit den LEDs und Tastern herum, geht
> alles, die Makros funken auch.

Das muss nicht unbedingt etwas heißen, Wenn du alle Logik rumdrehst 
funktionieren die meisten Programme bei denen es nur um Taste 
gedrückt/nicht_gedrückt und Led_an/Led_aus geht, völlig gleich.

> Denke irgendwo im Timer oder in der ISR liegt der Fehler.

Sieht ok aus.

Luge schrieb:
> Sry dann hab ich deine Frage falsch verstanden :)
>
> Also, grad nachgemessen. Bei gedrücktem Taster liegen am Eingangspin 5V
> an.
> Ausserdem schaltet dann das Register PINB von 0x00 auf zb 0x10 bei
> Taster 5. (getestet über UART und Terminalprogramm, sowas erleichtert
> die Fehlersuche echt ungemein wenn man kein JTAG hat :))

OK

Ich such weiter

Da ist der erste Fehler

1

#define   LED_AUS(LED)    ((OUTPORT) &= (1 << (LED)))

muss heissen

1

#define   LED_AUS(LED)    ((OUTPORT) &= ~(1 << (LED)))

Luge schrieb:
> Danke dir!
>
> ich hatte schon Angst dass meine ISR zu lang ist. Aber bei 16Mhz dauert
> ein Takt ja grad mal ~60 nS, das reicht eigentlich dicke.

Du sagst es

> Aber ich kanns mir nur so erklären dass die ISR teilweise nicht
> aufgerufen wird/unvollständig ausgeführt wird.

Nein.
Du machst den Kardinalfehler: Bei Fehlern kannst du zu 99% davon 
ausgehen, dass DU einen Programmfehler gemacht hast, und nicht dass CPU 
oder Compiler irgendetwas schräges treiben.

holger schrieb:
> Jetzt hab ichs;)
>
>>  TIMSK |= (1<<OCF0);
>
> OCF0 gibts nicht in TIMSK. Das Ding heisst OCIE0.

Prinzipiell richtig.
Nur leider nicht das Problem :-)
(korrigier erst mal die fehlende ~)

OCIE   ist ein #define auf 1
OCF0   ist ein #define auf 1

d.h. in beiden Fällen steht dort

  TIMSK |= ( 1 << 1 );

und das schaltet den Compare Match Interrupt ein :-)

D.h. Obwohl du die falsche Bitbezeichnung genommen hast passiert 
trotzdem das richtige.

Nächster Fehler

1

    if TASTER(T5){

2

      LED_AN(LED1);

3

      timer_a = 3000;

4

5

    }

hier ist die Reihenfolge falsch, bzw. überhaupt der Zugriff.

Was ist das Problem:
Dein Code schaltet zb die LED ein. Und genau wie es der Teufel haben 
will, kommt der Compare Match Interrupt noch ehe timer_a auf 3000 
gesetzt wird. Die Folge: da die ISR abläuft, ehe timer_a auf 3000 
gesetzt wird, schaltet die ISR die LED wieder aus :-(

Da allerdings timer_a sowieso eine 16 Bit Variable ist, muss man den 
Zugriff atomic machen, also ein cli() / sei() Pärchen drumm herum legen.

1

    if TASTER(T5){

2

      cli()

3

      timer_a = 3000;

4

      LED_AN(LED1);

5

      sei();

6

    }

Für die andere Taste und den anderen Zähler genau gleich

Luge schrieb:

> @ Karl Heinz:
> Danke dir, werd ich sofort ausprobieren. Nur wie gesagt, bei Spielereien
> ohne Timer und ISR gabs nie Probleme.

Das lässt nur einen Schluss zu:
Du hast ganz einfach die falschen Dinge getestet.

(Durch Testen kann man immer nur das Vorhandensein von Fehlern 
nachweisen. Nie das Fehlen. Wenn also ein Programm so tut als ob, heißt 
das noch lange nicht das alles richtig ist)

> Evtl werd ich auch das Timer-Zeugs

Dein Problem ist nicht der Timer!
der arbeitet einwandfrei.
Das Problem ist dein Drumherum :-)

> aufschieben und erstmal eine geprüfte
> Routine zur Entprellung einbauen,

in dem Fall hättest du überhaupt keine Entprellung benötigt :-)

Luge schrieb:

> Wird auch geändert. Nur, mal im Ernst, wie groß ist die Chance dass der
> Interrupt immer genau nach dem Einschalten, bzw zwischen den Takten die
> für die Variablenzuweisung nötig sind, auftritt?

Ist uninteressant.
Passieren kanns (und ist mir auch in der Simulation passiert, ich habe 
allerdings andere Timereinstellungen benutzt, damit ich nicht ewig davor 
sitze) und damit muss es behandelt werden.


Mit den beiden Änderungen verhält sich dein Pgm in der Simulation so wie 
gewünscht. Hauptschuldiger war die fehlende ~

Luge schrieb:
> Danke dir nochmal, alles Bestens jetzt!
>
> Wieder was gelernt.
>
> Letzte Woche hatte ich solche Spielereien getestet:
>
> if (TASTER(T1))
>    LED_TOGGLE(LED1);

Ja und.

LED_TOGGLE ist ja ein ganz anderes Makro als LED_aus

Luge schrieb:

> Dadurch dass die Anweisungen bei Tasterdruck jetzt durch cli() und sei()
> atomar sind kann es ja sein dass sich meine ISR um einige hundert
> Nanosekunden verschiebt.

Das kann sein. Ja

> Im schlimmsten Fall bei jedem Durchlauf der
> Hauptschleife. An sich hier nicht tragisch.
>
> Aber was wäre zB, wenn ich eine Uhr oder sowas in der Richtung bauen
> will?
> Irgendwann würden sich ja die Zeiten doch soweit addieren,

Nur solange du nicht einen ISR Aufruf überhaupt verpasst.

Der Timer läuft ja im Hintergrund unbeeinflusst weiter.
Lediglich der eine ISR Aufruf kommt dann ein klein wenig später. Aber 
der nächste passt dann wieder, weil der Aufruf ja nur vom Timer selbst 
abhängt und nicht davon, wann die ISR zuletzt aufgerufen wurde.

Diese kleinen Fehler summieren sich also nicht auf.
Lediglich die Zeitabstände der ISR Aufrufe sind ein wenig unregelmässig. 
Aber wenn ein Aufruf ein klein wenig zu spät erfolgt, kommt dafür der 
nächste ein klein wenig früher und alles gleicht sich wieder aus.

Den Artikel kennst du?
Beitrag "Re: Pollin AVR Board Fehler beim drücken der Taster / Qualität der Bauteile"

Besonders ganz unten.