Hallo, ich möchte mir einen 32Bit-Adresszähler aus drei 74hc590 aufbauen, bin mir aber nicht ganz sicher, ob ich das richtig geplant habe. Außer den Standardpins (Outputs, Vcc, Ground) hat der 74hc590 noch folgende Pins: CCK - Counter Clock Input (active HIGH) RCK - Register Clock Input (active HIGH) CCKEN - Counter Clock Enable Input (active LOW) G - Output Enable Input (active HIGH) GCLR - Counter Clear Input (active LOW) RCO - Register Carry Output (active LOW) Laut Datasheet muss RCO jeweils mit dem CCKEN des nächsten Zählers verbunden werden. Sehe ich das richtig, dass ich ... - CCKEN des ersten Zählers dauerhaft auf LOW setzen muss - alle G + alle GCLR an einen einzigen Pin meines µC anschliessen kann -> LOW = Outputs aus + Reset -> HIGH = Outputs wieder an - alle CCK + alle RCK auch an einen einzigen Pin anschliessen kann -> mit LOW->HIGH wird der Zähler dann um 1 erhöht Auf diese Weise würde ich nur 2 Pins meines µC brauchen. Die Outputs würden außerdem dem Eingangssignal dann doch einen Takt hinterherhinken. Also müsste ich nach einem Reset einmal CCK/RCK von L nach H setzen um auf 0 zu kommen, oder?
> ich möchte mir einen 32Bit-Adresszähler aus drei 74hc590 aufbauen, Nicht eher aus vier? > G - Output Enable Input (active HIGH) G ist active low (also /G): Ist G high, werden die Ausgänge hochohmig geschaltet. > Laut Datasheet muss RCO jeweils mit dem CCKEN des nächsten Zählers > verbunden werden. Das geht so einfach aber nur bei zwei ICs. Der /CCKEN des dritten muss an die OR-Verknüpfung aus den /RCOs der beiden ersten ICs und der /CCKEN des vierten an die OR-Verknüpfung der /RCOs drei ersten ICs angeschlossen werden. > - CCKEN des ersten Zählers dauerhaft auf LOW setzen muss Ja. > - alle G + alle GCLR an einen einzigen Pin meines µC anschliessen kann > -> LOW = Outputs aus + Reset > -> HIGH = Outputs wieder an G geht anders herum (s.o.). Ob es sinnvoll ist, bei der Deaktivierung der Ausgänge gleichzeitig einen Reset zu machen, hängt natürlich von deiner Anwendung ab. Was soll an die Ausgänge des Zählers angeschlossen werden? > - alle CCK + alle RCK auch an einen einzigen Pin anschliessen kann > -> mit LOW->HIGH wird der Zähler dann um 1 erhöht Ja. > Die Outputs würden außerdem dem Eingangssignal dann doch einen Takt > hinterherhinken. Also müsste ich nach einem Reset einmal CCK/RCK von L > nach H setzen um auf 0 zu kommen, oder? Ja. Um die Kaskadierung etwas zu vereinfachen (ohne die zusätzlichen OR-Gatter), kannst du alle /CCKENs auf Low legen und den CCLK jedes ICs mit dem /RCO des vorangehenden ICs verbinden. Der CCLK des ersten ICs wird mit der eigentlichen Taktquelle gespeist. Mit dieser einfacheren Lösung arbeitet der 32-Bit-Zähler aber nicht mehr synchron. Brauchst du unbedingt die synchrone Operation? Wenn nicht, und wenn du auch auf die Tristate-Ausgänge verzichten könntest, käme bspw. auch der 74HC4040 (12 Bit) in Frage. Dann bräuchtest du statt 4 nur 3 ICs bei gleicher Gehäusegröße. Er hat auch kein (in deinem Fall) störendes Ausgangsregister, sondern gibt nach dem Reset sofort die 0 aus.
Jein. Zumindest brauchst Du vier Stück 590er. >- CCKEN des ersten Zählers dauerhaft auf LOW setzen muss ja >- alle G + alle CCLR an einen einzigen Pin meines µC anschliessen kann > -> LOW = Outputs aus + Reset > -> HIGH = Outputs wieder an ja, die Ausgänge werden aber erst nach RCK-Impuls verändert - alle CCK + alle RCK auch an einen einzigen Pin anschliessen kann -> mit LOW->HIGH wird der Zähler dann um 1 erhöht ja Wenn man RCO mit 'ripple clock output' entziffert, wird dessen Funktion deutlicher. Synchrone Zähler brauchen diesen Ausgang zur Freigabe des nächsten Zählers.
@yalu
Du warst schneller!
>Das geht so einfach aber nur bei zwei ICs.
Bist Du wirklich sicher? Aus der hohlen Hand gesprochen, war das bei
uralten Zählern wohl notwendig. Die neueren Bausteine kann man m.E. ohne
zusätzlichen Aufwand kaskadieren.
Sicher bin ich mir aber nicht.
Tietze-Schenck, 4.Auflage, S.496: Zähler (74161) werden ohne Zusatzbeschaltung synchron kaskadiert. Eine Zusatzschaltung aus Gattern war - glaube ich - notwendig, um asynchrone Zähler synchron zu kaskadieren und damit die Durchlaufzeit zu verbessern. Alles so lange her.
Gast schrieb: >> Das geht so einfach aber nur bei zwei ICs. > Bist Du wirklich sicher? Ich war ;-) Im Datenblatt von TI steht nämlich: "Expansion is accomplished easily for two stages by connecting RCO of the first stage to CCKEN of the second stage. Cascading for larger count chains can be accomplished by connecting RCO of each stage to the counter clock (CCLK) input of the following stage." Im Logic-Diagramm ist /RCO einfach die NAND-Verknüpfung der 8 Flipflop-Ausgänge. Auf diesen Informationen fußt mein oben Geschriebenes. Nachdem du mich aber verunsichert hast, habe ich noch das Datenblatt von Hitachi gesaugt. Dort steht: "For cascading a ripple carry output R CO is provided. Expansion is easily accomplished by tying R CO of the first stage to CCKEN of the second stage, etc." Im Logic-Digramm sind im Gegensatz zum TI-Diagramm die 8 Flipflop- Ausgänge und zusätzlich das invertierte /CCKEN NAND-verknüpft. In diesem Fall kann man die ICs tatsächlich ohne zusätzliche Logik über /RCO kaskadieren. Die Frage ist nun natürlich, welches der beiden Datenblätter richtig ist. Oder bauen die beiden Hersteller tatsächlich unterschiedliche ICs? Immerhin heißen sie auch leicht unterschiedlich, bei TI SN74HC590A und bei Hitachi HD74HC590, wobei ein 'A' am Ende normalerweise eher die fortschrittlichere Variante anzeigt. Ich habe kein 590er da, sonst würde ich das einfach mal ausprobieren.
> Tietze-Schenck, 4.Auflage, S.496: > Zähler (74161) werden ohne Zusatzbeschaltung synchron kaskadiert. Ja, im Tietze-Schenk ist die Schaltung so gezeigt wie im Hitachi-Datenblatt. So ist das ja auch viel sinnvoller, und das eine zusätzliche Gatter wird die Chip-Fläche sicher nicht sprengen. Also ein Fehler bei TI (entweder im Datenblatt oder im IC)?
Ich habe mir mal ein Datenblatt zum xx161 herausgesucht. Dort findet man noch eine Tabelle der "Wahrheit". RCO wird aktiv, wenn intern der Zähler auf 15 steht. Das macht die Sache deutlicher.
Weil ich diesen Widerspruch doch etwas beängstigend fand, habe ich bei verschiedenen Herstellern in den Datenblättern nachgeschaut, ob laut Text bzw. laut Diagramm eine Kaskadierung von mehr als zwei ICs ohne externe Logik möglich ist. Hier das Ergebnis:
1 | Hersteller Bezeichnung Text Diagramm |
2 | ------------------------------------------ |
3 | TI SN74HC590A nein nein |
4 | Hitachi HD74HC590 ja ja |
5 | Toshiba TC74HC590A nein nein |
6 | ST M74HC590 ja nein |
7 | NXP 74HC590 nein nein |
Interessant ist das Datenblatt von ST: Der Text lautet gleich wie bei Hitachi (s.o.), das Diagramm sieht aber so aus wie bei Toshiba, was funktional dem von TI entspricht. Ich habe immer geglaubt, Datenblätter stellen so eine Art Referenz dar und sind (zumindest bei so einfachen Schaltungen) immer fehlerfrei ;-) > RCO wird aktiv, wenn intern der Zähler auf 15 steht. Das macht die > Sache deutlicher. Unabhängig vom Clock-Enable? Dann hätte dein Tietze-Schenk gelogen.
Hallo, ich habe zwar aus der Fragestellung rausgelesen, daß er ein SRAM per Adresszähler von einem µC ansteuern will, um Pins zu sparen. Den Typ des µC, die Zugriffszeit des Rams und damit die gewünschte Geschwindigkeit finde ich aber nicht. Wenn es z.B. ein AVR mit 16MHz Takt wäre, ist es ziemlich egal, on die Zählerkaskade komplett asyncron, teilweise syncorn oder komplett syncron läuft. Die einzige kritische Zeit wäre dann die maximale Zeit zwischen letztem Clock-Impuls zum Erreichen der gewünschten Adresse bis zum stabilen Zustand an allen Zählerausgängen. Dann käme noch die Zugriffszeit des Ram dazu bis die Daten gültif sind. Ob während des Zählens ungültige Zwischenzuständen auftreten wäre dann egal. Komplett syncrone Zähler werden dann interessant, wenn mit konstanter möglichst kleiner Verzögerungszeit jede beliebige Adresse angesprchen werden soll, also maximale und konstante Geschwindigkeit gefordert wäre. Für ihn also die maximale Laufzeit durch alle Zähler + Zugriffszeit des Rams. Diese Zeit zwischen letzten Clock und dem Lesen einhalten und es geht. Gruß aus Berlin Michael
>Unabhängig vom Clock-Enable? Nein, dieser ist implizit immer aktiv :-) Von Renesas habe ich ein Datenblatt gefunden, wo der interne Aufbau sehr konfus wirkt. Im Zweifelsfall suche ich immer bei NXP (Philips). Hier ist die interne Logik übersichtlicher gezeichnet: http://www.standardics.nxp.com/products/hc/datasheet/74hc590.pdf >..(zumindest bei so einfachen Schaltungen) immer fehlerfrei ;-) Leider nein. Selbst bei einfachsten Schaltungen wie HC14 oder 4093 sind die Hysteresen je nach Hersteller verschieden. Oder nimm den 74HC4046. Die einen schaffen gerade 5MHz bei 5V, wo hingegen Onsemi über 15MHz kommt und NXP sogar über 20MHz. Mit NS habe ich die schlechtesten Erfahrungen gemacht. @Michael Ich würde synchrone Logik immer bevorzugen; es gibt keinen Grund, dies nicht zu tun. Im Gegenteil: bei asynchroner Logik wird auf jeden kurzzeitigen Zwischenstand reagiert, der zu Spikes und undefinierten Zuständen führt. @Martin Die Gans für den 11. ist schon im Kühlschrank :-)
Danke für die vielen Antworten. Wie schon richtig vermutet, ist der Adresszähler für einen SRAM (55ns). Angesteuert wird er nur mit einem 16Mhz AVR, also muss er wohl nicht komplett synchron laufen. Wenn ich also auf Nummer sicher gehen will, sollte ich ihn wie folgt benutzen? - alle /CCKEN auf Low - /RCO mit CCK des jeweils nachfolgenden Zählers - ein einziger Outputpin des AVR an den ersten CCK und an alle RCK
Hallo, Gast wrote: > @Michael > Ich würde synchrone Logik immer bevorzugen; es gibt keinen Grund, dies > nicht zu tun. Im Gegenteil: bei asynchroner Logik wird auf jeden > kurzzeitigen Zwischenstand reagiert, der zu Spikes und undefinierten > Zuständen führt. Prinzipiell auch meine Meinung, aber: er will per AVR und Zähler mit einem SRAM reden. Der 590 ist ein 8-stufiger Zähler, mögliche voll syncrone Varianten ist z.B. der 161. Der ist aber nur 4 stufig. Damit steht dann die Entscheidung entweder doppelt soviele 161 oder 590 mit zusätzlichen Gattern. Wenn es schnell sein muß blieb ohnehin nur der 161 übrig. Meine Suche nach syncronen Teilern endete immer wieder dort, anere waren entweder unverhältnismäßig teuer, nicht sinnvoll beschaffbar oder beides. FPGA o.ä. stand nicht zur Debatte. Da entscheide ich mich dann auch für asyncron, zumal die Auswirkungen nicht stören. Dem SRAM ist es egal, ob da zwischendurch wild die Adressen wechseln, er leifert dann eben nur unsinnige Daten ab. Wenn der Zählerstand erreicht ist, muß eben genau dort gewartet werden, bis die Pegel stabil sind und dann gelesen oder geschrieben werden. Wenn das in der konkreten Anwendung realisierbar ist und nicht stört, warum dann nicht asyncron? Gruß aus Berlin Michael
@ martin (Gast) >Danke für die vielen Antworten. Wie schon richtig vermutet, ist der >Adresszähler für einen SRAM (55ns). Angesteuert wird er nur mit einem >16Mhz AVR, also muss er wohl nicht komplett synchron laufen. Wie kommst du darauf? Und willst du deinen SRAM schnarchlangsam ansteuern? Alles per Software? Reichlich sinnfrei. Nimm einen AVR mit externem SRAM-Interface 8515 oder andere haben das. Schliess den SRAM direkt nach Datenblatt an. Damit kannst du knapp 64 kB adressieren. Wenn du mehr brauchst, nimm einen weiteren freien Port und steuer damit die oberen Adressbits an. Damit kannst du eine sog. Bankumschaltung machen. Der Vorteil liegt auf der Hand. Du hast einfachen und schnellen Zugriff auf den SRAM. MFG Falk
@Falk Brunner: Er schreibt von einem 32-Bit-Adresszähler. Das sieht nicht so aus, als wolle er mit dem SRAM den Datenspeicher des AVR erweitern. @martin: Hui, da fällt mir gerade auf: 32 Bit sind ja eine ganze Menge. Damit kannst du 4G Worte adressieren. Ich weiß nicht, was aktuell die größten SRAM-Bausteine sind, aber für 4Gx8 oder gar 4Gx16 brauchst du sicher eine ganze Tüte davon :) Soll das vielleicht ein Soft-LA, -Speicheroszi, -DDS, -Audiorecorder/ -player oder so etwas in diese Richtung werden? > - alle /CCKEN auf Low > - /RCO mit CCK des jeweils nachfolgenden Zählers > - ein einziger Outputpin des AVR an den ersten CCK und an alle RCK Ja, so sollte das gehen. Und noch einmal zurück zu meinem Kommentar von oben: Brauchst du zur Adressierung des SRAM unbedingt die Tristate-Ausgänge am Zähler? Wenn nicht dann nimm doch drei 74HC4040. Du brauchst weniger Bauteile, die Adressausgabe ist nicht um einen Takt verzögert und du kannst mit den 36 Bit sogar 64G adressieren.
@ yalu (Gast) >Er schreibt von einem 32-Bit-Adresszähler. Das sieht nicht so aus, als >wolle er mit dem SRAM den Datenspeicher des AVR erweitern. Naja, siehe dein eigener Kommenar . . . >kannst du 4G Worte adressieren. Ich weiß nicht, was aktuell die größten >SRAM-Bausteine sind, aber für 4Gx8 oder gar 4Gx16 brauchst du sicher >eine ganze Tüte davon :) Eben. Solche Datenmengen baut keiner mit SRAM auf, schon gar nicht mit TTL Klapperlogik. >Adressausgabe ist nicht um einen Takt verzögert und du kannst mit den 36 >Bit sogar 64G adressieren. Mit Relaisklappergeschwindigkeit. @OP Was soll das Ganze denn werden? MFG Falk
>Da entscheide ich mich dann auch für asyncron, zumal die Auswirkungen >nicht stören. Dem SRAM ist es egal, ob da zwischendurch wild die >Adressen wechseln, er leifert dann eben nur unsinnige Daten ab. Schwerer Irrtum: jeder Adresswechsel spiegelt sich in der Stromaufnahme wieder und verursacht durchaus Störungen. Man merkt es nur nicht, außer wenn es zu spät ist. @Martin Möglicherweise benötigst Du garnicht soviele Adressleitungen, wie yalu angedeutet hatte. Aber: laß Dich nicht verunsichern und betreibe die HC590 wie ursprünglich geplant. Synchrone Zähler betreibt man am sichersten synchron.
> Schwerer Irrtum: jeder Adresswechsel spiegelt sich in der > Stromaufnahme wieder und verursacht durchaus Störungen. Man merkt es > nur nicht, außer wenn es zu spät ist. Gerade was Stromspitzen u.ä. betrifft, ist es doch günstiger, alle Adressleitungen nacheinander zu schalten, wie es bei einem asynchronen Adresszähler der Fall wäre. Beim Synchronzähler kommt der Stromstoß zwar seltener, dafür aber umso heftiger. Der Vorteil des Synchronzählers für martins Anwendung liegt vor allem darin, dass er weniger Zeit braucht, um nach einer Taktflanke alle Ausgänge in den neuen Zustand zu bringen. Gerade bei großen Bitbreiten (32) kann der Übergang von 0xffffffff nach 0x00000000 bei einem reinen Asynchronzähler schon recht lange dauern. Dewegen nehme ich auch meinen obigen Vorschlag mit den 74HC4040 (bis zu 670ns Durchlaufzeit bis zum 32. Ausgang) ein Stückchen zurück ;-). Mit AC-Typen (ca. 125ns) geht es schon besser. Wenn der AVR allerdings nichts anderes tut, als mit maximaler Geschwindigkeit den CCK zu toggeln (125ns Periodendauer), wird es auch damit knapp. Knapp wird es in diesem Fall aber auch mit vier kaskadierten 74HC590, da hier der Durchlauf vom CCK bis zum /RCO des vorletzten ICs 3*40ns=120ns dauert, dazu kommt noch die interne Laufzeit im letzten IC, so dass die Schaltung insgesamt sogar eher langsamer ist als die mit den drei 74AC4040. Mit vier 74AC590 sollte es aber auch bei einer Taktperiode von 125ns gehen. Die Frage ist halt, wie schnell das ganze Gedöns tatsächlich laufen muss und wieviele Adressleitungen tatsächlich gebraucht werden.
>...ein Stückchen zurück ;-). Das reicht mir aber nicht :-) >..der Durchlauf vom CCK bis zum /RCO des vorletzten ICs 3*40ns=120ns Der Vorteil der synchronen Zähler ist, daß sich die Durchlaufzeiten gerade NICHT addieren. Meine "Lieblings HC590" von NXP haben eine Durchlaufzeit von unter 20ns bei 5V. Typische Zählfrequenz ist damit >50MHz - gerade auch für längere Zähler!
@ Gast (Gast) >Der Vorteil der synchronen Zähler ist, daß sich die Durchlaufzeiten >gerade NICHT addieren. Jain. Die Carry Chain addiert sich schon, je nach Typ. OK, das kann man auch mit Pipelining machen, ob das die TTL-ICs machen weiss ich nicht. MFG Falk
> Meine "Lieblings HC590" von NXP haben eine Durchlaufzeit von unter > 20ns bei 5V. Die von mir angegebenen 40ns sind der Maximalwert bei 25°C aus dem Hitachi-Datenblatt (NXP gibt leider nur typische Werte an). > Typische Zählfrequenz ist damit >50MHz - gerade auch für längere > Zähler! Nein, 50MHz gehen nur bei einem oder zwei Bausteinen, nicht bei Kaskaden. Zwar schalten bei beliebig langen Kaskaden die Ausgänge immer gleichzeitig um, wenn man sie synchron kaskadiert, trotzdem darf die nächste Taktflanke erst kommen, nachdem der /RCO nacheinander alle Bausteine durchlaufen hat, sonst stolpert der Zähler. Apropos NXP: Wenn das dein Lieblingslieferant für den 590er ist, dann weißt du doch sicher, ob man damit mehr als zwei Bausteine über /RCO und /CCKEN kaskadieren kann (s. Diskussion weiter oben), was ja lt. NXP-Datenblatt nicht geht. Denn nur damit ließen sich Zähler aus mehr als zwei Bausteinen ohne Zusatzaufwand synchron realisieren.
>Die Carry Chain addiert sich schon, Nein (s.u.); Carry Chain, kann man das essen? >... nachdem der /RCO nacheinander alle Bausteine durchlaufen hat, Und nochmals: nein. >was ja lt. NXP-Datenblatt nicht geht. Bei NXP heißt die Taktfreigabe /CE (siehe Verweis aufs Datenblatt weiter oben). Hier kann man keinen Takt anlegen. Das meint das Datenblatt! Zur Kaskadierung kann man aber den /RCO-Ausgang an CPC anlegen und /CE konstant auf '0' lassen. Damit wird die Zählerkette asynchron, braucht aber nur eine Leitung zur Kaskadierung (/RCO -> CPC). Da /CE nur eine Taktfreigabe ist und nicht in das Ergebnis von /RCO eingeht, entscheidet nur die Verzögerung von CPC -> /RCO über die Geschwindigkeit der Zählerkaskade. Diese Verzögerung findet zwar in jedem Zählerbaustein statt, aber gleichzeitig zu den anderen Zählern in der Kette. Synchrone Zähler sind eine feine Sache!
> Da /CE nur eine Taktfreigabe ist und nicht in das Ergebnis von /RCO > eingeht, entscheidet nur die Verzögerung von CPC -> /RCO über die > Geschwindigkeit der Zählerkaskade. Diese Verzögerung findet zwar in > jedem Zählerbaustein statt, aber gleichzeitig zu den anderen Zählern > in der Kette. Wieso gleichzeitig? /RCO hängt vom aktuellen Zählerstand des jeweiligen ICs ab. Erst wenn die Flipflops des ersten ICs alle umgeschaltet haben und das 8-fach-NAND durchgeschaltet hat, wird über die /RCO-CPC- Verbindung das zweite IC getaktet. Dort dauert wieder es eine gewisse Zeit, bis die Flipflops umgeschaltet haben und das 8-fach-NAND durchgeschaltet hat usw. Es ensteht also in jedem IC eine Verzögerung, die sich zusammensetzt aus der Verzögerung der CPC-Eingangslogik, dem Umschalten der Flipflops und der Verzögerung des 8-fach-NANDs. Bei n-facher Kaskadierung addieren sich diese Verzögerungen n-mal. Das Einzige, was parallel läuft, ist das Umschalten der 8 Flipflops innerhalb jedes einzelnen ICs. Deswegen ist der 75HC590 ja auch schneller als bspw. der 74HC4040. Das ändert aber nichts an der Tatsache, dass sich bei Kaskadierung die Verzögerungen addieren. Kürzer wäre die Verzögerung pro IC, wenn, wie im Hitachi-Datenblatt gezeigt, der invertierte /CE bzw. /CCKEN an einen neunten Eingang des /RCO-NAND-Gatters angeschlossen wäre (eigentlich kein großer Aufwand). Dann würde man die Kaskadierung über /RCO->/CE vornehmen, und der Takt ginge an alle ICs parallel. Somit erfolgte das Umschalten der Flipflops aller ICs parallel, so dass die Verzögerung der Eingangslogik und das Umschalten der Flipflops bei einer beliebig langen Kaskade nur einmal auftritt. Aber auch dann muss die Verzögerung bei der /RCO-Generierung n-fach gerechnet werden. Ein n-stufiger Synchronzähler, dessen Geschwindigkeit unabhängig von n ist, erfordert nun einmal einen Bauteilaufwand von O(n²) und kann deswegen durch einfache Kaskadierung gleicher Bauteile (O(n)) nicht realisiert werden. Umgekehrt erreicht man mit einem Bauteilaufwand von O(n) bestenfalls eine Verzögerungszeit von O(n). Um das mal etwas geekish auszudrücken ;-)
@ yalu (Gast) >realisiert werden. Umgekehrt erreicht man mit einem Bauteilaufwand von >O(n) bestenfalls eine Verzögerungszeit von O(n). Um das mal etwas >geekish auszudrücken ;-) Meine Rede, eine Carry Chain ist eine Carry Chain, auch wenn der Begriff eher bei Addierern als Zählern auftaucht. MFG Falk
>wird über die /RCO-CPC- >Verbindung das zweite IC getaktet. Dort dauert wieder es eine gewisse >Zeit, bis die Flipflops umgeschaltet haben und das 8-fach-NAND >durchgeschaltet hat usw. Das ist eine asynchrone Kaskadierung! Synchron läuft die Zählerkette, wenn alle CPC zusammengeschaltet den Takt bekommen, der /CE des 1. Zählers auf '0' liegt und der /CE-Eingang des nächsten Zählers an /RCO der vorangehenden angeschlossen wird. Bei jedem neuen CPC-Takt muß /RCO des vorausgehenden Zählers gültig sein. Und dies passsiert gleichzeitig in jedem Zähler mit 'propagation delay CPC to /RCO'. /RCO ist nur abhängig vom internen Zählerstand und nicht von /CE. Ich wiederhole mich ständig, möchte aber nicht, daß hier falsche Informationen unwidersprochen stehen bleiben. Positiv bemerken möchte ich, daß Martin mit seiner "Anfängerfrage" schon die richtige Beschaltung von mehreren Zählern formuliert hat. Wie es scheint, ist das nicht selbstverständlich.
@Gast: Ich glaube, wir reden teilweise ein wenig aneinander vorbei, weil (zumindest mir) auf Grund der widersprüchlichen Datenblattangaben immer noch nicht klar ist, wie denn nun die ICs kaskadiert werden müssen, ob asynchron über /RCO-CPC oder synchron über /RCO-/CE. In meinem letzten Post habe ich deswegen beide Möglichkeiten beschrieben. >> wird über die /RCO-CPC-Verbindung das zweite IC getaktet. Dort dauert >> wieder es eine gewisse Zeit, bis die Flipflops umgeschaltet haben und >> das 8-fach-NAND durchgeschaltet hat usw. > > Das ist eine asynchrone Kaskadierung! Richtig. Und genau diese empfiehlt NXP bei der Kaskadierung von mehr als 2 ICs. > Synchron läuft die Zählerkette, wenn alle CPC zusammengeschaltet den > Takt bekommen, der /CE des 1. Zählers auf '0' liegt und der /CE-Eingang > des nächsten Zählers an /RCO der vorangehenden angeschlossen wird. Richtig. Allerdings funktioniert diese Verschaltung nach NXP-Datenblatt nur für 2 ICs. > Bei jedem neuen CPC-Takt muß /RCO des vorausgehenden Zählers gültig > sein. Richtig. > Und dies passsiert gleichzeitig in jedem Zähler mit 'propagation > delay CPC to /RCO'. > /RCO ist nur abhängig vom internen Zählerstand und nicht von /CE. Laut NXP-Datenblatt ist es genau so. Und genau das ist der Grund, warum die Kaskadierung von mehr als 2 ICs auf diese Weise nicht funktioniert. Bei der synchronen Kaskadierung darf der Takt eines ICs nur dann freigegeben werden, wenn der Zählerstand sämtlicher vorangehender ICs 0xFF ist, also alle Ausgänge 1 sind. Laut NXP ist /RCO die NAND-Verknüpfung der 8 Zählerbits. Dies bedeutet, dass der Takt eines ICs schon dann freigegeben wird, wenn nur der Zählerstand des direkten Vorgängers 0xFF ist. Das ist bei 2 ICs ok, aber bei >2 ICs zu wenig, denn es müssen alle Vorgänger berücksichtigt werden. Ein Ausweg besteht darin, den invertierten /CE-Eingang ebenfalls in die NAND-Verknüpfung der 8 Zählerbits mit einzubeziehen, wie im Hitachi-Datenblatt. Damit lassen sich beliebig viele ICs synchron kaskadieren, allerdings nimmt die maximal mögliche Zählfrequenz mit wachsender Anzahl von ICs ab, da in diesem Fall die /RCO-Generierung jedes ICs vom /RCO des Vorgängers abhängt. Soll die maximale Zählfrequenz unabhängig von der Anzahl ICs sein, muss man an den /CE-Eingang jedes ICs die OR-Verknüpfung der /RCOs aller vorangehender ICs legen. Das erfordert dann aber externe Logik. Zusammenfassung: Man kann bei der Kaskadierung mehreren 74HC590 zwischen vier Alternativen auswählen: 1. Asynchrone Kaskadierung über /RCO - /CPC. Nachteile: Zählerausgänge schalten nicht gleichzeitig, Verzögerung bis zum Umschalten der Zählerausgänge des letzten ICs hängt von der Anzahl kaskadierter ICs ab. 2. Synchrone Kaskadierung über /RCO - /CE mit ICs gemäß NXP-Datenblatt. Nachteil: Funktioniert für mehr als 2 ICs nicht. 3. Synchrone Kaskadierung über /RCO - /CE mit ICs gemäß Hitachi- Datenblatt. Nachteil: Maximale Zählfrequenz hängt von der Anzahl kaskadierter ICs ab. 4. Synchrone Kaskadierung über /RCO* - OR-Gatter - /CE (/RCO* = /RCOs aller Vorgänger). Nachteil: Zusätzlicher Bauteilaufwand. Ich hoffe, dass die Sache jetzt etwas klarer geworden ist. Immer noch unklar ist allerdings, ob die 74HC590 von NXP und Hitachi tatsächlich funktional unterschiedlich sind, oder ob nur eines der beiden Datenblätter fehlerhaft ist. > Ich wiederhole mich ständig, möchte aber nicht, daß hier falsche > Informationen unwidersprochen stehen bleiben. Geht mir genauso ;-) > Positiv bemerken möchte ich, daß Martin mit seiner "Anfängerfrage" > schon die richtige Beschaltung von mehreren Zählern formuliert hat. > Wie es scheint, ist das nicht selbstverständlich. Bleibt für ihn nur zu hoffen, dass er keine NXP-ICs benutzt, oder dass das NXP-Datenblatt fehlerhaft ist, sonst fällt er auf die Nase.
@yalu Du hast Recht, und ich weiß warum :-) Nach anfänglicher Unsicherheit konnte ich mich daran erinnern, in den 70ern Zähler aus 8 x 74LS160 synchron zusammengeschaltet zu haben. Diese funktionierten bis deutlich über 20MHz, wobei die typische Grenzfrequenz eines einzelnen ICs bei 25MHz lag. Nachdem ich im T&S meine Schaltung im Prinzip wiedergefunden habe, war mein Glaube unerschütterlich. Knackpunkt ist der, daß die 74LS160 den Übertrag des vorhergehenden Zählers in den eigenen /RCO eingebunden haben, so wie es der xx590 von Hitachi/Renesas macht. Daher hatte es bei mir damals funktioniert. NXP (und auch STM) hingegen erzeugen /RCO allein aus dem eigenen Zählerstand, was ich natürlich für meine Argumentation sehr begrüßt habe. In Gedanken war ich mir sicher, daß bei einem Zählerstand von 0xFFFFFFFF mit dem nächsten Zählimpuls der Zähler auf 0x00000000 stehen würde. Durch Herauspicken der Rosinen kam ich so zu meiner wunderbaren Lösung :-) Jetzt könnte ich mich natürlich irren, die xx160 seinerzeit mit einheitlichem Takt zählen gelassen zu haben. Zum Auslesen der Zählerkette hatte ich diese aber als 4Bit Schieberegister verschaltet, sodaß alle Clock-Eingänge zwangsläufig miteinander verbunden sein mußten. Fazit: Für Martin heißt das dann, zur Kaskadierung den /RCO des Zählers an den CPC des nachfolgenden zu legen, wobei alle /CE auf '0' geschaltet werden. Die xx590 sind allemal schnell genug. Und was heißt das für uns? Nichts mehr glauben, was man nicht selbst gesehen hat und - früher war alles besser :-)
> Für Martin heißt das dann, zur Kaskadierung den /RCO des Zählers an > den CPC des nachfolgenden zu legen, wobei alle /CE auf '0' geschaltet > werden. Die xx590 sind allemal schnell genug. Genau. Oder, wenn er möchte, kann er die ersten beiden ICs (IC1 und IC2) synchron kaskadieren, den Rest (IC3 und IC4) asynchron. Dann wird das Ganze noch etwas schneller. Also: - CCK von IC1 und IC2 und RCK von allen ICs gemeinsam an eine µC-Ausgang (Zähltakt) - /G von allen ICs an VCC - /CCKEN von IC1, IC3 und IC4 an GND - /CCKEN von IC2 an /RCO von IC1 - CCK von IC3 an /RCO von IC2 - CCK von IC4 an /RCO von IC3 - /RCO von IC4 bleibt offen - /CCLR von allen ICs gemeinsam an einen µC-Ausgang (Zähler zurücksetzen) Die Pin-Namen sind wie in Martins erstem Post, also anders als bei NXP, sollte aber leicht zu transferieren sein. > Nichts mehr glauben, was man nicht selbst gesehen hat und - früher war > alles besser :-) So isses. Bei diesem neumodischen IC-Kram weiß doch eh keiner mehr, was da wirklich drin steckt :) Ich habe übrigens ein 74LS590 von TI ausgegraben und nachgeprüft, ob /CCKEN tatsächlich keinen Einfluss auf /RCO hat. Dazu habe ich den Zähler mit Hilfe mordernster Mikrocontrollertechnik ;-) bei /CCKEN=low bis 0xFF zählen lassen. /RCO wechselt beim Zählerstand von 0xFF wie erwartet von high nach low und bleibt auch dann auf low, wenn man (bei auf 0xFF stehendem Zähler) /CCKEN auf high setzt. Demnach stimmen die Angaben im Datenblatt von TI. Interessant wäre es, den Test mit einem IC von Hitachi/Renesas, das sich laut Datenblatt anders verhalten müsste, zu wiederholen. Leider habe ich kein Renesas-IC im Zugriff.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.