PinChangeInterrupt über das Setzen eines Pins auslösen

Entschuldigt bitte, es handelt sich hierbei um einen ATmega.

Habe aber bereits mein Problem und auch die Lösung dazu entdeckt.

Um den Software-Interrupt auslösen zu können, muss dieser konfiguriert 
und aktiviert werden. Jedoch sind die Pins dazu als Ausgänge zu 
definieren.

Mein Problem war, dass ich gleich nach dem Software-Interrupt wieder in 
den ext. Modus gehen wollte (also den Pin wieder als Eingang definieren) 
- was nicht funktioniert hat. Hierbei verweise ich auf das Kapitel 
"Switching Between Input and Output" jedes AVR-Datenblatts.

Zwischen diesen Befehlen muss mind. ein nop() vorhanden sein. Hat 
irgendwas mit dem Verhindern des metastabilen Pin-Zustandes zu tun.

Der Port Pin muss nicht als Ausgang konfiguriert werden, damit man 
einen Software-Interupt implementieren kann.

Die Aussage ist, dass es trotzdem möglich ist.

Ich habe eben noch mal im Datenblatt des ATMega32 nachgeschaut. Seite 
66. Dort steht es so. Welchen Typ verwendest Du?

Note schrieb:
> Entschuldigt bitte, es handelt sich hierbei um einen ATmega.

Wird nicht entschuldigt. Wer nicht gleich seinen µC Typ nennt und dann 
auf Nachfrage immer noch nicht den genauen Typ mitteilt hate eigentlich 
keine Antwort verdient.

Ein ATmega8 hat zB überhaupt keinen PinChangeInterrupt. Auf ein 
erwähntes aber nicht näher bezeichnetes oder verlinktes Datenblatt, also 
noch zu suchendes Datenblatt Bezug nehmen zu können, geht auch nicht.

Bei den Eingängen von AVR's ist es so, dass die Software beim Lesen von 
PINx immer den Pegel sieht, der einen Takt vorher am Pin angelegen hat.

An folgendem Beispiel will ich Dir zeigen, welche Konsequenz das hat:

1

         10kΩ

2

Vcc o----[===]----- AVR Pin PB0

3

4

5

DDRB |= (1<<PB0);   // PB0=Ausgang

6

PORTB &= ~(1<<PB0); // PBO=Low

7

8

DDRB &= ~(1<<PB0);  // PB0=Eingang

9

if(PINB & (1<<PB0) // Eingang lesen

10

{

11

    ... tuwas

12

}

Zunächst wird der Pin als Ausgang mit Low Pegel gesetzt. Danach wird er 
als Eingang verwendet und ausgelesen. Die if-Abfrage wird allerdings 
niemals einen High Pegel sehen, da PINB stets den Status von einem Takt 
vorher zurück liefert. Und da war das noch ein Ausgang mit Low Pegel.

Also muss vor die if-Afrage noch mindestens irgendein anderer Befehl 
stehen.

Weiterhin sollte man berücksichtigen, dass der AVR (und die Leitungen) 
eine gewisse Kapazität haben. Der Eingang wird nicht sofort von Low nach 
High wechseln. Je größer der Wert des Pull-Up Widerstandes ist, umso 
länger dauert es.

Danke für die zahlreichen Antworten, Leute :)
Manchmal zweifle ich hier etwas am Ton, aber nun gut, man hat manchmal 
schlechte Tage. Habe mich für meinen Fehler entschuldigt.

Der ATmega-Typ ist an der Stelle völlig irrelevant, weil das Datenblatt 
zum Thema PinChangeInterrupt überall die gleichen Hardware-Angaben 
macht. (Solange der ATmega einen PinChangeInterrupt-Vektor besitzt)

@Stefan Us: Genau, da war meine Missinterpretation! Dass da faktisch 
immer ein Befehl dazwischen stehen muss, da kam ich nicht auf Anhieb 
drauf bzw. habe den Part im Datenblatt übersehen. Ob man da jetzt einen 
wirklichen (sinnvollen) Befehl oder NOP macht, ist natürlich egal. Ich 
danke dir für die ausführliche Antwort.

@M. Köhler, Peter Dannegger: Danke für die Anmerkungen, aber an der 
Stelle hatte Marc Vesely völlig Recht - es ist zum Testen gedacht. Die 
Signalfolge (also seriell) kommt von einer PLC/SPS (die ich gerade nicht 
vor mir stehen habe) und versetzt meinen Zustandsautomaten/State Machine 
in bestimmte Zustände. Damit ich keine externen Geräte für den Test 
verwenden muss, habe ich mir gedacht - naja, dann startest du das Ding 
"per intern".

Vielen Dank an euch und einen schönen Tag.
Bei weiteren Anregungen und Ideen stehe ich natürlich zur Verfügung :)

Note schrieb:
> Bei weiteren Anregungen und Ideen stehe ich natürlich zur Verfügung :)

Bei Fragen zu µCs IMMER den genauen Typ angeben. Das erspart 
Diskussionen und entspricht der Netiquette. Selbst wenn man alle 
Datenblätter zu allen ATmegas kennt und glaubt, daß da immer das gleiche 
zu einem bestimmten Thema drin steht, kann man nicht von allen Lesern 
erwarten, daß sie auch daran glauben.

@Marc Vesely: Sehe ich da einen (Leidens-)Genossen? ;)

@M. Köhler: Die wesentlichen Sachen hat Marc Vesely schon erklärt. Für 
kleinere Anwendungen und Test, wenn man ein HMI hat (LCD+Tasten oder per 
UART o.ä.) kann man gut eine Art "Debugging Console" einrichten - dort 
gibt man meinetwegen die genaue serielle Folge in binär (oder eben 
ASCII) an und diese wird an dem jeweiligen Eingang "simuliert".
Ob das eine richtige "Bibliothek" wird hängt natürlich davon ab, wie 
komplex das Timing zu sein hat. Unabhängig davon, ob es bessere 
Möglichkeiten gibt, kann man Selbsttest-Funktionen in MCU implementieren 
(beim Feldversuch/Installation ist man häufig stark begrenzt in seinen 
Testmöglichkeiten)

@kühlrippe: Weiß Bescheid, wird nicht wieder vorkommen. Wieder Freunde? 
;)

M. K. schrieb:
> Gluckser schrieb:
>> Ich habe eben noch mal im Datenblatt des ATMega32 nachgeschaut. Seite
>> 66. Dort steht es so. Welchen Typ verwendest Du?
>
> Da werden die externen Interrupts INT0 und INT1 behandelt (zumindest im
> 02/2011er Datasheet des ATmega32),
> die werden sich anders verhalten als
> die Pin Change Interrupts, die der TE benutzt ;)

Ich weiß nicht, was Du damit sagen willst? Ist das eine Kritik? Habe ich 
was Falsches geschrieben? Willst DU eine Vermutung äussern, dass sie 
sich anders verhalten? Oder ist das eine Aussage über eine Tatsache?
Was bedeutet das "werden" in Deinem Satz?

Das sind die Pin Change Interrupts und es sind die 
Level-Interrupts und das sind die externen Interrupts. Unabhängig 
davon welche Art (Level oder Flanke) man konfiguriert (das steht etwas 
tiefer auf der selben Seite), kann man so Software-Interrupts 
realisieren.