Hallo,
ich möchte 8 Eingängen zu 3 Bit encodieren. Konkret geht es darum, aus 8
IRQ-Leitungen eine Interruptnummer zu bilden, ein IRQ-Signal
weiterzuleiten und auf Anfrage auf den Bus zu geben.
Der 74348 (8 to 3-line priority encoder with three-state outputs) geht
nicht direkt, da er die Eingänge im HiZ-Zustand ignoriert. Gibt es da
einen Baustein, den ich übersehen habe oder muss ich mir das mit einem
74148 und einem Latch plus Logik selbst zusammenbauen?
Optimal wäre ein umgekehrter 74138, die 3 Enable-Signale würden mir
zusätzliche Logik ersparen.
Gruß
Der Ausgang EO=L meldet beim 148 zumindest das "Nichts los ist" und alle
Eingänge auf H liegen... der MC68000 hat mit IPL0-IPL2 aber auch
passende Eingänge die nicht am Bus liegen.
Kannst Du mal konkreter werden wo Du das anknüppern willst?
Ich bekomme nicht auf die Reihe wieso Dich an den Ausgängen "Z" stört,
wenn keiner der Eingänge aktiv ist, in dem Falle wird doch auch kein
Vektor generiert bzw. benötigt?
Nochwas: Guck doch mal die alten Interruptcontroller der 8080 Serie an,
eventuell läßt sich Sowas ja "misusen". 8086 ist sicherlich zu
aufgeblasen.
Ich habe aber auch schon mal einen Z80-CTC an einen Z8000 Bus mit einem
GAL angehängt, nur weil ich einen Int-Vector Generator für einen
SCSI-Chip benötigte.
Guckstdu:
http://www.rabotavinternet.info/ebay_foto/datasheet/585IK14-8214.pdf
Gruß,
Holm
Hallo,
> Kannst Du mal konkreter werden wo Du das anknüppern willst?
Das soll an einen Z80A.
> Der Ausgang EO=L meldet beim 148 zumindest das "Nichts los ist"> und alle Eingänge auf H liegen...> Ich bekomme nicht auf die Reihe wieso Dich an den Ausgängen "Z" stört,> wenn keiner der Eingänge aktiv ist, in dem Falle wird doch auch kein> Vektor generiert bzw. benötigt?
Das stimmt. Wenn ein Interrupt generiert wird, muss ich die CPU
informieren (dafür kann ich GS=L verwenden) und dann warten, bis die CPU
den Vektor haben möchte (/M1 und /IORQ). Bis dahin müssen die Ausgänge
aber im Tristate bleiben.
Einen fertigen Interruptcontroller wollte ich eigentlich nicht benutzen,
weil in meiner Kiste nicht vorhanden.
Gruß,
Svenska
Svenska schrieb:> Das soll an einen Z80A.
Herrje. Erst einen auf Retro machen und dann auf das passende zünftige
Gattergrab verzichten wollen. Also das geht nunmal garnicht ;-)
> Herrje. Erst einen auf Retro machen und dann auf das passende zünftige> Gattergrab verzichten wollen. Also das geht nunmal garnicht ;-)
Hast ja recht.
Ich nehme einen 74148 für Vektor und /IRQ und einen 74541, um den Vektor
auf den Datenbus zu legen. ;-)
>Optimal wäre ein umgekehrter 74138,
Nö, MUX DeMUX geht gar nicht, weil kein Prio-Dekoder.
>Mit dem 74148 brauche ich noch ein zusätzliches Tristate-Latch, weil ein>Interrupt allein kein Grund ist, um die Daten auf dem Bus zu zerstören.
Nö. \E1 vom '148/'348 macht das.
Das ganze ist nicht trivial.
Interrupts sind asynchron.
Du mußt aber dafür sorgen, daß während der Abfrage des Interruptvectors
dieser stabil und auch gültig ist.
Ein einfacher priority encoder kann das nicht.
Ich hab sowas mal mit nem CPLD gemacht.
Ich frage mich nur warum er nicht die Z80 Peripherie zu diesem Zweck
mißbraucht. Diese kann ja, da zum System passend Vektoren generieren und
durch die Daisy Chain auch priorisieren. Ich würde die Ints simpel in
einer PIO oder in einem CTC zusammenfassen. Ich begreife auch nicht
wieso man heute noch ein Z80 System baut das 8 unterschiedliche
Interruptprioritäten unterstützt.. so viel zeitkritische Peripherie an
einem Z80?
>Einen fertigen Interruptcontroller wollte ich eigentlich nicht benutzen,>weil in meiner Kiste nicht vorhanden.
Hmm, Du baust den aber gerade zu Fuß..
Gruß,
Holm
Wenn man davon ausgeht, dass der INT-Eingang nicht noch gespeichert wird
(was der Normalfall ist (es ist auch Sache des Anwenders für stabile
INT-Sign zu sorgen)) ist es schon trivial. Bei INT zur CPU ruft diese
vom INT-Controller den INT-Vector ab, und fertig. Das geht mit 1..3
TTL-ICs.
>Ich begreife auch nicht>wieso man heute noch ein Z80 System baut das 8 unterschiedliche>Interruptprioritäten unterstützt..
Wo soll da das Problem sein? Es gibt ja nie zu viele
Interruptprioritäten, sondern ggfs nur zu wenige (bsp AVR).
Man muss auf zwei Schmutzeffekte achten:
(1) Spurious Interrupts gibts, wenn ein IRQ-Signal wieder verschwinden
kann, bevor der Prozessor zum Zuge kam. Bei mancher Peripherie lässt
sich das schlecht vermeiden, etwa bei den 16550 UARTs. Da kommt dann der
Vektor, der erzeugt wird, wenn alle Requests inaktiv sind.
(2) In seltenen Fällen kann ein falscher Vektoren erzeugt werden, wenn
die Requests nicht taktsynchron erzeugt werden, der Kram in dieser
Schaltung nur einfach synchronisiert wird und sich exakt zum falschen
Zeitpunkt etwas ändert (race condition).
>>Ich begreife auch nicht>>wieso man heute noch ein Z80 System baut das 8 unterschiedliche>>Interruptprioritäten unterstützt..>Wo soll da das Problem sein? Es gibt ja nie zu viele>Interruptprioritäten, sondern ggfs nur zu wenige (bsp AVR).
Ich war mehr darauf aus warum man sich einen Z80 für die Lösung dieses
Problems aussucht und dann auch noch dessen "normale" Umgebung, also die
dazugehörigen Peripherie-ICs die ja die Int-Logik enthalten .. nicht
verwenden möchte.
Ein Problem mit zu vielen Interruptprioritäten habe ich auch nicht.
Gruß,
Holm
Holm Tiffe schrieb:> Ich war mehr darauf aus warum man sich einen Z80 für die Lösung dieses> Problems aussucht und dann auch noch dessen "normale" Umgebung, also die> dazugehörigen Peripherie-ICs die ja die Int-Logik enthalten .. nicht> verwenden möchte.
Weil es an Wissen fehlt, was dieses Prozessorsystem leisten kann.
Ich müßte nachsehen, aber mit einer PIO kann man das Problem intelligent
lösen.
Die Frage steht natürlich noch, warum für eine Neuentwicklung ein Z80
genommen wird.
