Hallo zusammen, irgendwie werde ich aus dem Atmel-Datenblatt zum ATtiny13A nicht schlau. Mir gehen da Informationen ab, bzw. ich finde sie nicht. Der INT0-Interrupt wird so eingestellt, dass er bei einer fallenden Flanke auslöst. Der Interrupt soll dann einen anderen PORT-Pin einlesen. Wichtig ist dabei allerdings eine möglichst geringe Verzögerung. Was mich daher interessiert ist, wann genau der erste Befehl des Interrupts nach der fallenden Flanke am INT0-Pin ausgeführt wird. Das Datenblatt ( http://www.atmel.com/Images/doc8126.pdf ) gibt leider nur das Timing an, wann das Flag der PCINTn gesetzt wird. Hier gehe ich einfach mal davon aus, dass es beim INT0 nicht anders sein wird. Allerdings wann der erste Befehl nach dem Setzten des Interrupts ausgeführt wird, kann ich dem Datenblatt leider nicht entnehmen. Kann mir diesbezüglich jemand helfen? Vielen Dank Gruß Michael
@ Michael (Gast) >Was mich daher interessiert ist, wann genau der erste Befehl des >Interrupts nach der fallenden Flanke am INT0-Pin ausgeführt wird. Nach 4 Takten, nachdem der Interrupt intern aktiv wurde. Die Flankenerkennung an sich dauert vielleicht noch 1-2 Takte. >nur das Timing an, wann das Flag der PCINTn gesetzt wird. Hier gehe ich >einfach mal davon aus, dass es beim INT0 nicht anders sein wird. Sehr ähnlich. >Allerdings wann der erste Befehl nach dem Setzten des Interrupts >ausgeführt wird, kann ich dem Datenblatt leider nicht entnehmen. Ich schon. 4.7.1 Interrupt Response Time The interrupt execution response for all the enabled AVR interrupts is four clock cycles minimum. After four clock cycles the Program Vector address for the actual interrupt handling routine is executed. During this four clock cycle period, the Program Counter is pushed onto the Stack. The vector is normally a jump to the interrupt routine, and this jump takes three clock cycles. If an interrupt occurs during execution of a multi-cycle instruction, this instruction is completed before the interrupt is served. If an interrupt occurs when the MCU is in sleep mode, the interrupt execution response time is increased by four clock cycles. his increase comes in addition to the start-up time from the selected sleep mode. A return from an interrupt handling routine takes four clock cycles. During these four clock cycles, the Program Counter (two bytes) is popped back from the Stack, the Stack Pointer is incremented by two, and the I-bit in SREG is set.
Michael schrieb: > Kann mir diesbezüglich jemand helfen? es wird auf jeden Fall der aktuelle befehlt noch abgearbeitet, im schlimmsten fall ist es ein Spruch. gehe mal von 3 Takten aus. Ab dann kommt der Sprung in der ISR was auch noch mal 1( oder sogar 2) Takte sind. Und auch nicht vergessen, in der zeit der kein andere ISR aktiv sein, sonst wird es viel mehr.
Falk Brunner schrieb: > Ich schon. > > 4.7.1 Interrupt Response Time So versteckt... Das hab ich nicht gefunden. Danke.
Ganz genau lässt sich das nicht sagen. Die Atmels sind aber relativ schnell. 1. Aktueller Befehl beenden 2. Push IP ca. 2 Tick-Tacks 3. JMP ISR ca. 2 Tick-Tacks Vorsicht: Die Atmels sichern noch nicht mal die Flags. 4. IRET ca. 2 Tick-Tacks Wenn Du noch was sichern musst: Pro Push/Pop 2 Takte. Und natürlich Deine Sequenz.
Zitat:
1 | 4.7.1 Interrupt Response Time |
2 | The interrupt execution response for all the enabled AVR interrupts is four clock cycles minimum. |
3 | After four clock cycles the Program Vector address for the actual interrupt handling routine |
4 | is executed. During this four clock cycle period, the Program Counter is pushed onto the Stack. |
5 | The vector is normally a jump to the interrupt routine, and this jump takes three clock cycles. |
Das ganze fängt mit dem Beginn des Befehls nach dem Setzen des Flags an. Dabei beinhalten die oben genannten minimal 4 Zyklen auch die Ausführung des nächsten Befehls mit einem Zyklus. Benötigt der Befehl mehrere Zyklen, dauert es halt länger. Wenn das Flag gesetzt wird, wird also der zur Zeit laufende Befehl fertig abgearbeitet, ebenso der darauf folgende. Dann wird der ISR-Vector angesprungen. Da einzelne Befehle zwischen einem und drei Zyklen benötigen, dauert das ganze also zwischen 4 und 8 Zyklen. Dazu kommt dann noch die Ausführung des Sprungbefehls rjmp in der ISR-Tabelle mit nochmal 2 Zyklen ( da irrt der Text des Datenblatts...) Nach 6 bis 10 Zyklen nach setzen des Flags bist du also am Beginn deiner ISR-Routine. Oliver
Danke euch allen, Damit ist das Thema Interrupt für mich vom Tisch. Das dauert alles viel zu lange. Dann muss ich wohl den entsprechenden Pin pollen, was auch schon recht langsam für meine Anwendung ist, weil ja immer ein Rücksprung mit 2 Takten gemacht werden muss wodurch effektiv nur alle 3 Takte der Pin gelesen wird und im schlimmsten Falle auch 4 Takte zum ersten Befehl vergehen
1 | ; low-Pegel abwarten |
2 | low: SBIS PINB,1 |
3 | RJMP low |
4 | ; high-Pegel abwarten |
5 | high: SBIC PINB,1 |
6 | RJMP high |
7 | ; hier war die fallende Fanke |
8 | IN 16,PINB |
9 | ... |
Der zu messende Pegel muss innerhalb von etwa 500ns gemessen sein. Bei einer Taktfrequenz von 8MHz ergibt das leider nur 4 Takte... Vielleicht muss ich ja doch auf 16MHz umsteigen, aber auch dann ist das noch zu unsicher mit nem Interrupt... Trotzdem Danke
Michael schrieb: > Der INT0-Interrupt wird so eingestellt, dass er bei einer fallenden > Flanke auslöst. Der Interrupt soll dann einen anderen PORT-Pin einlesen. Zusätzlich ein D-Flipflop mit der fallenden Flanke triggern und das Signal auf den D-Eingang. Dann kannst du, solange kein weiterer Trigger gekommen ist, am Ausgang des Flipflops den Signalzustand auch später lesen. MfG Klaus
@ Michael (Gast) >Der zu messende Pegel muss innerhalb von etwa 500ns gemessen sein. Bei >einer Taktfrequenz von 8MHz ergibt das leider nur 4 Takte... Beschreibe dein Vorhaben, nicht deine vermeintliche Lösung. Siehe Netiquette.
Michael schrieb: > Der zu messende Pegel muss innerhalb von etwa 500ns gemessen sein. Bei > einer Taktfrequenz von 8MHz ergibt das leider nur 4 Takte... > Vielleicht muss ich ja doch auf 16MHz umsteigen, aber auch dann ist das > noch zu unsicher mit nem Interrupt... Warum nicht 20 MHz? Der ATtiny13A ist offiziell dafür ausgelegt. 2 Takte kannst du zusätzlich sparen, wenn die Interrupt-Routine nicht irgendwo im Speicher beginnt, sondern genau dort, wo sich der Interrupt-Vektor befindet. Voraussetzung dafür ist natürlich, dass die in der Tabelle folgenden Vektoren nicht benötigt werden. Mir hat das schon oft geholfen.
Die unterschiedliche Antwortzeit wird zum Problem, wenn genaues Timing für eine Video-Ausgabe nötig ist. http://www.batsocks.co.uk/readme/art_SerialVideo_3.htm ein Arduino-Program zur ASCII-Ausgabe auf einem TV. nur mit einem Trick wird es hier vermieden: "Normally, AVRs have a slightly jittery interrupt latency...To prevent this jitter, the μC is put to sleep. When an interrupt wakes the processor from sleep, no instructions are executing, hence there is a repeatable, constant latency." http://www.watterott.com/de/Batsocks-TellyMate-Video-Output-Shield Es gibt ähnliche Programme, z.B. ein Fertiggerät von Pollin, oder auch hier in der Artikelsammlung. Beitrag "AVR ASCII Video Terminal - 40 x 25 - BAS Signal" Beitrag "AVR VGA Terminal"
Falk Brunner schrieb: > Beschreibe dein Vorhaben, nicht deine vermeintliche Lösung. > > Siehe Netiquette. Sorry, ich wollte nicht zu weit ausholen, damit keiner von einem Roman abgeschreckt wird. Ich hab den Thread gelesen: Beitrag "Präzisions Monoflop zur Erzeugung von Pulsen im Bereich von 200-800ns" und da ich auch gerade einen solchen LED-Strip bekommen habe und damit spiele fand ich die Idee genial einen kleinen µC als Datenwandler zu nehmen. Das Bedeutet, ich möchte einerseits ein 800kHz SPI-Signal lesen und dabei jedes einzelne Datenbit in einen langen (ca. 650ns) oder kurzen (ca. 300ns) langen Puls verwandeln. ( die vorliegenden Angaben zu den Pulslängen variieren von 250ns bis 350ns je +-150ns für eine logische "0", und von 600ns bis 700ns ebenfalls jeweils +-150ns für die logische "1". Scheint also nicht sooo genau zu gehen. ) Beim 800kHz Taktisgnal kommen die Taktflanken eben im 625ns takt. Nicht viel Zeit wenn ein Prozessortakt schon 125ns benötigt. Auf 8MHz beschränken wollte ich mich damit ich den internen RC-Oszillator verwenden kann und einen Quarz oder dergleichen einsparen kann.
schau mal hier: http://www.ledstyles.de/ftopic21707.html im Verlauf des threads sind noch mehr Loesungen angeboten. Andre
Wenn Du einen Pin-Status nur durchreichen willst, so geht dass am Besten in Hardware. Willst Du aber irgendwie darauf reagieren, so hast Du nicht nur ein Interruptproblem, sondern auch noch dass Problem, das ein µP im Allgemeinen auch irgendwas zutun hat und irgendein Statusregister/-bit nicht dauernd und in Nullzeit abgefragt werden kann. Also jeder Was-Auch-Immer-Befehl blockiert die Hauptschleife und verhindert somit eine mögliche Statusabfrage. Zusätzlich kommt am Ende der Hauptschleife noch ein Sprungbefehl, der auch seine Zeit haben will.
Michael schrieb: > Auf 8MHz beschränken wollte ich mich damit ich den internen > RC-Oszillator verwenden kann und einen Quarz oder dergleichen einsparen > kann. OK, ich spar auch gern Bauteile ein. :-) Du könntest es mit einem ATtiny85 versuchen, der lässt sich auch ohne Quarz mit 16 MHz betreiben.
Markus Weber schrieb: > OK, ich spar auch gern Bauteile ein. :-) Du könntest es mit einem > ATtiny85 versuchen, der lässt sich auch ohne Quarz mit 16 MHz betreiben. Ich frage mich wie das gehen soll... der hat auch nur einen 8MHz internen RC-Oszillator. OK er hat ne PLL mit 8x Multiplikator aber der geht ausschließlich als Taktquelle für den Timer/Counter1?! und die Kalibrierung des internen RC-Oszillators auf 200% stellen kann man bei jedem mir bekannten AVR nur weiß halt keiner so recht was dabei wirklich raus kommt. Hat das schon mal jemand ausprobiert? Wär glatt mal ein Versuch wert.
Michael schrieb: > und die Kalibrierung des internen RC-Oszillators auf 200% stellen kann > man bei jedem mir bekannten AVR nur weiß halt keiner so recht was dabei > wirklich raus kommt. Hat das schon mal jemand ausprobiert? Wär glatt mal > ein Versuch wert. Hat bei mir ohne Probleme funktioniert. Allerdings meine ich ist das außerhalb der Spezifikationen.
Die ATtiny85 und 861 können die PLL auf 16MHz runter geteilt als CPU-Takt fusen.
Peter Dannegger schrieb: > Die ATtiny85 und 861 können die PLL auf 16MHz runter geteilt als > CPU-Takt fusen. Dass der 861 das auch kann, war mir gar nicht bewusst, danke für den Tipp! Megas gibts aber keine, die offiziell intern mit 16 MHz laufen, oder?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.