| Autor |
Flash EPROM
Suche nach: eprom (644) |
|
|
|
|
BID = 3473
Benedikt
Inventar
Beiträge: 6241
|
|
Dumme Frage:
Wie soll das gehen ?
Jeder 574 besitzt einen Clock Eingang.
Diese alle zusammen, und alle Register werden mit denselben Daten geladen ! |
|
BID = 3475
perl
Ehrenmitglied
Beiträge: 11110,1
Wohnort: Rheinbach
|
|
Hab ich doch weiter oben schon mal versucht mit Charaktergrafik zu malen.
Du verbindest die 8 Ausgänge eines Registers mit den 8 Eingängen des nächsten und dasselbe nochmal.
Auf die Weise erhältst Du 8 parallele 3-bit Schieberegister
8 Datenleitungen vom LPT
I7 I6 I5 I4 I3 I2 I1 I0
574
Q7 Q6 Q5 Q4 Q3 Q2 Q1 Q0
zum nächsten 574 und zu A0..A7 des PROM
I7 I6 I5 I4 I3 I2 I1 I0
574
Q7 Q6 Q5 Q4 Q3 Q2 Q1 Q0
zum nächsten 574 und zu A8..A15 des PROM
I7 I6 I5 I4 I3 I2 I1 I0
574 oder aus Geiz nur ein 7474
Q7 Q6 Q5 Q4 Q3 Q2 Q1 Q0
nur noch zu A16, A17 des PROM
|
|
BID = 3481
Benedikt
Inventar
Beiträge: 6241
|
Danke,
jetzt habe ichs kapiert.
Und das funkioniert auch sicher ?
Bei jedem Clock werden ja syncron die Daten an den Eingängen übernommen.
Wenn das erste die Daten etwa früher übernimmt als das nächste, dann bekommt das nächste auch die Daten vom ersten oder ?
|
BID = 3483
perl
Ehrenmitglied
Beiträge: 11110,1
Wohnort: Rheinbach
|
Du hast mal wieder Recht.
Der Teufel steckt aber bekanntlich im Detail. Ich hab vorsichtshalber nochmal nachgesehen. Der 74HC574 braucht 5ns tDataHold.
Clock der mittleren Stufe zu invertieren nutzt auch nix.
Jetzt bin ich auch bald soweit, daß ich mich hinter den Zug werfe.
[ Diese Nachricht wurde geändert von: perl am 2002-09-10 18:26 ]
[ Diese Nachricht wurde geändert von: perl am 2002-09-10 19:04 ]
|
BID = 3487
Benedikt
Inventar
Beiträge: 6241
|
Dann nehme ich den 2 zu 4 Dekoder und alles läuft prima.....
Dann kann ich die Daten auch getrennt in die Latches laden.
|
BID = 3490
perl
Ehrenmitglied
Beiträge: 11110,1
Wohnort: Rheinbach
|
So, jetzt versuch ichs hier noch zum letztenmal. Diesmal ohne das pdf File. Da ist mir jedemal der Upload steckengeblieben.
Also:
Ich habe auch eine, wie ich finde unschöne, Lösung für das tDataHold Problem.
Jeder halt wie er kann.
(Und jetzt eben kein Upload sondern: Mit nichtinvertierenden Buffern z.B. 2x 74HC04 die Clock zwischen den Registern etwas verzögern.
Ausbreitung der Clock entgegen der Datenrichtung)
|
BID = 3496
admin
Administrator
Beiträge: 5025
Wohnort: Heilbronn
| 
Hallo perl,
bitte mal die probleme mit upload kurz mitteilen, es wurde nichts an der software geändert.
danke
_________________
Mit zunehmendem Alter
braucht man auch Entkalker
BB
|
BID = 3497
perl
Ehrenmitglied
Beiträge: 11110,1
Wohnort: Rheinbach
|
Noch ein Upload Versuch.
Diesmal über t-Online.
Schließlich bezahl ich ja genug Gebühren.
Uploaded file: tHold.PDF
|
BID = 3498
perl
Ehrenmitglied
Beiträge: 11110,1
Wohnort: Rheinbach
|
Und es geht doch, die Clocks einfach zusammenzubinden!
Ich war auch sehr irritiert, denn Schieberegister sind intern auf genau die gleiche Weise aus MS-Flipflops aufgebaut und funktionieren schließlich auch.
Der Grund warum es funktioniert:
Auch wenn für die Eingangsdaten tDHold nach +Clock 5ns verlangt ist (0 wäre wünschenswert), so ist die Delay Clock-Output sehr viel größer.
Damit ist sichergestellt, daß das nachfolgende Register seine Eingänge schon abgeschaltet hat, wenn sich der Logikpegel dort ändert.
Die kapazitive Belastung der Ausgänge wirkt sich ausnahmsweise mal positiv aus, da sie weitere Reserven schafft.
|
BID = 4354
Benedikt
Inventar
Beiträge: 6241
|
Nochmals danke an alle.
Ich habe es jetzt etwas anderst gelöst, da die Adressänderungen wärend dem Schieben der Daten eventuell zu Problemen führen könnten.
Jetzt läuft alles Super !
Das Problem waren wirklich die 150us zwischen den Befehlen. Steht zwar nirgends im Datenblatt, dass diese auch bei Befehlen eingehalten werden müssen, aber naja.....
|
