Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #308716 > unrolled thread

MPLAB Simulator für AVR kaputt?

Back to article view | Back to de.sci.electronics

Contents

  MPLAB Simulator für AVR kaputt? "Peter Heitzer" <peter.heitzer@rz.uni-regensburg.de> - 2021-08-18 10:40 +0000
    Re: MPLAB Simulator für AVR kaputt? Gunther Mannigel <newsgroups@mannigel.net> - 2021-08-31 22:13 +0200
      Re: MPLAB Simulator für AVR kaputt? Josef Moellers <josef.moellers@invalid.invalid> - 2021-09-01 10:46 +0200
        Re: MPLAB Simulator für AVR kaputt? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-01 11:35 +0200
          Re: MPLAB Simulator für AVR kaputt? Josef Moellers <josef.moellers@invalid.invalid> - 2021-09-01 13:57 +0200
            Re: MPLAB Simulator für AVR kaputt? Michael Bäuerle <michael.baeuerle@stz-e.de> - 2021-09-01 14:28 +0200
              Re: MPLAB Simulator für AVR kaputt? Josef Moellers <josef.moellers@invalid.invalid> - 2021-09-01 14:46 +0200
            Re: MPLAB Simulator für AVR kaputt? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-01 18:41 +0200
              Re: MPLAB Simulator für AVR kaputt? Michael Bäuerle <michael.baeuerle@stz-e.de> - 2021-09-01 19:29 +0200
                Re: MPLAB Simulator für AVR kaputt? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-02 01:36 +0200
              Re: MPLAB Simulator für AVR kaputt? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-09-01 19:11 +0000
                Re: MPLAB Simulator für AVR kaputt? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-02 01:51 +0200
                  Re: MPLAB Simulator für AVR kaputt? Michael Schwingen <news-1513678000@discworld.dascon.de> - 2021-09-03 20:09 +0000
                    Re: MPLAB Simulator für AVR kaputt? Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2021-09-04 07:09 +0200
        Re: MPLAB Simulator für AVR kaputt? Gunther Mannigel <newsgroups@mannigel.net> - 2021-09-01 21:28 +0200

#308716 — MPLAB Simulator für AVR kaputt?

Ich versuche gerade mit der neuesten MPLAB X IDE ein einfaches
Programm für einen ATTiny13a im Simulator zu testen.

#include <xc.h>
#include <avr/io.h>

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
....

Bei einem ähnlichen Programm für einen PIC16f627 tut der Simulator wie er
soll. Er hält nur beim Breakpoint an und auch "Continue" funktioniert bis
er beim nächsten Timeroverflow am gesetzten Breakpoint anhält.

Kann es sein, daß die Unterstützung der ATMEL Chips entgegen der Dokumentation
doch noch nicht so weit gediehen ist?

-- 
Dipl.-Inform(FH) Peter Heitzer, peter.heitzer@rz.uni-regensburg.de

[toc] | [next] | [standalone]

#309441

Am 18.08.2021 um 12:40 schrieb Peter Heitzer:
> Ich versuche gerade mit der neuesten MPLAB X IDE ein einfaches
> Programm für einen ATTiny13a im Simulator zu testen.
> 
> #include <xc.h>
> #include <avr/io.h>
> 
> uint8_t ov=0;
> void __interrupt(TIM0_OVF_vect_num) t0isr(void) {
>      ov++;
> }

Tiny kenne ich jetzt nicht, aber das kann daran liegen, dass das 
Interruptflag per Software zurückgesetzt werden muss. Der springt
aus der ISR gleich wieder rein.

Gruß
Gunther

[toc] | [prev] | [next] | [standalone]

#309447

On 31.08.21 22:13, Gunther Mannigel wrote:
> Am 18.08.2021 um 12:40 schrieb Peter Heitzer:
>> Ich versuche gerade mit der neuesten MPLAB X IDE ein einfaches
>> Programm für einen ATTiny13a im Simulator zu testen.
>>
>> #include <xc.h>
>> #include <avr/io.h>
>>
>> uint8_t ov=0;
>> void __interrupt(TIM0_OVF_vect_num) t0isr(void) {
>>      ov++;
>> }
> 
> Tiny kenne ich jetzt nicht, aber das kann daran liegen, dass das
> Interruptflag per Software zurückgesetzt werden muss. Der springt
> aus der ISR gleich wieder rein.

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

Ich stolpere aber über die Definition der ISR. Meine (OK, für einem
ATmega168) sieht so aus:
ISR(TIMER0_COMPA_vect)
{
}
und ... nein, ich lösche kein Interrupt Flag in der ISR.

Josef

[toc] | [prev] | [next] | [standalone]

#309452

On 9/1/21 10:46 AM, Josef Moellers wrote:


> Das Handbuch sagt allgemein (S.13):

Welches Handbuch?

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

Sowas ist mir noch nie begegnet. Wofür könnte so ein Interrupt gut sein?


> Ich stolpere aber über die Definition der ISR. Meine (OK, für einem
> ATmega168) sieht so aus:
> ISR(TIMER0_COMPA_vect)
> {
> }
> und ... nein, ich lösche kein Interrupt Flag in der ISR.

Die haben auch das übliche Interrupt-Handling, das alles nötige in 
Hardware erledigt. Siehe 4.7 Reset and Interrupt Handling

DoDi

[toc] | [prev] | [next] | [standalone]

#309460

On 01.09.21 11:35, Hans-Peter Diettrich wrote:
> On 9/1/21 10:46 AM, Josef Moellers wrote:
> 
> 
>> Das Handbuch sagt allgemein (S.13):
> 
> Welches Handbuch?
> 
> [...]
>> The second type of interrupts will trigger as long as the interrupt
>> condition is present. These interrupts do not necessarily have Interrupt
>> Flags.
> 
> Sowas ist mir noch nie begegnet. Wofür könnte so ein Interrupt gut sein?

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

>> Ich stolpere aber über die Definition der ISR. Meine (OK, für einem
>> ATmega168) sieht so aus:
>> ISR(TIMER0_COMPA_vect)
>> {
>> }
>> und ... nein, ich lösche kein Interrupt Flag in der ISR.
> 
> Die haben auch das übliche Interrupt-Handling, das alles nötige in
> Hardware erledigt. Siehe 4.7 Reset and Interrupt Handling

Wen meinst Du jetzt mit "Die"?
Für mich sind die ATtinys im Wesentlichen das Selbe wir die ATmegas, nur
eben kleiner.

Josef

[toc] | [prev] | [next] | [standalone]

#309461

Josef Moellers wrote:
> On 01.09.21 11:35, Hans-Peter Diettrich wrote:
> > On 9/1/21 10:46 AM, Josef Moellers wrote:
> > > 
> > [...]
> > > The second type of interrupts will trigger as long as the interrupt
> > > condition is present. These interrupts do not necessarily have Interrupt
> > > Flags.
> > 
> > Sowas ist mir noch nie begegnet. Wofür könnte so ein Interrupt gut sein?
> 
> Nennt sich ganz einfach "level triggered interrupt".
> Den zweiten Satz verstehe ich aber auch nicht.

Das Flag dient zum speichern eines Ereignisses, z.B. einer Flanke
an einem Pin. Für einen "level triggered"-Interrupt wird es nicht
benötigt, da z.B. der Pin-Zustand direkt verwendet werden kann.

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. [...]

Für Peripherie, die nur diesen Modus unterstützt, braucht das Flag
gar nicht implementiert zu sein.

[toc] | [prev] | [next] | [standalone]

#309462

On 01.09.21 14:28, Michael Bäuerle wrote:
> Josef Moellers wrote:
>> On 01.09.21 11:35, Hans-Peter Diettrich wrote:
>>> On 9/1/21 10:46 AM, Josef Moellers wrote:
>>>>
>>> [...]
>>>> The second type of interrupts will trigger as long as the interrupt
>>>> condition is present. These interrupts do not necessarily have Interrupt
>>>> Flags.
>>>
>>> Sowas ist mir noch nie begegnet. Wofür könnte so ein Interrupt gut sein?
>>
>> Nennt sich ganz einfach "level triggered interrupt".
>> Den zweiten Satz verstehe ich aber auch nicht.
> 
> Das Flag dient zum speichern eines Ereignisses, z.B. einer Flanke
> an einem Pin. Für einen "level triggered"-Interrupt wird es nicht
> benötigt, da z.B. der Pin-Zustand direkt verwendet werden kann.

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

Josef

[toc] | [prev] | [next] | [standalone]

#309470

On 9/1/21 1:57 PM, Josef Moellers wrote:
> On 01.09.21 11:35, Hans-Peter Diettrich wrote:
>> On 9/1/21 10:46 AM, Josef Moellers wrote:
>>
>>
>>> Das Handbuch sagt allgemein (S.13):
>>
>> Welches Handbuch?
>>
>> [...]
>>> The second type of interrupts will trigger as long as the interrupt
>>> condition is present. These interrupts do not necessarily have Interrupt
>>> Flags.
>>
>> Sowas ist mir noch nie begegnet. Wofür könnte so ein Interrupt gut sein?
> 
> Nennt sich ganz einfach "level triggered interrupt".

Ich fragte nicht nach dem Namen, sondern nach dessn möglicher 
(beabsichtigter) Verwendung. Vielleicht den Prozessor mit einem Signal 
völlig blockieren, weil dann nur noch der Interrupt-Code abläuft?


Anscheinend ist dieser zweite Interrupt-Typ ein Irrläufer aus irgend 
einem anderen schlauen Buch, der sich aus obskuren Gründen in einigen 
AVR Datenblättern gehalten hat. Außer dieser Erwähnung konnte ich noch 
keine Interrupt-Quelle finden, die diesen Typ implementieren würde.

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


>>> Ich stolpere aber über die Definition der ISR. Meine (OK, für einem
>>> ATmega168) sieht so aus:
>>> ISR(TIMER0_COMPA_vect)
>>> {
>>> }
>>> und ... nein, ich lösche kein Interrupt Flag in der ISR.
>>
>> Die haben auch das übliche Interrupt-Handling, das alles nötige in
>> Hardware erledigt. Siehe 4.7 Reset and Interrupt Handling
> 
> Wen meinst Du jetzt mit "Die"?
> Für mich sind die ATtinys im Wesentlichen das Selbe wir die ATmegas, nur
> eben kleiner.

Die 8 Bit AVRs, ATmega und ATtiny. Mit "üblich" auch noch alle 
Mikroprozessoren.

DoDi

[toc] | [prev] | [next] | [standalone]

#309476

Hans-Peter Diettrich wrote:
> On 9/1/21 1:57 PM, Josef Moellers wrote:
> > On 01.09.21 11:35, Hans-Peter Diettrich wrote:
> > > On 9/1/21 10:46 AM, Josef Moellers wrote:
> > > > 
> > > [...]
> > > > The second type of interrupts will trigger as long as the interrupt
> > > > condition is present. These interrupts do not necessarily have Interrupt
> > > > Flags.
> > > 
> > > Sowas ist mir noch nie begegnet. Wofür könnte so ein Interrupt gut sein?
> > 
> > Nennt sich ganz einfach "level triggered interrupt".
> 
> Ich fragte nicht nach dem Namen, sondern nach dessn möglicher 
> (beabsichtigter) Verwendung. Vielleicht den Prozessor mit einem Signal 
> völlig blockieren, weil dann nur noch der Interrupt-Code abläuft?

Zum einen lässt sich das Hauptprogramm eines AVR mit Interrupts nicht
völlig blockieren (Nach jeder ISR wird mindestens ein Befehl des Haupt-
programms ausgeführt).

Außerdem führt der Code in der ISR üblicherweise dazu, dass der
Interrupt deaktiviert wird. Falls das nicht der Fall ist kann die
ISR den Interrupt auch maskieren.

> Anscheinend ist dieser zweite Interrupt-Typ ein Irrläufer aus irgend 
> einem anderen schlauen Buch, der sich aus obskuren Gründen in einigen 
> AVR Datenblättern gehalten hat. Außer dieser Erwähnung konnte ich noch 
> keine Interrupt-Quelle finden, die diesen Typ implementieren würde.

Vielleicht liegt hier ein Missverständnis vor:
Das Interrupt-Flag für z.B. Edge-Trigger eines Pins braucht eigenen
Speicher, damit das auftreten des Ereignisses später noch festgestellt
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).

Im zitierten Text oben steht für den ersten Typ von Interrupts:
| 
| [...] the Interrupt Flag will be set and remembered [...]

Wegen dem "remembered" würde ich die oben zitierte Aussage so
interpretieren, dass der zweite Typ (Level-Trigger) sich eben nichts
merken muss (und ein Flag, im Sinne des dahinter stehenden Speichers,
daher prinzipiell nicht nötig ist).

[toc] | [prev] | [next] | [standalone]

#309497

On 9/1/21 7:29 PM, Michael Bäuerle wrote:
> Hans-Peter Diettrich wrote:

>>> Nennt sich ganz einfach "level triggered interrupt".
>>
>> Ich fragte nicht nach dem Namen, sondern nach dessn möglicher
>> (beabsichtigter) Verwendung. Vielleicht den Prozessor mit einem Signal
>> völlig blockieren, weil dann nur noch der Interrupt-Code abläuft?
> 
> Zum einen lässt sich das Hauptprogramm eines AVR mit Interrupts nicht
> völlig blockieren (Nach jeder ISR wird mindestens ein Befehl des Haupt-
> programms ausgeführt).

Nun ja, je nach Controller.

> Außerdem führt der Code in der ISR üblicherweise dazu, dass der
> Interrupt deaktiviert wird.

Wer so was schreibt hat Probleme mit seiner Interruptbehandlung.

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

Wozu? Das Flag wird immer zurückgesetzt, bis zum nächsten Trigger.

>> Anscheinend ist dieser zweite Interrupt-Typ ein Irrläufer aus irgend
>> einem anderen schlauen Buch, der sich aus obskuren Gründen in einigen
>> AVR Datenblättern gehalten hat. Außer dieser Erwähnung konnte ich noch
>> keine Interrupt-Quelle finden, die diesen Typ implementieren würde.
> 
> Vielleicht liegt hier ein Missverständnis vor:
> Das Interrupt-Flag für z.B. Edge-Trigger eines Pins braucht eigenen
> Speicher, damit das auftreten des Ereignisses später noch festgestellt
> werden kann.

Laut Beschreibung werden die Flags beim Aufruf des Handlers gelöscht. 
Der Programmierer muß sich schon selbst merken, welches Ereignis den 
Interrupt ausgelöst hat.

> 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).
> 
> Im zitierten Text oben steht für den ersten Typ von Interrupts:
> |
> | [...] the Interrupt Flag will be set and remembered [...]

Das ist wichtig für die Bearbeitung paralleler Interrupts. Zuerst kommt 
der mit der höchsten Priorität dran, die anderen erst später. Da wäre es 
gegen jede vernünftige Verwendung eines Interrupts, wenn der irgendwann 
(von der Hardware) unbearbeitet gelöscht würde.

> Wegen dem "remembered" würde ich die oben zitierte Aussage so
> interpretieren, dass der zweite Typ (Level-Trigger) sich eben nichts
> merken muss (und ein Flag, im Sinne des dahinter stehenden Speichers,
> daher prinzipiell nicht nötig ist).

Genau dann kann es aber passieren, daß höher priorisierte Interrupts 
behandelt werden und der Level schon wieder inaktiv ist, bevor sein ISR 
dran käme. Will man sowas ernsthaft haben?

Wie gesagt, mir fehlt jegliche Idee in welchem Controller so ein 
Interrupt realisiert ist und wofür man den verwenden könnte.

DoDi

[toc] | [prev] | [next] | [standalone]

#309477

On 2021-09-01, Hans-Peter Diettrich <DrDiettrich1@aol.com> wrote:
>> Nennt sich ganz einfach "level triggered interrupt".
>
> Ich fragte nicht nach dem Namen, sondern nach dessn möglicher 
> (beabsichtigter) Verwendung. Vielleicht den Prozessor mit einem Signal 
> völlig blockieren, weil dann nur noch der Interrupt-Code abläuft?
>
> Anscheinend ist dieser zweite Interrupt-Typ ein Irrläufer aus irgend 
> einem anderen schlauen Buch, der sich aus obskuren Gründen in einigen 
> AVR Datenblättern gehalten hat. Außer dieser Erwähnung konnte ich noch 
> keine Interrupt-Quelle finden, die diesen Typ implementieren würde.

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
zurück. Wenn weitere Daten da sind, bleibt das Interruptsignal aktiv und der
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

[toc] | [prev] | [next] | [standalone]

#309496

On 9/1/21 9:11 PM, Michael Schwingen wrote:
> On 2021-09-01, Hans-Peter Diettrich <DrDiettrich1@aol.com> wrote:

>> Anscheinend ist dieser zweite Interrupt-Typ ein Irrläufer aus irgend
>> einem anderen schlauen Buch, der sich aus obskuren Gründen in einigen
>> AVR Datenblättern gehalten hat. Außer dieser Erwähnung konnte ich noch
>> keine Interrupt-Quelle finden, die diesen Typ implementieren würde.
> 
> Das ist doch ganz normal, wenn man eine unbekannte Datenmenge ausliest, z.B.
> bei einem UART mit FIFO?

Ein FIFO wird nur benötigt, wenn ein Prozessor überlastet ist, wie beo 
den ersten PC. Heute würde man sowas (Netzwerk...) mit DMA erledigen.

> Der Interrupthandler tut irgendwas (z.B. ein Byte abholen) und springt
> zurück. Wenn weitere Daten da sind, bleibt das Interruptsignal aktiv und der
> Interrupthandler triggert erneut.

Normalerweise prüft man vor dem Rücksprung, ob noch weitere Daten 
vorliegen, dann geht die Verarbeitung deutlich schneller. Aber ein 
Controller, der auf einen Interrupt nicht rechtzeitig reagieren kann, 
bevor der nächste Interrupt (nächstes Zeichen) eintrifft, ist sowieso 
überfordert.


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

Und was dann? Wenn der Controller schon auf den ersten Interrupt nicht 
rechtzeitig reagieren kann, dann ist alles zu spät :-(

DoDi

[toc] | [prev] | [next] | [standalone]

#309540

On 2021-09-01, Hans-Peter Diettrich <DrDiettrich1@aol.com> wrote:
>> Das ist doch ganz normal, wenn man eine unbekannte Datenmenge ausliest, z.B.
>> bei einem UART mit FIFO?
>
> Ein FIFO wird nur benötigt, wenn ein Prozessor überlastet ist, wie beo 
> den ersten PC. Heute würde man sowas (Netzwerk...) mit DMA erledigen.

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

>> Der Interrupthandler tut irgendwas (z.B. ein Byte abholen) und springt
>> zurück. Wenn weitere Daten da sind, bleibt das Interruptsignal aktiv und der
>> Interrupthandler triggert erneut.
>
> Normalerweise prüft man vor dem Rücksprung, ob noch weitere Daten 
> vorliegen, dann geht die Verarbeitung deutlich schneller.

Das ist Optimierung. Trotzdem kann es passieren, daß zwischen dem Check
"nichts mehr da" und dem Rücksprung aus dem Interrupt neue Daten eintreffen,
und dann kein neuer Interrupt triggern würde. Daher ist es wichtig, daß der
Interrupt level-sensitiv ist - das vermeidet das Problem zuverlässig.

> Aber ein 
> Controller, der auf einen Interrupt nicht rechtzeitig reagieren kann, 
> bevor der nächste Interrupt (nächstes Zeichen) eintrifft, ist sowieso 
> überfordert.

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

>> Wenn Du sowas mit edge-triggered Interrupts machen willst, hast Du leicht
>> eine race condition, wenn im richtigen Moment gerade neue Daten eintreffen.
>
> Und was dann? Wenn der Controller schon auf den ersten Interrupt nicht 
> rechtzeitig reagieren kann, dann ist alles zu spät :-(

Nein. Mit Level-Interrupts hast Du evtl (das hängt von der Quelle ab - siehe
FIFO) Datenverlust. Bei Edge hast Du ein hängendes System, das überhaupt
keine Daten mehr überträgt.

cu
Michael

[toc] | [prev] | [next] | [standalone]

#309553

On 9/3/21 10:09 PM, Michael Schwingen wrote:
> On 2021-09-01, Hans-Peter Diettrich <DrDiettrich1@aol.com> wrote:

>> Normalerweise prüft man vor dem Rücksprung, ob noch weitere Daten
>> vorliegen, dann geht die Verarbeitung deutlich schneller.
> 
> Das ist Optimierung. Trotzdem kann es passieren, daß zwischen dem Check
> "nichts mehr da" und dem Rücksprung aus dem Interrupt neue Daten eintreffen,
> und dann kein neuer Interrupt triggern würde. Daher ist es wichtig, daß der
> Interrupt level-sensitiv ist - das vermeidet das Problem zuverlässig.

Quatsch :-(
Das Interrupt-Flag wird beim *Aufruf* der ISR gelöscht, kann danach also 
ohne Verlust gleich wieder neu gesetzt werden. Es ist aber kein Zähler, 
deshalb sollte man im FIFO Fall immer testen, wieviele Zeichen vor dem 
Betreten der ISR eingetroffen sind.


>> Und was dann? Wenn der Controller schon auf den ersten Interrupt nicht
>> rechtzeitig reagieren kann, dann ist alles zu spät :-(
> 
> Nein. Mit Level-Interrupts hast Du evtl (das hängt von der Quelle ab - siehe
> FIFO) Datenverlust. Bei Edge hast Du ein hängendes System, das überhaupt
> keine Daten mehr überträgt.

Wie das? *Jedes* Ereignis setzt das Interrupt-Flag, und wenn das gesetzt 
ist, wird der Interrupt auch behandelt. Bei Überlastung bekommt man eben 
nur das letzte Ereignis (epfangenes Zeichen...) mit, aber hängen kann da 
garnichts.


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

DoDi

[toc] | [prev] | [next] | [standalone]

#309479

Am 01.09.2021 um 10:46 schrieb Josef Moellers:
> The bit TOV0 is set when an overflow occurs in Timer/Counter0. TOV0 is
> cleared by hardware when executing the corresponding interrupt handling
> vector.

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.
Da gibt es dann Effekte, bei denen man kreative Idee´n haben muss um an 
der richtigen Stelle zu suchen.

Gruß
Gunther

[toc] | [prev] | [standalone]

Back to top | Article view | de.sci.electronics

csiph-web