PinChangeInterrupt über das Setzen eines Pins auslösen

[Note (Gast)]

Hallo liebe Gemeinde,

es müsste doch irgendwie gehen, einen Interrupt künstlich herbeiführen 
zu können, indem man den jeweiligen Pin auf 1 bzw. 0 setzt?

Im Datenblatt wurde ich nicht fündig, wie man einen externen Interrupt 
von "intern" auslösen kann...

Danke im Voraus :)

[Jim M. (turboj)]

Es wäre hilfreich zu wissen welcher µC verwendet wird.

[Note (Gast)]

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.

[Gluckser (Gast)]

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?

[M. K. (sylaina)]

Note schrieb:
> es müsste doch irgendwie gehen, einen Interrupt künstlich herbeiführen
> zu können, indem man den jeweiligen Pin auf 1 bzw. 0 setzt?

Im Interrupt will man ja sicher etwas machen. Nur mal so am Rande: Statt 
einen Pin auf 1 bzw. 0 zu setzen könnte man doch gleich anschubsen, was 
man im Interrupt machen wollte. Welchen Sinn hat es denn hier einen 
zusätzlichen Schritt einzufügen?

[kühlrippe (Gast)]

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.

[M. K. (sylaina)]

kühlrippe schrieb:
> 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.

Du musst unbedingt lesen lernen. Er hat zwar den genauen Typ nicht 
genannt, wohl aber dass er sein Problem gelöst hat was eine Antwort mehr 
oder weniger erübrigt.

Und wenn du schon weißt, dass ein Atmega8 keinen Pin Change Interrupt 
hat kannste den ja auch gleich ausschließen.

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 ;)

[Stefan F. (Gast)]

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:

         10kΩ
Vcc o----[===]----- AVR Pin PB0


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

DDRB &= ~(1<<PB0);  // PB0=Eingang
if(PINB & (1<<PB0) // Eingang lesen
{
    ... tuwas
}

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.

[Peter D. (peda)]

M. K. schrieb:
> Statt
> einen Pin auf 1 bzw. 0 zu setzen könnte man doch gleich anschubsen, was
> man im Interrupt machen wollte. Welchen Sinn hat es denn hier einen
> zusätzlichen Schritt einzufügen?

Das frage ich mich auch.
Warum so umständlich von hinten durch die Brust ins Auge?

[Marc V. (Firma: Vescomp) (logarithmus)]

Peter D. schrieb:
> M. K. schrieb:
>> Statt
>> einen Pin auf 1 bzw. 0 zu setzen könnte man doch gleich anschubsen, was
>> man im Interrupt machen wollte. Welchen Sinn hat es denn hier einen
>> zusätzlichen Schritt einzufügen?
>
> Das frage ich mich auch.
> Warum so umständlich von hinten durch die Brust ins Auge?

 Zum testen ?
 Beispiel:
 a) Tastendruck wird simuliert.
 b) Taster (oder ext. Device) löst kein Interrupt aus, bzw. die ISR
 wird nicht angesprungen, aber mit setzen des Pins geht es.
 c) Statemachine wird getestet - wer will (und kann) sich schon die
 richtige Reihenfolge der Taster merken.
 d) Gremlins - da werden aus einer Random Tabelle die Zeiten und
 Zustände ausgelesen und auf Mainprogramm losgelassen.

[Note (Gast)]

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 :)

[M. K. (sylaina)]

Note schrieb:
> @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".

Meine Projekte sind irgendwie zu klein, auf so eine Idee bin ich bisher 
auch noch nicht gekommen. Zum Testen hast du also eine Art Bibliothek 
mit der Zustände simuliert werden? Ja, das kann schon sinnvoll sein, und 
wie stellst du sicher, dass dein "Simulationsprogramm" die Zustände auch 
richtig simuliert? Fände ich durchaus mal spannend.

[Marc V. (Firma: Vescomp) (logarithmus)]

M. K. schrieb:
> Meine Projekte sind irgendwie zu klein, auf so eine Idee bin ich bisher
> auch noch nicht gekommen. Zum Testen hast du also eine Art Bibliothek
> mit der Zustände simuliert werden? Ja, das kann schon sinnvoll sein, und
> wie stellst du sicher, dass dein "Simulationsprogramm" die Zustände auch
> richtig simuliert? Fände ich durchaus mal spannend.

 Industriesteuerungen - davon leben wir.
 Und Gremlins sind nicht meine Erfindung, die gab es schon bei Palm OS.

 Auf jeden Fall muss eine Steuerung mit Sensoren und Aktoren verbunden
 sein - um jede mögliche Situation auszutesten (und vorherzusehen)
 müsste man etwa 10000 Seiten füllen.

 Deswegen kriegt Statemachine zufällige, auch praktisch unmögliche
 Werte von simulierten Sensoren und muss darauf entsprechend reagieren,
 wobei simulierte Aktoren auch zufällige Positionen (oder Zustände)
 haben. Oder man lässt eine Steuerung normal arbeiten aber die
 entsprechenden Sensoren liefern zufällige Werte. Oder die Sensoren
 liefern normale Werte aber die Steuerung reagiert falsch.

 Wenn das alles ohne Fehler durchgelaufen ist, kann man aufatmen.
 Deswegen lässt man Gremlins über Nacht laufen, wertet die Ergebnisse
 mit einem PC aus und weil die so viel Unfug anstellen, heissen die
 wahrscheinlich auch Gremlins.

[kühlrippe (Gast)]

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.

[Note (Gast)]

@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? 
;)

[Gluckser (Gast)]

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.

[Marc V. (Firma: Vescomp) (logarithmus)]

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

 Ich würde ich es nicht unbedingt Leiden nennen, jetzt zumindest nicht
 mehr, früher vielleicht.
 Macht sogar manchmal Spass zu sehen, wie leicht man ganz
 offensichtliche (Fehler) Zustände beim programmieren übersehen kann.