Robotrontechnik-Forum

Registrieren || Einloggen || Hilfe/FAQ || Suche || Mitglieder || Home || Statistik || Kalender || Admins

Willkommen Gast!

Robotrontechnik-Forum » Technische Diskussionen » Z80/U880 Interruptsystem » Themenansicht

Autor

Thread - Seiten: -1-

000
10.02.2009, 20:02 Uhr
jmueller

Hallo,

das Z80-Interruptsystem ist ja allgemein bekannt
und auch gut beschrieben.
Wo aber die Dokumentationen recht dünn werden,
ist der Fall, wenn die Interruptauslösung unterdrückt
bzw. behindert wird.
Und genau in dem Zusammenhang bin ich mir bei einigen Details
der Daisy Chain nicht ganz 100% sicher.
Deshalb möchte ich hier mal ein paar Fälle zru Diskussion stellen.
In den meisten Fällen glaube ich zwar die Antwort zu wissen,
doch ich halte mich damit mal absichtlich zurück
und stelle einfach nur die Fragen.

Also gegeben sind 2 Interrupt auslösende Bausteine A und B
(z.B. PIO oder CTC), wobei A höher priorisiert ist.

1. Fall:
A stellt eine Interruptanforderungen und zieht /INT auf L,
in der CPU sind Interrupts gesperrt und A wartet nun ewig
auf die Interruptbestätigung
Wenn nun 1000 Befehle später ein EI-Befehl ausgeführt wird,
wird dann der Interrupt noch angenommen?

2. Fall:
Interrupts in der CPU gesperrt,
B stellt Interruptsanforderung,
später stellt auch A Interruptanforderungen,
Nun kommt EI, Wird daraufhin A und anschließend B bedient?

3. Fall:
Interrupts in der CPU gesperrt und A stellt Interruptanforderung,
Anschließend wird A so umprogrammiert,
dass keine Interrupts ausgelöst werden (Interruptfreigabebit=0).
Bleibt die Interruptsanforderung trotzdem bestehen?

4.Fall:
A stellt Interruptanforderung,
anschließend möchte auch B eine Interruptanforderung stellen,
kann aber nicht (niedriger priorisiert).
Geht die Interruptanforderung verloren oder wird sie noch aktiv,
nachdem die Interruptseriviceroutine für A beendet
und die Daisy Chain wieder geschlossen ist?

Mir fallen noch mehr Fälle ein,
aber das soll erstmal genügen.
Also was ist eure Meinung?

Jens

Seitenanfang

Seitenende

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

001
10.02.2009, 21:50 Uhr
susowa

Zitat:

jmueller schrieb
Wo aber die Dokumentationen recht dünn werden,
ist der Fall, wenn die Interruptauslösung unterdrückt
bzw. behindert wird.
Und genau in dem Zusammenhang bin ich mir bei einigen Details
der Daisy Chain nicht ganz 100% sicher.

Da bringst Du 3 Sachen zusammen, welche vollkommen getrennt sind und nichts miteinander zu tun haben:

- Auslöser ist immer die Peripherie
- Annahme macht immer die CPU
- DaisyChain regelt nur die Prioritäten zwischen kaskadierter Peripherie

Das ganze läuft statisch ab, gesteuert von Pegeln bzw. Flanken, welche in Flags statisch gespeichert werden und anschliessend entsprechend Taktregime in den diversen CPU-Zyklen stur nach dem gleichen Muster abgearbeitet werden.

Gute Quelle für Deine Fragen:

http://www.z80.info/zip/z80-interrupts.pdf

Soll beispielsweise heissen, wenn die CPU /INT laut Taktregime sampelt und das liegt auf L, wird der INT auch angenommen oder wenn ein peripherer Baustein /INT auf L zieht, wird das immer bedient, sobald das von der CPU beachtet wird, Zeit spielt dort keine Rolle.

Für die Regelung der Prioritäten geschachtelter Interrupts und Freigabe von beteiligten Bausteinen ist EI nicht entscheidend, das wird in der Mitte von RETI erledigt.

Insofern kannst Du Deine Fragen alle selbst richtig beantworten, wenn Du die Pegelbedingungen während der CPU-Zyklen genau spezifizieren kannst - dafür sind aber Deine Fragen teilweise zu ungenau.

Seitenanfang

Seitenende

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

002
10.02.2009, 22:34 Uhr
tp

Zitat:

susowa schrieb
- DaisyChain regelt nur die Prioritäten zwischen kaskadierter Peripherie
...
Für die Regelung der Prioritäten geschachtelter Interrupts und Freigabe von beteiligten Bausteinen ist EI nicht entscheidend, das wird in der Mitte von RETI erledigt.

Und genau deshalb, weil die CPU von der DaisyChain überhaupt nix mitbekommt, dekodieren die Peripherie-Schaltkreise auch das RETI selber. Nur so können sie unter Beachtung der DaisyChain (IEI/IEO) feststellen, was sie tun müssen.
--
Die Zeit ist auch nicht mehr, was sie mal war! (Albert Einstein)

Seitenanfang

Seitenende

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

003
10.02.2009, 22:59 Uhr
jmueller

@susowa: danke für den Link,
das Dokument kenne ich aber schon.

@alle:
Die Arbeitsweise des Interruptsystems ist mir schon klar.
Ich möchte im Prinzip wissen, ob es außer bei Reset Fälle gibt
in denen eine Interruptanforderung (z.B. durch den Peripheriebaustein selbst)
wieder zurückgenommen wird (deshalb Frage mit Fall 3)
oder (z.B. durch die Daisy Chain) "verloren" gehen kann.

Es war wohl nicht so glücklich,
das in Form von Fallbeispielen zur Diskussion zu stellen.
Nun ja, bei den Fällen 1, 2 und 4 wolte ich meine eigene Antwort
bestätigt wissen.
Bei Fall 3 weiß ich aber wirklich nicht, was da CTC und PIO tun.

Jens

Seitenanfang

Seitenende

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

004
10.02.2009, 23:46 Uhr
holm

Avatar von holm

So weit ich mich erinnere war in der RFE mal ein Fall dokumentiert in dem Fall 3 zu einem Absturz führte bei dem ein CTC beteiligt war.

Gruß,

Holm
--
float R,y=1.5,x,r,A,P,B;int u,h=80,n=80,s;main(c,v)int c;char **v;
{s=(c>1?(h=atoi(v[1])):h)*h/2;for(R=6./h;s%h||(y-=R,x=-2),s;4<(P=B*B)+
(r=A*A)|++u==n&&putchar(*(((--s%h)?(u<n?--u%6:6):7)+"World! \n"))&&
(A=B=P=u=r=0,x+=R/2))A=B*2*A+y,B=P+x-r;}

Seitenanfang

Seitenende

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

005
11.02.2009, 12:04 Uhr
susowa

Zitat:

Bei Fall 3 weiß ich aber wirklich nicht, was da CTC und PIO tun.

Diese Frage kann Dir die Literatur zu CPU und implementiertem Interruptsystem auch nicht beantworten, sondern nur das Datenblatt des Peripheriebausteines.
Nur dort steht drin, was der Baustein wie und wann auf dem Bus macht, wenn er umprogrammiert wird. Und da gibt es viele schöne Möglichkeiten, sowohl bei PIO als auch CTC.
Da aber wie bei der CPU davon auszugehen ist, dass alles statisch nach Taktregime abgearbeitet wird, geht die /INT Leitung auch wieder auf H, wenn Du die Int-Freigabe auf Disable programmierst - wann das genau passiert, kann man dem Taktdiagramm des Bausteins entnehmen, i.d.R. ist das ja vorhanden.

Seitenanfang

Seitenende

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

006
11.02.2009, 18:47 Uhr
Wusel_1

Hallo Jens,

das ganze hier auszuführen wäre sehr lang. Ich würde sagen, du siehst, wenn du hast, mal in das Buch "Mikroprozessortechnik" von Kieser und Meder. Da findest du ab Seite 215 bis 241 alles über den Interrut und das Interruptsystem des Z80 und deren Peripherieschaltkreise. Da steht auch wann ein Interrup verloren geht und wenn nicht. Da ich in nächster Zeit nicht anwesend bin (Urlaub) habe ich keine Möglichkeit (Zeit) die Seiten zu scannen. Sollte es Zeit haben und du das Buch nicht griffbereit hast, dann könnte ich es so mitte März mal die Seiten einscannen.

MfG Andreas
--
Beste Grüße Andreas
______________________________________
DL9UNF ex Y22MF es Y35ZF
JO42VP - DOK: Y43 - LDK: CE

*** wer glaubt, hört auf zu denken ***

Seitenanfang

Seitenende

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

007
11.02.2009, 20:13 Uhr
jmueller

Ich sollte vielleicht mal den Hintergrund meines Postings erläutern,
damit man es besser versteht:

Also auf der Suche nach einem Fehler in meinem Emulator JKCEMU
habe ich vorgestern die Emulation des Z80-Interruptsystems zerprogrammiert.
Als es dann gestern nicht besser, sondern noch schlimmer wurde,
habe ich die Grundfrage bekommen und an meinem Verstand gezweifelt.
Im Zuge dessen kam ich dann (nachträglich betrachtet idiotischerweie und überhastet)
auf die Idee, die Fälle, die ich zerprogrammiert hatte und nicht mehr funktionierten,
hier zur Diskussion zu stellen.
Inzwischen ist der Fehler gefunden und behoben,
der Programmcode wieder sauber und strukturiert
und die Emulation funktioniert auch wieder richtig.

Geblieben ist aber die Überlegung bzw. Frage nach möglichen Fällen,
in denen Interruptanforderungen nicht angenommen werden.
Insofern wäre ich an dem Buch "Mikroprozessortechnik" von Kieser und Meder
schon interessiert, wenn da solche Fragen behandelt werden.
Ich habe es aber leider nicht.
Ich plane aber, dieses Jahr als Neuling zum KC-Treffen zu kommen.
Vielleicht gibt es da die Möglichkeit, einen Blick hineinzuwerfen.
Da mein Emu wieder funktioniert und zudem der Fehler auch behoben ist,
gibt es erstmal kein akutes Problem.

Gruß
Jens

Seitenanfang

Seitenende

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

008
11.02.2009, 20:23 Uhr
ggrohmann

Hallo Jens!

Ich habe das Buch und kann es dir gerne ausborgen.

Guido

Seitenanfang

Seitenende

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

009
11.02.2009, 20:35 Uhr
jmueller

@Guido:

> Ich habe das Buch und kann es dir gerne ausborgen.

Gern!
Wie ist für dich das Ausborgen am einfachsten?

Wenn du es mir schicken willst,
meine Adresse steht im Impressum auf http://www.jens-mueller.org
Porto übernehme ich selbstverständlich!

Gruß
Jens

Seitenanfang

Seitenende

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

010
11.02.2009, 20:40 Uhr
susowa

Zitat:

Geblieben ist aber die Überlegung bzw. Frage nach möglichen Fällen,
in denen Interruptanforderungen nicht angenommen werden.

Auszüge aus der "Kieser und Meder"-Bibel findet man viele auf den Seiten von Herrn Rost - zur PIO steht dort:

http://www.sn.schule.de/~gyfloeha/rt/lex09/z80pio/funktion.htm#int

U.a. folgender langer Satz, welcher zumindest teilweise Deine INT-Fragen bezüglich PIO beantworten sollte:

"Das Bit D7 des Wortes beeinflusst das Interruptfreigaberegister (Interruptenableflipflop) des programmierten Kanals. Bei Setzen dieses Bits (D7 = 1) erfolgt die Weitergabe von anhängigen Interruptanmeldungen, die durch die PIO-Interruptlogik ausgelöst wurden, an den Steuereingang INT der CPU U880. Bei rückgesetztem Bit D7 (D7 = 0) wird die Weitergabe dieser Anmeldung an die CPU verhindert. In diesem Fall wird aber eine durch die Peripherie ausgelöste Interruptforderung in der PIO abgespeichert. Wird das Interruptfreigabeflipflop des betreffenden Kanals im späteren Programmablauf wieder gesetzt (D7 = 1), gelangt dieser abgespeicherte Interrupt zur Anmeldung an die CPU. Diese Anmeldung erfolgt auch, wenn seitens der Peripherie dieser Interrupt nicht mehr aktuell ist (also die den Interrupt auslösende Bedingung aufgehoben ist). Die PIO reagiert hierbei unabhängig von der Art der Interruptanmeldung, die durch die Betriebsart des Kanals festgelegt wird. Eine anhängige Anmeldung geht aber verloren, wenn zum Zeitpunkt dieser Interruptforderung die PIO bereits eine Interruptbearbeitung hat (Interruptbearbeitungsflipflop der Kanallogik gesetzt) und das auslösende Ereignis zum Zeitpunkt der Rückkehr aus dieser ISR nicht mehr aktuell ist."

Vielleicht findest Du ja bei ihm auch schon vor dem KC-Treffen weitere Antworten zu CTC, SIO u.s.w., ist manchmal etwas unübersichtlich dort durch die vielen verschachtelten/verlinkten Unterseiten.

Seitenanfang

Seitenende

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

011
11.02.2009, 20:53 Uhr
jmueller

@susowa:
Das ist dein bisher bester Beitrag in diesem Thread!
Konkret und auf den Punkt gebracht beantwortet das exakt meine Frage!

@Guido:
Kommando zurück beim Buch-Verborgen,
Ich studiere erstmal diese Webseiten durch.
Wenn sich dann noch Unklarheiten bestehen,
melde ich mich wieder.

Jens

Seitenanfang

Seitenende

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

012
11.02.2009, 21:25 Uhr
ggrohmann

@Jens:

Alles klar!

Guido

Seitenanfang

Seitenende

Profil || Private Nachricht || Suche

Zitatantwort || Editieren || Löschen

Seiten: -1- [ Technische Diskussionen ]

Robotrontechnik-Forum

powered by ThWboard 3 Beta 2.84-php5
© by Paul Baecher & Felix Gonschorek