Forum: Mikrocontroller und Digitale Elektronik umgekehrter 74138 mit Tri-State?


von Svenska (Gast)


Lesenswert?

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ß

von (prx) A. K. (prx)


Lesenswert?

Fürs IRQ-Signal tuts ein 8-Input (N)AND. Den Encoder brauchst du nur für 
den Vektor.

von Holm T. (Gast)


Lesenswert?

Ich denke der 74148 ist  das was Du suchst. Der wird auch in MC68K 
Systemen als Int-Priority-Encoder eingesetzt.

Gruß,

Holm

von Svenska (Gast)


Lesenswert?

Dann brauche ich zusätzliche Logik für das IRQ-Signal und für die 
Enable-Leitung. Die wollte ich mir eigentlich ersparen...

von (prx) A. K. (prx)


Lesenswert?

Selber bauen mit CPLD. Wird wohl nicht die einzige Zusatzlogik sein.

von Svenska (Gast)


Lesenswert?

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

von Holm T. (Gast)


Lesenswert?

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

von Svenska (Gast)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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

von Svenska (Gast)


Lesenswert?

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

von MCUA (Gast)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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.

von Holm T. (Gast)


Lesenswert?

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

von MCUA (Gast)


Lesenswert?

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

von (prx) A. K. (prx)


Lesenswert?

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

von Holm T. (Gast)


Lesenswert?

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

von Michael_ (Gast)


Lesenswert?

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.

von Holm T. (Gast)


Lesenswert?

...Du meinst MIR fehlt das Wissen über den Z80? ..lach... ich bin mit 
dem Ding "aufgewachsen" ... oder meinst Du den TO?

Gruß,

Holm

von Michael_ (Gast)


Lesenswert?

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
Noch kein Account? Hier anmelden.