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ß
Fürs IRQ-Signal tuts ein 8-Input (N)AND. Den Encoder brauchst du nur für den Vektor.
Ich denke der 74148 ist das was Du suchst. Der wird auch in MC68K Systemen als Int-Priority-Encoder eingesetzt. Gruß, Holm
Dann brauche ich zusätzliche Logik für das IRQ-Signal und für die Enable-Leitung. Die wollte ich mir eigentlich ersparen...
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. :-)
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.
...Du meinst MIR fehlt das Wissen über den Z80? ..lach... ich bin mit dem Ding "aufgewachsen" ... oder meinst Du den TO? Gruß, Holm
Nein, du nicht! Meinte den TO. Bist doch auch ein Vertreter der PIO-Version.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.