MPLAB Simulator für AVR kaputt?

Ich versuche gerade mit der neuesten MPLAB X IDE ein einfaches

#include #include

uint8_t ov=0; void __interrupt(TIM0_OVF_vect_num) t0isr(void) { ov++; }

int main(void) { TCCR0B=5; // clk/1024 TIMSK0=_BV(TOIE0); TCNT0=0; ei(); /* Replace with your application code */ while (1) { } }

Wenn ich nun das Programm mit Debug starte, bleibt der Simulator am Ende der ISR stehen, obwohl kein Breakpoint gesetzt ist. Im Simuatorausgabefenster sind dann die folgenden Warnungen/Fehlermeldungen:

W0116-SIM: Last push caused a stack overflow E0108-SIM: Failed simulator operation: java.lang.ArrayIndexOutOfBoundsException: -1 ....

doch noch nicht so weit gediehen ist?

--
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de
Reply to
Peter Heitzer
Loading thread data ...

Am 18.08.2021 um 12:40 schrieb Peter Heitzer:

Tiny kenne ich jetzt nicht, aber das kann daran liegen, dass das

aus der ISR gleich wieder rein.

Gunther

Reply to
Gunther Mannigel

Beg to differ!

Das Handbuch sagt allgemein (S.13):

There are basically two types of interrupts. The first type is triggered by an event that sets the Interrupt Flag. For these interrupts, the Program Counter is vectored to the actual Interrupt Vector in order to execute the interrupt handling routine, and hardware clears the corresponding Interrupt Flag. Interrupt Flags can also be cleared by writing a logic one to the flag bit position(s) to be cleared.

The second type of interrupts will trigger as long as the interrupt condition is present. These interrupts do not necessarily have Interrupt Flags.

Konkret steht dann zum TOV0 (S.76):

The bit TOV0 is set when an overflow occurs in Timer/Counter0. TOV0 is cleared by hardware when executing the corresponding interrupt handling vector.

Bei den PICs ist das so, wie Du das beschreibst (BTDTNT).

ATmega168) sieht so aus: ISR(TIMER0_COMPA_vect) { }

Josef

Reply to
Josef Moellers

Welches Handbuch?

[...]

Hardware erledigt. Siehe 4.7 Reset and Interrupt Handling

DoDi

Reply to
Hans-Peter Diettrich

Nennt sich ganz einfach "level triggered interrupt". Den zweiten Satz verstehe ich aber auch nicht.

Wen meinst Du jetzt mit "Die"?

eben kleiner.

Josef

Reply to
Josef Moellers

Das Flag dient zum speichern eines Ereignisses, z.B. einer Flanke

In Atmels Worten (Zitate aus dem Datenblatt des ATmega164A): | | [...] If enabled, a level triggered interrupt will | generate an interrupt request as long as the pin is held low.

Und zu den Interrupt-Flags: | | [...] These flags are always cleared when INT2:0 are configured as | level interrupt. [...]

gar nicht implementiert zu sein.

Reply to
Michael Bäuerle

Ah ... verstanden ... wieder was gelernt.

Josef

Reply to
Josef Moellers

(beabsichtigter) Verwendung. Vielleicht den Prozessor mit einem Signal

Oder ist damit ein Reset Interrupt gemeint? Die haben aber alle ihre Flags.

Mikroprozessoren.

DoDi

Reply to
Hans-Peter Diettrich

Interrupt deaktiviert wird. Falls das nicht der Fall ist kann die ISR den Interrupt auch maskieren.

werden kann. Bei Level-Trigger kann das Bit eines Status-Registers einfach den aktuellen Zustand anzeigen/durchreichen. Damit kann man auch per Software darauf pollen (wenn keine ISR verwendet wird).

| | [...] the Interrupt Flag will be set and remembered [...]

interpretieren, dass der zweite Typ (Level-Trigger) sich eben nichts merken muss (und ein Flag, im Sinne des dahinter stehenden Speichers,

Reply to
Michael Bäuerle

Das ist doch ganz normal, wenn man eine unbekannte Datenmenge ausliest, z.B. bei einem UART mit FIFO?

Der Interrupthandler tut irgendwas (z.B. ein Byte abholen) und springt

Interrupthandler triggert erneut.

Wenn Du sowas mit edge-triggered Interrupts machen willst, hast Du leicht eine race condition, wenn im richtigen Moment gerade neue Daten eintreffen.

cu Michael

Reply to
Michael Schwingen

Am 01.09.2021 um 10:46 schrieb Josef Moellers:

Ah ja, solche Interruptflags. Dann war es das nicht. Ich hatte beim 3208 einen Timerinterrupt, da war das nicht so. Es gab ja auch mal eine 8052 oder 8039, der bei ISR-Aufruf das Statusbyte nicht gesichert hat.

der richtigen Stelle zu suchen.

Gunther

Reply to
Gunther Mannigel

Nun ja, je nach Controller.

Wer so was schreibt hat Probleme mit seiner Interruptbehandlung.

behandelt werden und der Level schon wieder inaktiv ist, bevor sein ISR

Wie gesagt, mir fehlt jegliche Idee in welchem Controller so ein

DoDi

Reply to
Hans-Peter Diettrich

vorliegen, dann geht die Verarbeitung deutlich schneller. Aber ein Controller, der auf einen Interrupt nicht rechtzeitig reagieren kann,

Und was dann? Wenn der Controller schon auf den ersten Interrupt nicht

DoDi

Reply to
Hans-Peter Diettrich

Das hat nun mit dem Prinzip der Interruptbehandlung nichts zu tun.

Nein. Das kommt auf die Anforderungen Deines Systems an, ob das ein Problem ist oder nicht.

cu Michael

Reply to
Michael Schwingen

Quatsch :-(

deshalb sollte man im FIFO Fall immer testen, wieviele Zeichen vor dem Betreten der ISR eingetroffen sind.

Wie das? *Jedes* Ereignis setzt das Interrupt-Flag, und wenn das gesetzt

garnichts.

Zudem bleibt meine Frage immer noch unbeantwortet, welcher Arduino einen Level-getriggerten Interrupt Eingang (ohne Flag) hat.

DoDi

Reply to
Hans-Peter Diettrich

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.