Nach einer Interrupt Routine wird der PORT zurückgesetzt

Das ist es nicht gewesen. Habe zu Testzwecken folgende Zeile eingebaut:

1

temp1=temp1+temp;

Dies hat nicht funktioniert habe dann einen Compilerfehler erhalten
while(1)
   {
    volatile ("nop");
   }

Ja der Interrupt wird durch einen Taster ausgelöst. Laut Datenblatt 
werden die beiden Interrupts mit Steigender Flanke getriggert.

Daniel V. wrote:
> Ja der Interrupt wird durch einen Taster ausgelöst. Laut Datenblatt
> werden die beiden Interrupts mit Steigender Flanke getriggert.

Taster an Interrupts zu hängen ist generell eine schlechte Idee, da 
Taster nicht direkt von "Auf" nach "Zu" gehen, wenn man draufdrückt, 
sondern noch eine Weile "prellen".

Hier hilft eine Hardware-Entprellung mit RC-Tiefpass oder auf Interrupts 
verzichten und mit Peter Danneggers Bullet-Proof-Taster-Polling zu 
arbeiten.

PS: Was soll eigentlich das hier?

1

#define INT0_vect                     _VECTOR(1)

2

#define INT1_vect                     _VECTOR(2)

Ich habe es nun ausprobiert wenn ich das sei() umsetzte, trotzdem keine 
Änderung. Über die Beschaltung der Interrupts muss ich mir im ersten 
Schritt denke ich keine Sorgen machen. Ich benutze die auf dem Pollin 
Board befindlichen Taster dür die Interrupts. Dort befinden sich Pullup 
Widerstände und ein Kondensator zur Entprellung drauf. Ich sehe ja auch 
das der Port kurz geschaltet wird nur dann erlischt er wieder. Aber er 
soll ja auch nachdem die Interrupt routine verlassen wurde gesetzt 
bleiben.
Geht das überhaupt das?

Die Zeilen habe ich aus dem Tutorial aauf dieser Seite

#define INT0_vect                     _VECTOR(1)
#define INT1_vect                     _VECTOR(2)

Das Temp habe ich global gemacht, da ich eigentlich in beiden Routinen 
drauf zugreifen wollte. So langsam verzeweifel ich an dem AVR :-(

ja aber auch da wird der port nur ganz kurz gesetzt und dann wieder 
zurückgesetzt. ich vermute das wenn ich ports im interrupt setze, das 
diese dann nur für die dauer des interrupts gültig sind. kann das sein?

Hat denn einer von euch die Möglichkeit mein Porg mal zu testen?
Wäre echt super.

Hallo Marco,

ja da gebe ich dir recht. Aber ich habe noch ein Grundsätzliches 
Problem. Und zwar wird auch bei INT0 der PortC nicht dauerhaft gesetzt. 
Es blinkt immer nur kurz auf.

gegen prellen hilft ein 10N kerko parallel zum taster

es sollte kein Problemn mit dem Prellen sein, da ich das Board von 
pollin benutze. Ich sehe ja auch das der Ausgang den Zustand wechselt, 
jedoch nur für kurze Zeit

Daniel V. wrote:
> Hat denn einer von euch die Möglichkeit mein Porg mal zu testen?

Ne, geht nicht.

Bin kein Hellseher, kann also nicht riechen, welchen AVR Du hast.


Einige haben ne M103 Fuse, die schickt Deinen Stack in den Wald.


Peter

Hallo Peter,

Ich benutze den ATMEGA16, vielleicht hast du ja durch diese Info die 
Möglichkeit das zu testen. Wäre echt super. An die Fuses habe ich auch 
schon gedacht. Kann man diese so ohne weiteres ändern?

Daniel V. wrote:

> Ich benutze den ATMEGA16

stimmt nicht:

X.C: In function 'main':
X.C:49: error: 'GIMSK' undeclared (first use in this function)
X.C:49: error: (Each undeclared identifier is reported only once
X.C:49: error: for each function it appears in.)


Peter

Hallo Peter,

doch ich benutze den AtmEGA 16 auf dem POLLIN BOard. Bei mir wird der 
Code ohne Probleme compeliert. Ich compeliere mit AVR Studio 4 und 
übertrage dann mit Ponyprog und hatte bisher auch nie Probleme

Das GIMSK heißt beim ATmega16

GICR |=(1<<INT0)|(1<<INT1);

ich habe dies nun abgeändert, jedoch ändert sich leider nichts an dem 
verhalten. Hat noch jemand eine Idee? Kann es an den Fuses liegen?

Nur bei Anlage des Projektes habe ich im Auswahlfenster auf der Linken 
Seite Simulation und auf der rechten Seite ATMEGA16 ausgewählt. Nach dem 
ich dann das Prog compiliert habe schicke ich es mit Ponyprog auf den 
AVR. In Ponyprog habe ich auch ATMEGA16 ausgewählt.

@ich weiss auch alles besser:

Meine INT0 und INT 1 sind über das POLLIN Board mittels eines PULLUP 
widerstandes und eines Kondensators zum entprellen beschaltet. ICh sehe 
ja auch kurzzeitig das der Interrupt ausgeführt wird. von daher sollte 
es kein Pegelproblem sein?

Daniel V. wrote:
> Meine INT0 und INT 1 sind über das POLLIN Board mittels eines PULLUP
> widerstandes und eines Kondensators zum entprellen beschaltet. ICh sehe
> ja auch kurzzeitig das der Interrupt ausgeführt wird. von daher sollte
> es kein Pegelproblem sein?

Keine Ahnung ob es bei dir das Problem sein kann, aber generell schließt 
man Taster nicht an externe Interrupts an. Wenn die externe Entprellung 
aber korrekt dimensioniert ist, sollte das nichts machen.

Wo "siehst" du denn, dass der Interrupt ausgeführt wird? Weißt du wie 
schnell ein Taster prellen kann? Das kann man mit einer LED und dem 
menschlichen Auge nicht wahrnehmen. (Du siehst ja auch nicht, dass der 
Schalter für deine Zimmerbeleuchtung prellt). Hierfür bräuchte man schon 
ein Oszilloskop.

Das Problem daran ist aber, dass der Mikrocontroller so schnell ist, 
dass er das Prellen des Taster genau "mitbekommt". Aus seiner Sicht 
gesehen, ist das Prellen des Tasters sau-lahm.

Daniel V. wrote:
> Hallo Peter,
>
> doch ich benutze den AtmEGA 16 auf dem POLLIN BOard. Bei mir wird der
> Code ohne Probleme compeliert.

Dann hast Du nicht den ATmega16 als Target definiert, der hat kein 
GIMSK.

Bei nem falschen Target stürzt das Programm natürlich ab.

Und die Zeilen

1

#define INT0_vect                     _VECTOR(1)

2

#define INT1_vect                     _VECTOR(2)

schmeiß raus.
Die sind im io.h definiert, wenn das Target stimmt.


Peter

Hallo Axel,

die Idee mit dem PORT C auf FF zu setzen hat gezeigt, das der AVR einen 
Neustart macht. Und siehe da jetzt habe ich auch den Fehler gefunden. In 
meiner Entwicklungsumgebung war trotz auswahl des ATMEGA16 unter Device 
noch ATMEGA32 eingetragen. Ich denke mal das war ein typischer 
Anfängerfehler.
Trotzdem ein riesen Dankeschön an alle!!! ICh Verspreche Besserung :-)