Software Interrupt Atmega8

int0, wenn ausgelöst und das globale wie auch INT0 Int freigegeben sind 
wird die INT0 ISR angesprungen. Was da drinne passiert ist deiner 
fantasie überlassen.

defeniere mal bitte was du unter SoftwareInterrupts meints?

Clemens Trunner schrieb:

> Wie im Betreff schon steht würde ich gerne wissen ob es möglich ist mit
> dem Atmega8 einen Software Interrupt an INT0 zu realisiern

Natürlich.

> und wenn ja
> dann wie mach ich da in C?

Du tust es einfach.

Allerdings: Der Sinn des Unterfangens ist reichlich nebulös. Ein 
Interrupt ist letztlich nichts anderes, als eine Funktion, die durch 
äußere Ereignisse nebenläufig zu beliebiger Zeit aufgerufen werden kann. 
Wenn er aber von der Software selber ausgelöst wird und nicht durch 
äußere Ereignisse, dann wird er einigermaßen sinnlos, denn statt der 
Auslösung des Interrupts könnte die Software ja auch gleich den 
Interrupthandler direkt aufrufen. Wozu also den Interrupt-Overhead in 
Kauf nehmen? Das ist weitgehend sinnlos.

Die einzige Ausnahme sind eigentlich Debugger-Funktionalitäten. Die sind 
darauf angewiesen, auch an die Stelle der kleinstmöglichen Instruktion 
zu passen. Nur hier ergibt ein solcher "Software-Interrupt" einen Sinn, 
sonst nicht.

Die bisherigen Antworten kamen am Nachmittag, da haben wohl
noch alle geschlafen, oder waren noch im Schlaumeier-Mode.

Schaut doch einfach in's Datenblatt!

Gleich zu Anfang im Kapitel "External Interrupts" steht:

> The external interrupts are triggered by the INT0, and INT1 pins.
> Observe that, if enabled, the interrupts will trigger even if the
> INT0..1 pins are configured as outputs. This feature provides a
> way of generating a software interrupt.

Wie macht man das in C?
Da ich nur in ASM arbeite, kann ich jetzt nicht den C-Code
liefern - ansonsten machst du es ...
- So, wie du den INT0 als HW-Interrupt initialisierst.
- Dann setzt du den Port D2 als Ausgang, und schaltest den
  genau so, wie ein externes Signal den INT0 auslösen würde.

Karl Heinz Buchegger schrieb:

> Erhebt sich immer noch die Frage: Wozu, wenn man anstatt den
> Interrupt auszulösen, die Funktion auch direkt aufrufen kann,
> wenn es notwendig ist?

Wenn der SW-Interrupt laut Hersteller problemlos machbar ist,
muss man ihn doch nicht als "Sowas tut man nicht!"
verheimlichen...

Theoretisch könnte man ihn vielleicht zur Fehlerbehandlung
nutzen.

Allerdings hätte ICH keine Ahnung, wie sich bei einem Direkt-
Aufruf das "reti" auswirkt. - Wäre für mich eher die "Finger-
weg!" Variante...

>Wozu, wenn man anstatt den Interrupt auszulösen, die Funktion auch direkt
>aufrufen kann, wenn es notwendig ist?

Weil beides im Detail verschiedene Aktionen bewirkt und es Situationen 
gibt, wo es auf diese Unterschiede ankommt.

Beim Aufrufen der Funktion mit rcall wird:
    - simultan die Returnadresse auf dem Stack abgelegt und
      der PC (program counter) mit der Adresse der Funktion geladen,
      was den Ansprung der Funktion bewirkt.

Beim Auslösen des Interrupts wird:
     - erstmal nur das zugehörige INTF-Flag gesetzt und
sobald die Interrupts global enabled sind (i-Flag = 0):
     - simultan das i-Flag gesetzt (*),
       die Returnadresse auf dem Stack abgelegt und
       der PC mit der Interrupt-Einsprungadresse geladen.

Der wesentliche Unterschied ist der mit (*) markierte. Durch das 
automatische Setzen des i-Flags wird der Code in der ISR geschützt, d. 
h. nicht durch andere Interrupts unterbrechbar ausgeführt. Man kann das 
auch nicht erreichen, indem man ein rcall mit vorangesetztem sei 
macht, denn das ist nicht atomar. Ein zu diesem Zeitpunkt anstehender 
Interrupt würde die Programmausführung unerwünschterweise zwischen sei 
und rcall unterbrechen.

Die wichtigste Bedeutung von Software-Interrupts liegt in der 
Realisierung von sogenannten Exceptions oder Traps.

Hi

>     - erstmal nur das zugehörige INTF-Flag gesetzt und
>sobald die Interrupts global enabled sind (i-Flag = 0):
>     - simultan das i-Flag gesetzt (*),

diese Aussage solltest du noch mal überdenken

MfG Spess

Ahhh... damn, das i-Flag war irgendwie invertiert in meinem Kopf. Big 
sorry!

So ist es richtig:

>>sobald die Interrupts global enabled sind (i-Flag = 1):
>>     - simultan das i-Flag gelöscht (*),

Danke, Spess!



PS: War nur'n Test... ;-)

Schöne Diskussion, hab ich auch was dazugelernt.

- Hoffentlich auch der TO.

LostInMusic schrieb:

> Man kann das
> auch nicht erreichen, indem man ein rcall mit vorangesetztem /sei/
> macht, denn das ist nicht atomar.

Das ist doppelt falsch.

Zum einen schachlich-logisch, denn das ist wirklich kein Ersatz für eine 
Interruptauslösung, weil dafür natürlich cli und nicht sei zu verwenden 
wäre.

Und obendrein ist auch noch die Begründung falsch, daß die Folge sei, 
rcall nicht atomar wäre, sie IST es. Siehe AVR instruction set 
reference: "The instruction following SEI will be executed before any 
pending interrupts".

Und auch die korrekte Umsetzung mit cli, rcall ist atomar. Wieder Zitat 
aus derselben Quelle: "The interrupts will be immediately disabled. No 
interrupt will be executed after the CLI instruction, even if it occurs 
simultaneously with the CLI instruction."

Was bleibt also von deiner Argumentation pro Software-Int? Nichts, nur 
heiße Luft.

Ich kenne auch genug Leute, denen fallen keine sinnvollen 
Anwendungsfaelle fuer Threads ein. Und fuer jedes Threadbeispiel faellt 
denen auch immer ein Gegenbeispiel ein, wie es ohne geht. Es gab ja auch 
Affen die fanden, es sei nicht sinnvoll vom Baum zu klettern. Kann man 
so sehen. Muss man aber nicht.

Karl-Heinz hat soweit Recht; allerdings wären ein paar gesparte Bytes im 
Flash für mich ebenfalls kein Grund, einen Software-INT auf einem Atmega 
zu nutzen. Da würde ich vorher andere Stellen finden, um die Bytes 
einzusparen.

Schwachsinn.

Karl Heinz Buchegger schrieb:

> Aber abgesehen davon, sehe ich noch immer nicht, wozu ich einen
> SW-Interrupt bei einem Tiny oder Mega benutzen würde, bzw. welchen
> Vorteil das hätte.

Wie ich schon weiter oben angemerkt habe, macht das eigentlich nur für 
Debug-Geschichten einen Sinn, also eine Verwendung des SW-Int-Auslösers 
als Quasi-Breakpoint. Man könnte damit z.B. einen netzwerkfähigen 
in-circuit-Debugger basteln.

Peter Dannegger schrieb:

> In Assembler findet man das Konzept der Scratchpad-Register nur selten,
> da wird oft gepusht/gepopt, bis der Arzt kommt, egal ob Interrupt oder
> Funktion.

Ich weiß ja nicht, welche Asm-Programme du als Quelle deiner Weisheiten 
benutzt, vermutlich Programme, die für Lehr- oder Anschauungszwecke 
gemacht wurden. Da macht man's natürlich "ordentlich" und kitzelt nicht 
noch den letzten Takt raus.

Bei praktischen Programmen aber natürlich sehr wohl. Allerdings wird man 
auch da i.d.R. selektiv vorgehen und nur dort optimieren, wo die 
Optimierung lohnt.

Bei einem DDS-Funktionsgenerator etwa ist mir scheißegal, wenn in den 
Routinen für die Benutzerinteraktion oder für die Initialisierung der 
Waveform möglicherweise ein paar überflüssige pushs und pops drinne 
sind. Hauptsache, die eigentliche DDS-Routine braucht eine konstante und 
möglichst geringe Anzahl von Takten. Dafür wird natürlich alles in 
Registern gehalten.

Ich schätze, das Clemens sich mit MS-DOS beschäftigt hat und die 
Betriebsystemaufrufe mittels Software-Interrupt praktisch findet.

Naja, immerhin könnte man mit der Methode "SW-Interrupt" einen 
Unterfunktionsaufruf bis nach dem aktuellen CLI-SEI-Block "aufschieben". 
Dieser wird dann nur ein mal Ausgeführt, auch wenn der Trigger mehrfach 
erfolgte. Falls man zufällig genau diese Funktionalität braucht ist das 
doch ganz praktisch.

Peter Dannegger schrieb:
> Man könnte auch ganz profan ein Flagh setzen und es am Ende testen.
> Dann muß man nicht für länger alle Interrupts sperren.

"Und fuer jedes Threadbeispiel faellt
denen auch immer ein Gegenbeispiel ein, wie es ohne geht."

Wenn ihr Controller designen wuerdet, koennten sie gar nichts. Weil es 
fuer jedes Feature irgendeinen Ersatz gibt, mit dem man sich behelfen 
kann.