Hallo, ich möchte innerhalb der Interruptroutine, welche durch einen externen Interrupt an INT0 (Tiny13) ausgelöst wurde, überwachen wie der Status dieses Pins weiterhin ist. Kann ich einfach mit cbi DDRB,1 (Pin als Eingang schalten) und sbis bzw sbic den PIN weiterhin überwachen ? Hintergrund: Ich möchte ein 8Bit über den INT0 Eingang empfangen. Sobald der Level auf der Leitung von 5 auf 0 Volt wechselt löst der Interrupt aus. Innerhalb dieser Routine möchte dann die wieteren Pegeländerungen (Bits) auswerten um dann nach 8 Bits oder auch nach einem möglichen Timeout (Störimpuls auf der Leitung) die Interruptroutine zu verlassen und auf das nächste Byte warten. Gruß Günter
Ich nehme an du willst ne Serielle schnittstelle simulieren, dazu gibt es 2 Möglichkeiten die zum gewünschten Ziel führen Zum einen kannst du deine Aktivität am Pin über einen gewissen Zeitraum überwachen. Zum anderen deaktivierst du den nterrupt und somit kannst du dn Pin in irgendwelchen anderen schleifen als ganz "normalen" eingang verwenden. Und erst wenn du mit der auswertung fertig bist enablest du den Interrupt wieder. Gruß Dennis
Ich war immer davon ausgegangen, dass der Interrupt innerhalb der Routine automatisch deaktiviert und erst am Ende durch reti wieder aktiviert wird. Ich möcht nicht ständig den Eingangspin abfragen, sondern sobald ein Byte kommt in die Interruptroutine springen und dort dann die 8 Bits auswerten um dann die Routine verlassen. Beispiel interrupt: Abfrage an Pin int0 (PB1) Bitzeiten der 8 Bit bzw eventuellen Timeout durch Zähler auswerten. Anschliessend Status 1 oder 0 RXBxte = ??? Reti
Achso, ja, die Abfrage des einzelnen Pins in der Interrupt routine ist kein Problem, man sollte nur bedenken, das für die Zeit der Routine wie du oben auch schon beschrieben hast die anderen Interrupts blockiert werden. Wenn in dieser Zeit zum Beispiel ein Timeroverflow passiert, wird dieser erst nach der "Empfangsroutine" ausgeführt, was vielleiht zu zeitlichen Problemen führen kann. Deshalb sollte versucht werden, diese Routinen so kurz wie möglic zu halten.
Timer benutze ich aufgrund fehlender Erfahrung noch nicht. Die Bit_Auswertung mache ich mit Schleifen und Abfragen. Ich hatte nur Bedenken, ob es möglich ist, den Pin, der vorher als Interrupt-Pin gedient hat, in der Interruptroutine selber als einfachen Eingang zu verwenden.
Guenter Bru wrote: > Timer benutze ich aufgrund fehlender Erfahrung noch nicht. Schade eigentlich, denn das Verwenden eines Timers macht Vieles einfacher. > Die Bit_Auswertung mache ich mit Schleifen und Abfragen. > Ich hatte nur Bedenken, ob es möglich ist, den Pin, der vorher als > Interrupt-Pin gedient hat, in der Interruptroutine selber als einfachen > Eingang zu verwenden. In der ISR eines externen Interrupts das gesamte Telegramm einzulesen, ist keine gute Idee, aber sicherlich nicht unmöglich. Ich würde (für UART) beim Int den Timer starten und mir vom Timer die nächsten Abfragetermine generieren lassen. Bei anderen seriellen Übertragungsarten (z.B. 25/75%-Protokoll oder Servoimpuls) würde ich im ext. Interrupt den Timerstand abfragen und auswerten, also bei Impulsbeginn Zeitstempel merken und bei Impulsende den gemerkten vom neuen Zeitstempel subtrahieren. Das erlaubt genaue Zeitmessung (Software-ICP), während die Compare-Einheiten nebenher noch den Takt für andere Dinge bereitstellen können. ...
>>In der ISR eines externen Interrupts das gesamte Telegramm einzulesen, >>ist keine gute Idee, aber sicherlich nicht unmöglich. Was meinst du mit "sicherlich nicht unmöglich" ? So schwierig ? Ich programmiere eher selten. Timer mögen eleganter sein, aber während der uP das Byte einliest, braucht er nicht unbedingt etwas anderes zu machen. Anbei meine noch nicht so ganz funktionierende Interruptroutine:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | |
37 | |
38 | |
39 | |
40 | |
41 | |
42 | |
43 | |
44 | |
45 | |
46 | |
47 | |
48 | |
49 | |
50 | |
51 | |
52 | |
53 | |
54 | |
55 | |
56 | |
57 | |
58 | |
59 | |
60 | |
61 | |
62 | |
63 | |
64 | |
65 | |
66 | |
67 | |
68 | |
69 | |
Habe jetzt einige Zeit (erfolglos) herumprobiert: Folgender Code funktioniert nicht bzw die Befehle sbic oder auch sbis funktionieren nicht. Kann mir einer sagen warum das so ist ? Habe ich irgendetwas übersehen ? Bei L-Pegel soll der Interrupt auslösen, was er auch macht. Aber jede weitere Abfrage des Pins in der Interruptroutine ignoriert der Tiny13. Hier die Interruptroutine:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
Was passiert eigentlich mit weiteren INT0 Interrupts, welche während eines INT0 Interrupts auftreten ? Werden die verworfen oder in eine Warteschlange gestellt ? Gruß Günter
Gast
#670798
Hi Wieso schaltest du das Pin erst in der Interruptroutine als Eingang? Wenn du einen Interrupt auslösen willst geht das nur mit einem Eingang. MfG Spess
Gast
#670800
>Was passiert eigentlich mit weiteren INT0 Interrupts, welche während >eines INT0 Interrupts auftreten ? >Werden die verworfen oder in eine Warteschlange gestellt ? Oh ja, die werden in eine gestellt, aber in eine, deren Länge auf 1 begrenzt ist. :-) Die "Warteschlange" ist das INTF0-Flag im GIFR.
int0_handler: ;Empfängt Byte cbi ddrb,1 ;Pin als Eingang schalten Unfug, der Int-Pin sollte schon beim Warten auf den Int. Eingang sein... sbic portb,1 LED_aus: ;Label ist eigentlich nicht erforderlich sbi portb,3 ;LED aus ;Richtig, LED aus, wenn PB1 gesetzt war rjmp loop reti Was soll das denn??? LED_an wird dadurch nie erreicht... LED_an: cbi portb,3 ;LED an reti Versuch's mal so: int0_handler: ;Empfängt Byte sbic portb,1 ;ist H-Pegel an PB1? - nein, skip... sbi portb,3 ;ja, mach LED aus sbis portb,1 ;ist L-Pegel an PB1? - nein, skip... cbi portb,3 ;ja, mach LED an reti ;fertig und zurück... ...
Gast
#670807
>Ich möchte ein 8Bit über den INT0 Eingang empfangen. >Sobald der Level auf der Leitung von 5 auf 0 Volt wechselt löst der >Interrupt aus. Innerhalb dieser Routine möchte dann die wieteren >Pegeländerungen (Bits) auswerten um dann nach 8 Bits oder auch nach >einem möglichen Timeout (Störimpuls auf der Leitung) die >Interruptroutine zu verlassen und auf das nächste Byte warten. Mit externen Interrupts wird man da erfahrungsgemäß wenig glücklich. Die Alternative ist: Konfigurier einen Timer so, das er mit einer passenden Frequenz tickt, und frag in dessen Interrupthandler den Leitungspegel zyklisch ab. Mit dem jeweils aktuell eingelesenen Pegel fütterst Du eine State Machine, in der der Bitstrom geeignet verrechnet wird.
Gast
#670811
Ich habe den Code nochmal berichtigt. (Habe schon sehr viele Versuche probiert und den Code entsprechend oft geändert gehabt .) @spess53 Nur zur Sicherheit. Ich habe in der Initroutine auch schon ein cbi DDRB,1 stehen. @all Wie gesagt der Interrupt wird ausgelöst. Nur sbis und sbic funktionieren in der Interruptroutine nicht. sbis portb,1 müsste doch eigentlich prüfen, ob Eingang 1 an Port B H oder L ist und dementsprechend den RJMP Befehl ausführen oder überspringen. Bei unten stehendem Code wird der sbic folgende Befehls immer ausgeführt. Da bei portb,1 = L der Interrupt ausgeführt wird, müsste der kurze Zeit später immer noch auf L liegende Eingang doch bewirken, dass rjmp übersprungen wird. Bin ziemlich ratlos.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
Gruß Günter
Gast
#670816
Hi Den Status eines Eingangspins wird mit PinX nicht mit PortX abgefragt. MfG Spess
Stimmt. Danke vielmals für die Hilfe. Da hätte ich noch lange suchen können. Gruß Günter
Gast
#670836
Hi No Problem. Aber bei meinem letzten Posting sind bei mir Kopf und Finger in verschiedene Richtungen gewandert. Aber wenns hilft. MfG Spess
spess53 wrote: > Hi > > Den Status eines Eingangspins wird mit PinX nicht mit PortX abgefragt. > > MfG Spess Und das habe ich aufgrund der anderen Fehler auch noch übersehen, schäm... ...
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.