Ich komme gerade mit einem toten Vollverstärker nicht weiter, den ich gerne wiederbeleben möchte. Er besteht aus 3 Platinen: Controller, Power-Amp und Vorverstärker. Die Funktionen des Vorverstärkers (also Quellenwahl und Lautstärkeregelung) werden von drei kaskadierten 74HC4094 Schieberegistern gesteuert, die Daten/Takt/Strobe vom Prozessor (bzw. dem letzten der drei SR, die sich bereits auf dem Controller-Board befinden) bekommen. Daten werden jeweils von QS zum nächsten SR weitergegeben, die einzelnen SR hängen hintereinander an der gleichen Taktleitung. Da die Z80-CPU auf dem Controller-Board gestorben war, habe ich sie durch einen AVR ATmega ersetzt. Mein Problem ist nun, dass die Schieberegister auf dem Vorverstärker-Board die Daten um genau einen Takt weiter schieben, als sie sollten. Da die Leitungslänge vom Prozessor bis zum letzten SR fast 50cm ist (und zudem noch über 2 Flexkabel respektive 4 Steckverbinder läuft), habe ich mir die existierenden Threads zum Thema "SR an langer Leitung" reingezogen, aber als Nicht-vom-Fach-Mann leider nicht alles davon so gut verstanden, dass ich mir das Phänomen jetzt erklären könnte. Daher meine Bitte um eure Hilfe ;) Das am häufigsten in solchen Zusammenhängen genannte Problem ist die Terminierung der Taktleitung - die hier zu fehlen scheint. Jedenfalls habe ich keine entdecken können und im (offiziell nicht verfügbaren) Schaltplan fehlt sie auch. Das gibt also 'ne satte Reflexion am Ende Leitung. Die Low-High-Flanke zeigt an meinem 100MHz-Oszi ein leichtes Überschwingen. Soweit - so gut. Aber das kann ja nun nicht dazu führen, dass das 4. bis 6. SR in der Kaskade in einer Taktfolge genau einen Takt mehr sehen als die ersten drei, oder irre ich mich da? Die Taktfolge an sich ist übrigens langsam. Was ich eher verstehen würde, wäre folgendes: wenn der Dateneingang des 4. SRs seinen Taktimpuls erst zu einem Zeitpunkt erkennt, zu dem das vorangehende SR seinen QS-Ausgang bereits geshifted hat, ergibt sich das was ich beobachte. Nur - wo soll diese Verzögerung herkommen??? Und dann nur auf der Taktleitung und nicht in gleicher Weise auf der Datenleitung, sonst würde sich der Effekt ja wieder aufheben. Liege ich damit richtig? Und wie sähe dann die Lösung des Problems aus? Bitte seid so nett und lasst Antworten der Art: "mach einfach 'ne Terminierung ran und gut isses". Kann sein, dass das so ist. Ich möchte aber vor allem verstehen, was da im Detail passiert und wie das schaltungstechnisch a) idealerweise und b) in meinem Fall am einfachsten zu lösen ist. Vielen Dank schon mal im Voraus ;) Ralph
Angehängte Dateien:
Moin Moin, naja, wenn es wirklich zu Reflektionen auf der Clock-Leitung kommt, dann kann es durchaus sein, dass eines oder mehrere SR die Reflexion als Clock-Puls verstehen. Überschwinger bei der Low-High Flanke sind vermutlich nicht so das Problem. Die Frage ist aber auch, was und wie Du da eigentlich misst. Ich würde da mal ein Rechteck draufgeben und dann am Anfang und am Ende der Clock-Leitung messen. Wenn es Reflexionen gibt, solltest Du die so sehen können. Außerdem könntest Du testweise ja mal CLK--->240R--->120pF--->GND hinter das letzte SR schrauben. Das wäre eine Terminierung.
Ralph K. schrieb: > Das am häufigsten in solchen Zusammenhängen genannte Problem ist die > Terminierung der Taktleitung - die hier zu fehlen scheint. Ja, führt zu gestörten Taktflanken. > im (offiziell nicht verfügbaren) > Schaltplan fehlt sie auch. Das Gerät ist schon älter (Z80), die CPU ist mit einer deutlich langsameren Technologie gefertigt, die Flanken haben größere Anstiegs-/Abfallzeiten. Deshalb ging es damals. > Die Taktfolge an sich ist übrigens langsam. Die Taktfrequenz ist egal, entscheidend sind die Flankensteilheit zusammen mit der Leitungslänge und den Stichleitungslängen. > Was ich eher verstehen würde, wäre folgendes: wenn der Dateneingang des > 4. SRs seinen Taktimpuls erst zu einem Zeitpunkt erkennt, zu dem das > vorangehende SR seinen QS-Ausgang bereits geshifted hat, ergibt sich das > was ich beobachte. Nur - wo soll diese Verzögerung herkommen??? Kann passieren, wenn die Datenleitung deutlich länger ist als die Taktleitung. Dem kann man auch damit begegnen, dass man den Takt am letzten FF einspeist, die Daten natürlich am ersten. > Bitte seid so nett und lasst Antworten der Art: "mach einfach 'ne > Terminierung ran und gut isses". Terminierung mag hier helfen. Aber warum willst du gerade das ausschließen? Vielleicht ist auch dein neuer Prozessor nicht in der Lage, so viele Eingänge sinnvoll zu treiben. > Kann sein, dass das so ist. Ich möchte > aber vor allem verstehen, was da im Detail passiert Höchstwahrscheinlich Reflexionen, die zu einer Doppelflanke im Takt führen. Abhilfe ist tatsächlich in erster Linie eine Terminierung. > und wie das > schaltungstechnisch a) idealerweise Idealerweise wäre eine echte Taktverteilung die sicherste Lösung. Jedes FF (meinetwegen auch zwei oder drei, die räumlich sehr nahe beieinander sind) bekommt eine eigene Taktleitung mit quellseitiger Serienterminierung. In deinem Fall: zumindest das Vorverstärkerboard müsste so mit einem extra gepufferten Takt versorgt werden. Z.B. so:
1 | +-BUF--33Ω----- Controller |
2 | | |
3 | Taktquelle --o |
4 | | |
5 | +-BUF--33Ω----- Vorverstärker |
Vielleicht geht das auch ohne den Buffer (z.B. CD4050), nur mit den getrennten, serienterminierten Leitungen. Das hängt einfach von dem mir unbekannten räumlichen Aufbau ab. Und immer schön darauf achten, dass die Taktleitung nicht kürzer ist als die Datenleitung. > und b) in meinem Fall am einfachsten zu lösen ist. Siehe oben oder: Beknnerschreiben schrieb: > Außerdem könntest Du testweise ja mal CLK--->240R--->120pF--->GND hinter > das letzte SR schrauben. Das wäre eine Terminierung.
Ralph K. schrieb: > Da die Z80-CPU auf dem Controller-Board gestorben war, habe ich sie > durch einen AVR ATmega ersetzt. Hast Du nur den Z80 ersetzt oder auch die Peripherie-ICs? Die Z80-Peripherie wird hochohmiger gewesen sein, d.h. langsamere Flanken. Häng mal in Reihe zu SCK, MOSI und Latch des AVR Widerstände (47..470R).
Mal die Versorgungsspannung der Schieberegister mit dem Oszi angeschaut? Vielleicht kommt es hier beim Umschalten zu Spannungseinbrüchen, möglicherweise durch defekte Elkos.
So, jetzt bin ich weitergekommen. Eine Terminierung der Taktleitung hat in der Tat das praktische Problem gelöst :) Aber nicht das theoretische. Denn es handelt sich ja um eine 48 Bit lange Taktfolge. Ich verstehe nicht wie es sein kann, dass da genau ein Bit zu viel weitergeschoben wurde. Denn Leitungsreflexionen wirken sich ja auf jede Taktflanke aus. Und da außerdem die einzelnen Taktimpulse mit 2µs gefühlte Ewigkeiten auseinanderliegen, scheint es mir unwahrscheinlich zu sein, dass es ausgerechnet die erste oder letzte Flanke in besonderer Weise betrifft. Ich bin übrigens vorher noch nie auf die Idee gekommen, mir mal so 'ne Taktleitung mit dem Oszi genauer anzuschauen. Ausgesprochen lehrreich - kaum zu glauben, was da alles drauf los ist :D
Ralph K. schrieb: > Ich verstehe nicht wie es sein kann, dass da genau > ein Bit zu viel weitergeschoben wurde. Ohne aussagekräftige Oszilloskop-Bilder können wir auch nur raten.
Ralph K. schrieb: > Ich verstehe nicht wie es sein kann, dass da genau > ein Bit zu viel weitergeschoben wurde. Denn Leitungsreflexionen wirken > sich ja auf jede Taktflanke aus. Und da außerdem die einzelnen > Taktimpulse mit 2µs gefühlte Ewigkeiten auseinanderliegen, scheint es > mir unwahrscheinlich zu sein, dass es ausgerechnet die erste oder letzte > Flanke in besonderer Weise betrifft. Die Reflexionen wirken sich natürlich auf jede Flanke aus. Das heißt aber nicht zwingend, dass es bei jeder Taktflanke auch sicher schief geht. Du hast ja mit den Empfängern zwangsweise eine örtliche Ausdehnung mit mehr oder weniger kurzen Stubs, die dann lokal auch was dazu beitragen - im positiven wie im negativen Sinn. Heißt: ein FF sieht 'ne Doppelflanke, das andere nicht, zumindest keine ausreichend groß ausgeprägte. Dein übrig gebliebenes Problem könnte auch andere Ursachen haben. - Du schiebst einen Takt mehr raus als notwendig ... - Du hast ein Problem in der Pause mit der Ruhelage des Taktes und dem jeweiligen Neubeginn; z.B. dadurch, dass du am Ende den Takt zwar auf z.B. LOW lässt, aber beim Neubeginn ihn erst mal auf HIGH setzt, um dann anzufangen. Ralph K. schrieb: > Bitte seid so nett und lasst Antworten der Art: "mach einfach 'ne > Terminierung ran und gut isses". Das hat sich damit auch relativiert ... :-)
Ralph K. schrieb: > So, jetzt bin ich weitergekommen. Eine Terminierung der Taktleitung hat > in der Tat das praktische Problem gelöst :) > > Aber nicht das theoretische. Dann wäre es jetzt an der Zeit, zu verstehen, warum deine Taktterminierung geholfen hat. Hast du mal versuchsweise QS* als Ausgang für den Übertrag benutzt und dir die Signale auf dem Logikanalysator angeguckt? Dann könntest du hier beide Versionen mal zeigen. > Ich bin übrigens vorher noch nie auf die Idee gekommen, mir mal so 'ne > Taktleitung mit dem Oszi genauer anzuschauen. Ausgesprochen lehrreich - > kaum zu glauben, was da alles drauf los ist :D Dann klemm dein Oszi zum Vergleich mal unter Verwendung einer Massefeder direkt an der Prüfspitze an ...
HildeK schrieb: > - Du schiebst einen Takt mehr raus als notwendig ... > - Du hast ein Problem in der Pause mit der Ruhelage des Taktes und dem > jeweiligen Neubeginn; z.B. dadurch, dass du am Ende den Takt zwar auf > z.B. LOW lässt, aber beim Neubeginn ihn erst mal auf HIGH setzt, um dann > anzufangen. Nein nein, der Logikanalysator sagt mir, dass da alles in Ordnung ist :) Wolfgang schrieb: > Dann klemm dein Oszi zum Vergleich mal unter Verwendung einer Massefeder > direkt an der Prüfspitze an ... Hab' schon ;) Wolfgang schrieb: > Hast du mal versuchsweise QS* als Ausgang für den Übertrag benutzt > und dir die Signale auf dem Logikanalysator angeguckt? Das wäre mein nächster Versuch gewesen, denn vom Timing her wäre das ja eigentlich die zu bevorzugende Variante. Aber SMD-Beinchen einzeln ablösen und dann quer verdrahten macht nicht wirklich Spaß :D Keine Ahnung warum die Entwickler da QS statt QS* genommen haben. Ich denk mal, dass ich das Thema jetzt zu den Akten lege. Herzlichen Dank für Eure Antworten!
Ralph K. schrieb: > Keine Ahnung warum die Entwickler da QS statt QS* genommen haben. Vermutlich weil im Datenblatt steht, das QS1 für schnelle Flanken die richtige Wahl ist. Im anderen Fall sollte dann das Problem trotz deiner Terminierung auftreten. ("Data is available at QS1 on the LOW-to-HIGH transitions of the CP input to allow cascading when clock edges are fast. The same datais available at QS2 on the next HIGH-to-LOW transition of the CP input to allow cascading whenclock edges are slow.")
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.