ich stehe mal wieder auf der Leitung. Ich suche nach einer Lösung für 4 RS FF in einem 16V8. Und das ohne Clk. Es soll im Prinzip 4 Tasten an den Eingängen geben, welche ein korrespondierendes Ausgangspin einschalten. Eine 5. Taste ist quasi der Masterclear. Die Aufgabe ist: jede Taste schaltet einen Ausgang an. Ist schon irgendeiner an, so wird dieser rückgesetzt und der angeforderte Ausgang eingeschaltet.
In Palasm habe ich nur eine Lösung mit Takt gefunden.
Achja, die Ausgänge habe ich registered. Bei Latched gibt es Fehlermeldungen.
Leider wird da mit jeder steigenden Flanke, wenn der Tastendruck nicht mehr anliegt, auch der Ausgang wieder auf 0 geschaltet, da ja die Bedingungen in der Gleichung dies so verlangen. Ich vermute fast, es geht mit Moore - oder Mealey Automat. Aber darin bin ich überhaupt nicht fit. Kann mir da evtl. mal jemand helfen? Eine Lösung mit µC würde mir deutlich leichter fallen, nur möchte ich gerne (auch wegen des Lerneffektes) Oder gibt es eine statische Lösung, welche Taktunabhängig funktioniert? Manfred?...
In article , Ingo Liebe writes: |> Ich suche nach einer Lösung für 4 RS FF in einem 16V8. Und das ohne Clk.
Also 4 RS-Latches, keine FF...
|> Es soll im Prinzip 4 Tasten an den Eingängen geben, welche ein |> korrespondierendes Ausgangspin einschalten. Eine 5. Taste ist quasi der |> Masterclear. |> Die Aufgabe ist: jede Taste schaltet einen Ausgang an. Ist schon |> irgendeiner an, so wird dieser rückgesetzt und der angeforderte Ausgang |> eingeschaltet.
D.h. Highlander-Modus -- es kann nur einen geben, Selektion mehrerer Ausgänge gleichzeitig ist unmöglich und das Aktivieren eines neuen Ausgangs deaktiviert einen ggf. anderen aktiven Ausgang.
Mal so aus der Hüfte geschossen in low-level-VHDL da meine PALASM-Zeiten über 10 Jahre zurückliegen (und man PALASM auch nicht mehr unbedingt verwenden will, die alte Regel, daß VHDL nicht für kleine Bausteine geeignet ist, gilt schon lange nicht mehr):
-- Rücksetzsignale für jede Taste (Taste gedrückt = 1)
-- d.h. Wechselseitiges "Abschießen" incl. T5=alle aus r1
Hmm, ich muß ehrlicherweise gestehen, daß ich hier nur Bahnhof verstehe. Mit VHDL oder Abel habe ich mich noch nie befasst. Die PLD's habe ich bisher nur als Decoderchen eingesetzt, um TTL Gräber zu umgehen. Könntest Du mir das obige Beispiel mal genauer erklären? Ggf. per Mail. Ich müsste das dann nämlich noch in Palasm übersetzen, um an das .jed zu kommen.
Dann brauchst Du aber einen Takt, sonst passiert überhaupt nichts. Du mußt es also rein kombinatorisch machen, mit Selbsthaltung - ein Beispiel in Abel für 3 Taster:
Mir hat damals (so ca. 1992) "Logikbausteine - Grundlagen, Programmierung und Anwendung" (ISBN 3-87791-072-6) von Hans-Joachim Blank geholfen. Vielleicht gibt's das ja noch irgendwo im Antiquariat.
ich habe hier alternativ noch 1 Lösung, die den Vorteil hat, daß nur 1 Ausgang 1 sein kann, selbst wenn man mehrere Tasten drückt, wie man das von den sogenannten "Radiobuttons" kennt. Der Aufwand ist zwar etwas höher, scheint aber genau das zu machen was Du schreibst.
Die 4 RS-FFs habe ich highaktiv angenommen, das erreicht man am einfachsten durch 2 rückgekoppelte NOR-Gatter mit set und reset, Ausgang out hinter der Rückkopplung invertiert. Dann kann man 8 Gleichungen aufstellen:
Das müßte Deiner Syntax eigentlich entsprechen. Den Palasm kenne ich selbst nicht, wohl aber GAL-Assembler. Ob das in 1 GAL16V8 reinpaßt, weiß ich jetzt so nicht, am besten ausprobieren.
Der Master-Reset überfährt aber auch hier nicht andere gedrückte Tasten, könnte man aber sicher auch noch mit reinbringen. Kommt eben drauf an, was Du genau haben willst.
Obige Lösung habe ich intuitiv gefunden, sicher wird es in VHDL oder so auch einen algorithmischen Ansatz geben. Dazu muß man sich allerdings da reinarbeiten, was ziemlichen Aufwand bedeutet. Sicher kann man die 4 RS-FFs auch als Speicher eines Moore- oder Mealey-Automaten ohne Takt betrachten, ich fand hier scharfes Hinsehen aber einfacher.
Was Michael zu den Glitches schrieb, trifft hier natürlich auch zu. Es gibt verschiedene Strategien dagegen, die einfachste wäre vielleicht, D-FFs als Register hinter die Taster zu setzen, die sind im GAL ja schon drin. Man kann es auch mit delays ohne Takt machen, das würde aber wohl in ein GAL nicht reinpassen.
Falls Du mit Hardwarebeschreibungssprachen für CPLDs oder FPGAs arbeiten möchtest, ich benutze hier die XILINX ISE, davon gibt es eine kostenlose Evaluation-Version WEBPACK, aktuell müßte die 9.2 sein. Damit kannst Du Schaltpläne zeichnen, in VHDL oder Verilog programmieren und simulieren. Kleinere Chips kann man mit selbstgebautem "Downloadkabel III" (ganz einfache Schaltung über Parallelport) damit programmieren, wir machen das bei uns zur Übung oft. Aber wie gesagt, die Einarbeitung in solche Software ist ein ziemlicher Aufwand.
Falls Du Probleme haben solltest, das GAL zu programmieren, kann ich auch meinen Assembler mal anwerfen, bin da nur etwas raus.
Das entspricht genau der PALASM Syntax und auch meinem Entwurf. Leider funktionierte das schon in der Simulation nicht. Wie beschrieben gingen die Ausgänge der FF nach wegfallen des Tastendruckes mit der nächsten High - Flanke wieder auf 0. Daher der Gedanke, das ganze ohne Takt zu versuchen. Da blieben die Ausgänge aller FF auf High. Warum auch immer. Zumindest in der Simulation. Nun weiß ich nicht genau, wie stark man sich auf die Simulation verlassen kann. In Hardware habe ich es noch nicht aufgebaut.
Danke für's Angebot. Programmiertechnisch bin ich hier mit einem Galep IV ausgerüstet. Der brutzelt das .jed schon da rein. Ich denke, ich werde den Aufbau mal auf einem Breadboard machen. Evtl. brachte mich nur die Simulation ins Schleudern. Sooo schwer kann das ja wohl nicht sein.
Das sollte auch asynchron funktionieren, wobei aber manche Logikcompiler meckern könnten. Wenn Du Dir das aufmalst, wirst Du aber feststellen, dass das nichts anderes ist, als das klassische RS-FF, nur eben mit mehr als zwei Eingängen.
****----*-------*-------*-------*-------*-------*-------*-------*----*****\ Viele -- Volker Bosch \*****\ Gruesse aus -- E-Mail: snipped-for-privacy@t-online.de \*****\ Stuttgart --
also bei mir funktioniert die Behavioral-Simulation (ohne Laufzeiten), natürlich müßte man noch über mögliche Hazards (Glitches) nachdenken. Ich schreibe es mal vollständig hin:
Evtl. läßt sich da noch was vereinfachen, aber das kann man auch dem Assembler überlassen. Ich weiß nicht, ob das syntaktisch so richtig ist, mein GAL-Assembler schluckt das so auch noch nicht. Das ':=' heißt hier sequentielle Zuweisung, also speichern, '=' heißt kombinatorische Zuweisung.
Aber mir fällt grade auch auf, daß ein GAL16V8 weniger als 8 Rückkoppelungen erlaubt und hier sind es schon 12, geht so also nicht. Wäre auch zu einfach gewesen, bin etwas durch CPLDs verwöhnt :-/.
Versuch mal den Ansatz von Michael, oder den von Volker, hab ich mir zwar noch nicht angesehen, aber müßte eigentlich reingehen.
Hm - ich hatte zwar aus anderen Gründen ein CPLD in meinem Design, aber die Gleichungen auf 4 Taster gekürzt lassen sich problemlos in ein 16V8 fitten:
FF die auf Pegel reagieren heissen auch Latch ;). Man kann aber auch ohne externen Takt mit Taktflankengesteuertem FF arbeiten, wenn man sich den Takt intern erarbeitet.
he.
Die Bildung von r1 bis r4 geschieht durch Oder-Fkt. Immer wenn eine Taste gedr=FCckt wird sollen dadurch die anderen Latches auf '0' gesetzt werden. Jedes Latch soll gesetzt werden, falls der Eingang '1' ist und es nicht gerade r=FCckgesetzt werden soll. Das obige Beispiel hat leider ein paar Fl=FCchtigkeitsfehler, die evtl das Verstehen erschweren. Der Global_Reset soll die Latches beim Einschalten auf einen definierten Pegel bringen, fehlt aber in der Sensitivity-List und ist deshalb unn=F6tig. Ausserdem m=FCsste er in dem Device =FCberhaupt enthalten sein :). Kann aber mit dem Masterclear zusammengelegt werden.
Die Schaltung oben w=FCrde verhindern, dass ein Dr=FCcken auf t1 das Latch
1 setzt, solange auch t2-t5 aktiv sind.
Deine Schaltung hat das Problem, dass du die letzte gedr=FCckte Taste gespeichert haben willst, wodurch du gezwungen bist die steigende Flanke eines Signals zu erkennen, um damit den Zustand deiner Latches zu ver=E4ndern. Asynchron ist das etwas aufw=E4ndiger, da Signallaufzeiten alles durcheinander werfen k=F6nnen. Insbesondere, wenn zwei Flanken zu dicht aufeinander folgen k=F6nnen, ist die Gefahr gross, das die Schaltung Unfug macht.
Wieder in VHDL (motiviert evtl zum lernen *g*): Der generate-Block spart mehrmaliges Copy&Paste der identischen Zeilen f=FCr Input 0 bis 3.
-- Eingang Reset ist Masterclear, Input(0)-Input(3) sind die vier normalen Eing=E4nge
signal I_del : std_ulogic_vector(3 downto 0); -- input delayed signal Set : std_ulogic_vector(3 downto 0); -- setze Latch
ja das funktioniert. Nun hat es mich doch gepackt ;-) und ich habe meinen Vorschlag systematisch vereinfacht. Dazu habe ich eine Variante eines RS-FFs entworfen, die 2 Speicherzustände hat:
Das Verhalten ist genau gleich und funktioniert in der Simulation, nur sind lediglich 4 Rückkoppelungen nötig, was bei GAL16V8 gehen müßte. Der Vorteil ist, daß mclr alles überfährt und niemals mehr als 1 LED aktiv sein kann. Ich erinnere mich an ein Radio, bei dem ich alle Tasten gleichzeitig gedrückt habe und diese dann nicht mehr herausbekommen habe, erst nach Zerlegen der Tastatur ;-).
Ob das Ganze in ein GAL16V8 paßt, werde ich mir noch ansehen, im Moment bin ich da allerdings selber raus. Wenn es geht, werde ich für Ingo schreiben, worauf man beim GAL-Assembler achten muß.
Mal sehen, vielleicht schaue ich mir die VHDL-Variante von Rainer auch noch an.
Es geht in ein GAL16V8 rein, die Simulation zeigt auch nichts Unerwünschtes wie Glitches, vereinfachen lassen sich die Gleichungen auch nicht mehr. Das Verhalten beim gleichzeitigen Drücken mehrerer Tasten habe ich mir nicht so genau angesehen, dürfte hier aber kaum relevant sein. Soweit ich erkennen kann, ist immer nur 1 LED an und im schlimmsten Falle keine.
Soweit ich mich erinnere, ist beim 16V8 1 Ausgang nicht rückgekoppelt, auf den darf man keine LED legen, habe jetzt nur kein Datenblatt zur Hand. Es könnte auch herstellerabhängig sein. Die Gleichungen müssen natürlich kombinatorisch und nicht sequentiell zugewiesen werden, damit kein Register benutzt wird.
Bei der Pinbelegung hat der Assembler nicht gemeckert, müßte also gehen. Ich kenne zwar den Palasm nicht, aber der müßte das doch machen. Ich hatte auch Probleme, meinen Assembler samt Optimierer und Simulator zum laufen zu bringen, da die alte konsolenorientierte Software nicht sehr komfortabel zu bedienen ist und man lange lesen muß. Dafür lief das aber seinerzeit auch schon auf Atari, brauchte nur umkompiliert zu werden.
Manche Assembler wollen die Gleichungen schon in Produktform haben, dann muß man es etwas umschreiben:
Vielen Dank für das Engagement an alle. Ich hatte die letzten Tage keine Zeit, mal in die NG zu sehen. Ich werde am Wochenende mal die Vorschläge ausprobieren und in einen 16V8 brutzeln. Es ist nun gerade kein GAL sondern ein PALCE. Das sollte aber meiner Meinung nach kein Problem bereiten.
ja das hatte ich aber auch so verstanden, daß es erwünscht ist. Ich habe das mal so aufbereitet, daß es funktioniert und etwas modifiziert, daß es in der Post-Fit-Simulation genau dasselbe macht wie meine Lösung und unten angehängt. Von Glitches ist aber nichts zu sehen, es sieht sauber aus, müßte ich allerdings dann noch genauer untersuchen.
Beim gleichzeitigen Drücken oder Loslassen passiert bei mir nichts Unerwünschtes, die Schaltung ignoriert einfach die Signale. Eigentlich müßte man sich noch über Metastabilität Gedanken machen.
Hm, ich bin eigentlich in VHDL auf Anfängerlevel und kann Deinem Stil nicht ganz folgen. Daß man hier einen Takt braucht, kann ich nicht erkennen.
Ich habe mal das in der Post-Fit-Simulation getestete File unten drangehängt, implementiert in einem CPLD XC9572, keinerlei Unsauberkeiten erkennbar. Im Vergleich zu meiner Papier-Lösung benutzt der 4 D-FFs in 4 Macrozellen, spart also 2 Makrozellen ein und ist doppelt so schnell. Das Fitting in das CPLD klappt also sehr gut, die Schaltung mit den 4 D-FFs kann ich mir ansehen, läßt sich aber nicht in ein GAL übertragen, weil die solche Hardware nicht drin haben.
Mal sehen, wenn ich etwas Zeit habe, schaue ich mir mal Deinen Vorschlag an, um etwas über VHDL zu lernen.
mfg. Winfried
Hier ist das File:
-------------------
library ieee; use ieee.std_logic_1164.ALL; use ieee.numeric_std.ALL;
-- synopsys translate_off library UNISIM; use UNISIM.Vcomponents.ALL;
-- synopsys translate_on
entity radio_butn is port ( global_rst : in std_logic; t1 : in std_logic; t2 : in std_logic; t3 : in std_logic; t4 : in std_logic; q1 : out std_logic; q2 : out std_logic; q3 : out std_logic; q4 : out std_logic); end radio_butn;
-- modifiziertes Beispiel von Rainer Buchty architecture BEHAVIORAL of radio_butn is
signal r1: std_logic; signal r2: std_logic; signal r3: std_logic; signal r4: std_logic;
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.