Forum: Mikrocontroller und Digitale Elektronik 74HC595: unsauberes Timing beim Kaskadieren?


von Hans-Jürgen E. (Firma: Esch Projekt) (eschprojektberlin)


Lesenswert?

Hallo liebe Experten!

Gibt ja auch hier jede Menge Beiträge zu den Schieberegistern HC595 - 
auf eine Merkwürdigkeit ist glaube ich noch nicht eingegangen worden:

Beim Kaskadieren meherer HC595 werden der ShiftOut "SH´" des ersten 
(oder weiterer) Schieberegister mit dem Serial-Input "SER" des zweiten 
(oder weiterer) verbunden. Shift-Clock "SRCLK" und Latch-Clock "RCLK" 
werden parallel versorgt.

Der am Serial-Input anliegende Logikpegel wird mit jeder L/H Flanke von 
Shift-Clock ins Schieberegister übernommen. Beim ersten Schieberegister 
sorgt man per Software dafür, dass vor dieser L/H-Flanke der Pegel am 
Serial-Input stabil ist. Eine perfekte Lösung sieht einen Wechsel des 
Pegels am Serial-Input vor, wenn Shift-Clock low ist (1. Bit) oder 
unmittelbar nach einer H/L-Flanke (folgende Bits).

Shift-Out wechselt den Pegel nun bei einer L/H-Flanke. Dem zweiten (ggf. 
3., 4...) Schieberegister werden also just Daten angeboten, die bei 
Shift-Clock L/H wechseln und etwa zeitgleich eingetaktet werden sollen.

Mit derartiger Hardware konfrontiert, wäre meine Kritik mindestens 
schlecht designt oder fehlerhaft und störanfällig.

Liege ich mit meiner Analyse völlig daneben oder hat jemand eine 
Erklärung? Immerhin scheint es ja in der Praxis meist zu funktionieren. 
Und wie könnte man einfach Abhilfe schaffen?

Herzlichen Dank für Euer Engagement!

von Martin O. (ossi-2)


Lesenswert?

Das gleiche Problem tritt bei einem Schieberegister auf.
Der Eingang der n+1sten Stufe übernimmt bei der Flanke
den alten Zustand der n-ten Stufe. Das klappt, weil
die Ausgänge eine gewisse hold-time haben, und die Eingänge
entsprechende Setup Grenzen.

von Falk B. (falk)


Lesenswert?

@ Hans-Jürgen Esch (Firma: Esch Projekt) (eschprojektberlin)

>Der am Serial-Input anliegende Logikpegel wird mit jeder L/H Flanke von
>Shift-Clock ins Schieberegister übernommen. Beim ersten Schieberegister
>sorgt man per Software dafür, dass vor dieser L/H-Flanke der Pegel am
>Serial-Input stabil ist.

Kann man machen, ist aber nicht zwingend.

>Eine perfekte Lösung sieht einen Wechsel des
>Pegels am Serial-Input vor, wenn Shift-Clock low ist (1. Bit) oder
>unmittelbar nach einer H/L-Flanke (folgende Bits).

Das ist die gängige Variante, wenn gleich sie eher ein praxisnaher 
Workaround ist.

>Mit derartiger Hardware konfrontiert, wäre meine Kritik mindestens
>schlecht designt oder fehlerhaft und störanfällig.

Falsch. So arbeiten fast alle synchronen Systeme. Datenübernahme und 
Ausgabe erfolgt auf der gleichen Taktflanke. Denn die Daten brauchen 
immer ein paar ns, um nach der Taktflanke den Pegel zu wechseln (clock 
to out time). Andererseits brauchen FlipFlops und in diesem 
Speziellen Fall die Schieberegister auch nur wenig Haltezeit der Daten, 
nachdem die aktive Taktflanke eingetroffen ist (hold time). Damit das 
alles sauber läuft, muss jedoch die Taktverteilung sauber sein. Der 
Workaround mit Datenwechsel auf der einen und Datenübernahme auf der 
anderen Flanke ist praktisch zwar robuster, kaschiert aber ggf. 
Signalprobleme. Außerdem halbiert er die maximal mögliche Taktfrequenz, 
was aber in den meisten Fällen unkritisch ist.

>Und wie könnte man einfach Abhilfe schaffen?

Saubere Taktverteilung.

von Peter D. (peda)


Lesenswert?

Hans-Jürgen E. schrieb:
> Mit derartiger Hardware konfrontiert, wäre meine Kritik mindestens
> schlecht designt oder fehlerhaft und störanfällig.

Nö.
Das ist das gleiche, als wenn Du mehrere D-FF 74HC74 als Schieberegister 
schaltest.
Zwischen Flanke am Eingang und Änderung am Ausgang, hast Du eine 
deutliche Laufzeit (Eingangspuffer->Register->Ausgangspuffer), d.h. der 
Ausgang ändert sich spät genug, um die minimale Datenhaltezeit nicht zu 
verletzen.

Der CD4094 hat noch einen Ausgang auf die entgegengesetzte Flanke, den 
darf man aber nur bei sehr langsamen Takt benutzen.

von Mw E. (Firma: fritzler-avr.de) (fritzler)


Lesenswert?

Zoom doch mal näher rein beim Oszi ob es die Zeiten im Datenblatt 
verletzt.
Tipp: tuts nicht, alles anderes ist nur Ästhetik.

von Dietrich L. (dietrichl)


Lesenswert?

Martin O. schrieb:
> Das gleiche Problem tritt bei einem Schieberegister auf.
> Der Eingang der n+1sten Stufe übernimmt bei der Flanke
> den alten Zustand der n-ten Stufe. Das klappt, weil
> die Ausgänge eine gewisse hold-time haben, und die Eingänge
> entsprechende Setup Grenzen.

Daher muss die Anstiegszeit des Taktes "Sytemgeschwindigkeit" haben, 
d.h. in der Größenordnung sein, wie ein Ausgang gleicher Technologie 
schaltet.

Begründung:
Weil der Schaltpunkt des Takteingangs exemplarabhängig Toleranzen hat, 
schalten nicht alle ICs bei der gleichen Spannung. Die Taktflanke darf 
also nicht zu langsam sein, damit die Zeit zwischen den 
Schaltzeitpunkten verschiedener Schieberegister immer kleiner ist als 
Laufzeit + Haltezeit.

von Peter (Gast)


Lesenswert?

Hans-Jürgen E. schrieb:
> Liege ich mit meiner Analyse völlig daneben oder hat jemand eine
> Erklärung? Immerhin scheint es ja in der Praxis meist zu funktionieren.
> Und wie könnte man einfach Abhilfe schaffen?

Du liegst richtig. Du kannst die Clock Leitung am Ende der 
Schieberegister einspeisen. Die Flanke des Clocks wandert vom Ende zum 
Anfang, die Daten umgekehrt vom Anfang zum Ende. Dadurch wird das 
Problem entschärft.

von Hans-Jürgen E. (Firma: Esch Projekt) (eschprojektberlin)


Lesenswert?

zunächst mal ganz herzlichen Dank für Eure interessante und erhellenden 
Beiträge und Anmerkungen!

Auf die Idee, mich etwas näher mit dem von mir schon häufig eingesetzten 
595 zu beschäftigen lag an einem, wie ich jetzt sehe, selbst 
geschaffenen Problem: Der Shift-Clock wird in dem vorliegenden System 
(HighEnd Audio) auf mehrere Platinen über Flachbandkabel verteilt. Um 
Einstreuungen durch steile Taktflanken ins sensible Audiosystem zu 
vermeiden, habe ich a) die Clockfrequenz niedrig gehalten und b) über 
ein R/C-Glied schön verschliffen. Beim jeweils ersten 595 funktioniert 
das auch wunderbar, aber dann gibt's gelegentlich merkwürdige Effekte. 
Der Hinweis mit den bauteilbedingten Streuungen liefert mir eine gute 
Erklärung.

von HildeK (Gast)


Lesenswert?

Hans-Jürgen E. schrieb:
> b) über ein R/C-Glied schön verschliffen.

RC-Glieder haben in einem digitalen Design nichts verloren. Und schon 
gar nicht bei Taktsignalen!
Auch ein Verteilen von einem Taktsignal auf mehreren Platinen 
erfordert Zusatzmaßnahmen. Ein einfaches Zusammenschalten wird nicht 
zuverlässig funktionieren - wenn überhaupt.

von Hans-Jürgen E. (Firma: Esch Projekt) (eschprojektberlin)


Lesenswert?

HildeK schrieb:
> Hans-Jürgen E. schrieb:
>> b) über ein R/C-Glied schön verschliffen.
>
> RC-Glieder haben in einem digitalen Design nichts verloren. Und schon
> gar nicht bei Taktsignalen!

Stimmt, besondere Anforderungen (Störfreiheit) erfordern jedoch 
besondere Maßnahmen.

> Auch ein Verteilen von einem Taktsignal auf mehreren Platinen
> erfordert Zusatzmaßnahmen. Ein einfaches Zusammenschalten wird nicht
> zuverlässig funktionieren - wenn überhaupt.

Ist im Bereich der Steuerung von Audioschaltungen erprobt und sicher, 
sofern nur eine Anzahl nicht kaskadierter Schieberegister verwendet 
werden.

von HildeK (Gast)


Lesenswert?

Hans-Jürgen E. schrieb:
> Stimmt, besondere Anforderungen (Störfreiheit) erfordern jedoch
> besondere Maßnahmen.

Das C führt nicht zur Störfreiheit, sondern zu Störungen beim 
Empfängertakteingang (ich nehme mal an, das RC-Glied ist quellseitig 
angebracht). Reflexionen vom Ende der Leitung werden an dem besagten C 
erneut reflektiert und können eine doppelte Taktflanke verursachen. 
Schon erlebt!

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.