Hallo, kann mir vieleicht einer sagen, wie lange die Reaktion auf einen Interrupt ist? ich hab´s im Datenblatt nicht gefunden. (Atmega 64 @ 16MHz) ich hab mim Oszi mal gemessen, des waren so um die 500ns des erscheint mir etwas viel kann das sein? Danke im Vorraus
habs soeben gefunden es sind 437,5ns(+evtl. zeit in der ein multi-cycle instruktion zuende ausgeführt wir). oder 4clk für bis in die Interruptroutine, 3 clk für den sprung, und der zuvorausgeführte befehl wird zuende ausgeführt.
Moin! Mir fällt da nur zum ATM8 bzw. 16 (dürfte beim 64 auch so sein) ein, dass es 4 Taktzyklen dauert, bis der erste Befehl der Interruptroutine ausgeführt wird. In dieser Zeit muss die MCU den PC mit der richtigen Sprungadresse des betreffenden Interrupts laden. Soweit ich mich erinnern kann, stand das im Kapitel zum Interrupthandling (liegt ja auch irgendwie auf der Hand). Gruß Roadrunner
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. This 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. Die Reaktionszeit liegt also bei 250ns + Sprung zur Routine, was nochmal 187ns dauert. Die 500ns kommen also hin. Der Text steht übrigends etwas versteckt unter AVR CPU Core und nicht unter Interrupts.
Zu diesen Reaktionszeiten dazu kommen natürlich noch so Sachen wie Register retten. Vor allem das Sichern des SREG braucht schon mindestens 5 Taktzyklen (push r16, in r16, SREG, push r16). Der Unsicherheitsfaktor mit dem Multicycle-Befehl, der noch zuende ausgeführt wird, liegt wohl je nach Prozessor bei 3 oder 4 Taktzyklen (die längsten Befehle, wie z.B. call brauchen 4 oder 5, wenn also nach dem ersten Takt davon der Interrupt kommt, wird noch 3 bzw. 4 gewartet). Falls der Prozessor beim Auftreten des Interrupt im Idle- oder Sleepmodus war, kommt noch die Aufwachzeit und eine zusätzliche Verlängerung der Antwortzeit dazu. Ich weiß grad nicht auswendig, wieviel das ist.
danke nochmals kann mir einer von euch einen controller empfehlen den ich statt dem Atmega 64 nehmen könnte? wäre schön wenn die software nicht groß umgeändert werden müsste... und ich sag mal so von der Verarbeitunggeschwindigkeit wäre faktor 10 x so schnell wünschenswert. hab den SX52BD von Parallax im Netz gesehen, habt ihr erfahrungen mit diesen?
Google mal nach Atmega64-HS. Der soll angeblich mit 200MHz laufen. Ist pin- und funktionskompatibel.
Interrupt-Antwortzeiten sind immer recht lang. Darf man fragen, warum die Reaktionszeit so kurz sein muss?
wollte auf mit den Interrupts den I2C-Bus mit 400 kHz tracen... da aber bei steigender Flanke der CLK innerhalb von 600ns auslesen muß sind die 500ns an Interrupt-Antwortzeit ziemlich lang... ich habe mir mal wie oben beschrieben den SX52BD-100 angeschaut, der hätte nur 30ns Interruptreaktionszeit... leider habe ich die Hardware scho fertig... werde wohl aber bald auf was schnelleres wie den Atmega64 umsteigen müssen, den der ist "etwas" überfordert...
ja mit polling habs auch scho probiert und hab eine Max. Abtastrate von 800 kHz aber laut spec ist die "high" zustand vom Clk für min 600 ns d.h. ich müßte mit 1600 MHz abtasten... ist glaub ich nicht möglich nochmal soviel ausm controller rauszuholen... man bedenke d.h. alle 10 Clk bei 16MHz den Bus abtasten... in dieser zeit sollten die daten ja auch weggeschickt werden... Nochmals zu Interrupts... wenn ein interrupt ausgelöst wird push der MCT den Program Counter... geschieht des im Hintergrund oder ist da der MCT dann für meine Befehle blockiert?
Hardware I2C interface... funktioniert auch nicht, da ich das Interface nur als Slave verwenden könnte. Weil der Trace möglichst passiv ablaufen sollte! und der Slave reagiert dann nur auf die Eingespeicherte Adresse... oder gibt es ein möglichkeit auf das Bus Interface Unit zuzugreifen?
Stimmt, das I2C Interface ist zu gut. Bei einfachen AVRs wie dem tiny2313 mit USI funktioniert das aber wunderbar. Damit habe ich einen einfachen I2C Sniffer realisiert der mir alle Aktivitäten auf dem Bus am PC anzeigt.
<<Nochmals zu Interrupts... wenn ein interrupt ausgelöst wird push der MCT den Program Counter... geschieht des im Hintergrund oder ist da der MCT dann für meine Befehle blockiert?>> Wie vermutet, war Deine Forderung nach einem schnellem µP nur der Ausdruck dafür, daß Du keine Ahnung hast. Wenn Du obige Frage nicht selbst beantworten kannst, bringe erst einmal eine LED zum Blinken.
Das ich nicht so viel Ahnung habe, wie andere hier stimmt !!! aber seit 2 Jahren verschiedene Controller in ASM zu programieren nenne ich nicht unbedingt "keine Ahnung" das problem ist das jeder MCT anders ist... habe bisher vorallem mit welchen mit nem C166 Core zu tun gehabt... und da ich versuche so wenig wie möglich anzunehmen, wenn nix im Datenblatt steht, oder ich es nicht finde, frage ich lieber nach... so wie ich des sehe, blockiert der Interrupt den MCT für min 435ns das ist ziehmlcih lang, aber es könnte auch sein, das des Pushen im Hintergrund abläuft..
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.