Hallo! Ich habe ein Problem mit der Kaskadierung von Schieberegistern am Atmel: Der Aufbau: Jeweils ein 74HC595 + ULN2803 steuern eine 100mm 7-Segment Anzeige. Diese Schaltung habe ich jetzt 10mal gebaut, jeweils in ein Gehäuse gepackt und die Steuerleitungen der Schieberegister über SUB-D nach aussen geführt. Die Zusammengesteckten Schieberegister sind dann wie im AVR Tutorial beschrieben hintereinander geschaltet (Serielle Daten durchgeshiftet, Clocks parallel) Angesteuert wird das Ganze von einem ATMEGA8 der über UART jeweils ein Zeichen liest und das Equivalent als Byte in das erste Register shiftet. Jetzt zum Problem: Mit 7 aneinandergesteckten Anzeigenkästen (also 7 Schieberegister) funktioniert alles. Kommt ein achtes Register hinten dran, entstehen ab dem 5. Register fehlerhafte Ausgaben. Diese Fehler sind immer identisch und reproduzierbar und werden "korrekt" weitergeshiftet (wenn z.B. Ein bit von 1 nach 0 gekippt ist, bleibt es beim weiterschieben auch im nächsten Register 0) Das Verrückte: Ich kann keine guten oder schlechten Platinen ausmachen, also Platinen die in 5er Gruppen funktionieren zeigen in 8er Gruppe Fehler, usw. Ich verzweifle langsam. Ein Fehler in der Software kann sich doch eigentlich nur auf das erste Register auswirken, aber es kann kein Fehler in einem Späteren erzeugt werden. Also ein Schirmungs- Störungs- Masseproblem? Da hätte ich ein mehr zufälliges Verhalten erwartet, nicht so berechenbar. Wenn ich gleich nach Hause komme poste ich mal die Schaltpläne, evtl. Hat ja bis dahin schon jemand einen Tip... Gruss, Kolja
Jede angesteckte Platine stellt für die Ansteuerung eine Last dar und bring noch zusätzlich eine längere Leitung (kap. Last und Reflexionen). Mit dem Oszilloskop die Signalqualität an CLock und Strobe prüfen, mit einer Platine, 2 Platinen, 3 Platinen ... usw. Da zeigt sich dann, ob Dein Design für 8 und mehr Platien geeignet ist.
Versuche schon händeringend, mir für morgen irgendwo ein Oszi auszuleihen... Sagen wir, die Clocks sind nicht mehr sauber, läßt sich das zwischen Atmel und erster Platine beheben? Also zum Beispiel durch eine zusätzliche Signalverstärkung? Oder muss ich dann das ganze Design über den Haufen werfen?
zus. zu den Ausführungen von Kurz: es könnte auch ein Problem der Masseführung sein. Der Laststrom der Anzeigen hebt den Massepegel der Module.
Schau Dir doch erst mal die Signale an, such nach der Ursache für den Fehler und entscheide dann, was zu tun ist. Wie lang ist denn das Clock und Strobe-Signal ? Wenn die Flanken verschliffen sind und nicht mehr High-Pegel erreichen, könnte schon eine zeitliche Verlängerung des Signals günstig sein. Hängt natürlich von der Art der Eingangsbeschaltung auf den Platinen ab. Hoffe es sind Schmitt-Trigger verwendet... Also erst Signale beurteilen, dann über die Maßnahmen nachdenken, alles andere ist das Pferd von hinten aufgezäumt.
Gute Anmerkung! Hatte ich noch gar nicht erwähnt: Ich habe vorhin Delays in meinen Code gebastelt. Sah dann etwa so aus: - Ein Bit für Serielle Leitung setzen, Serialclock Low - 1 Sekunde warten - serielles Bit halten, Serial Clock High - 1 Sekunde warten - nächstes Bit für Serielle Leitung setzen, Serialclock Low - 1 Sekunde warten - serielles Bit halten, Serial Clock High - 1 Sekunde warten ... nach jeweils acht Bit habe ich den Storage Clock getaktet. Dabei wieder zwischen allen Bitveränderungen eine lange Wartezeit. Das fehlerverhalten war exakt das Selbem, wie bei schneller Verarbeitung. Es wurden die selben Bits an der selben Stelle "vergessen". Ich poste gleich Code und Chaltung, suche grade alles zusammen.
Die Delays sind horrender Blödsinn. Damit änderst Du nichts an derTtaktlänge Deiner Signale, nichts an der Ausgangsleistung deiner Treiberschaltung, nichts an Leitungslängen, nichts an Masseführung, nichts an irgendetwas relevantem. Oszi -> Singnale anschauen -> beurteulen -> verbessern Alles andere ist Quatsch, Spekulation, Kristallkugelschauen, und nur frustrierend für Dich.
@kurz: Öhm, natürlich sind keine Schmitt-Trigger drin! Ich musste bis vor wenigen Sekunden auch noch nicht, was das ist, aber Wikipedia hat mich gerade aufgeklährt. Wenn ich sicher weiß, das die Signale vermurkst werden kann ich aber jeweils zwischen den Platinen noch eine solche Triggerschaltung einbauen. Dann muss ich die mühevoll geätzen Platinen nicht wegwerfen.
Wie lange ist denn die Gesamtleitung? Sind die ICs abgeblockt per 100nF Kerko? Bei langer Signalleitung mal versuchen mit 100pF KerKo an den Signalen. Ohne Oszi /Analizer ist das natürlich blöd. Oder in der Ausgaberoutine ist ein Array zu kurz geraten. Johann
kurz schrieb:
> Damit änderst Du nichts an derTtaktlänge Deiner Signale [...]
Natürlich ändert er die Taktlänge, wenn er dazwischen immer eine Sekunde
wartet. Damit hat er zumindest schonmal auf einfache Weise
ausgeschlossen, daß es an der Geschwindigkeit liegt, mit der er die
Daten in die Register schiebt.
Oder meintest Du vielleicht gar nicht die Taktlänge, sondern die Länge
der Taktflanken? Die ändert sich natürlich nicht.
Johann L. schrieb:
> Oder in der Ausgaberoutine ist ein Array zu kurz geraten.
Dann wären die Daten schon im ersten Register falsch und nicht erst
weiter hinten in der Kette.
Ist leider ein Problem aller '595... Hatte auch schon damit zu kämpfen. Auf einem PCB gehts normalerweise aber wenn mehrere PCB's ins Spiel kommen kanns kritisch werden. Delays bringen dir nichts... Das Problem ist dass das die Bits auf die gleiche Clk Flanke rausgeschoben werden wie sie auch beim nachfolgendem 595 am Eingang gelesen werden. Abhilfe schaft ein zusätzliches Latch zwischen den verschiedenen 595er. Dieses Latch sichert dir den alten Zustand für den nächsten 595. Hab leider meine Dokumentation (Scope Bilder) nicht da ich das für einen Kunden untersucht habe. Vieleicht rückt er die raus, dann kann ich das hier posten. Cheers
Wäre natürlich alles halb so schlimm, wenn die Anzeigetafel die so entstehen sollte nicht am Wochenende zum Einsatz kommen sollte. Vielen Dank schonmal für die vielen Antworten, so ein aktives Forum ist wirklich eine feine Sache. Ich hab jetzt 13 Stunden darüber nachgegrübelt, gelesen, ausprobiert. Heute werd ich die vielen Dinge von denen ich keine Ahnung habe nicht mehr nachlesen und verstehen können. Morgen früh fräse ich mich durch die verschiedenen Ansätze zur Bereinigung der Taktflanke. Wenn ich es schaffe, bis abends alle nötigen Bauteile zu beschaffen kann das noch klappen.
Also ich habe mit den HC595 eine Infotafel gebaut. Zehn Stk. HC595 auf einer Platine und 6 Platinen mit jeweils 20cm Flachkabel verbunden (die Stromversorgung über Extraleitungen 0,75qmm). Alle HC595 liegen in Reihe. Ich habe keine Probleme damit. Das funktioniert einwandfrei. Zum Timing: Es ist nicht sehr schnell. Dauert etwa eine halbe Sekunde, bis einmal alles durchgeschoben ist. Das liegt aber daran, das ich 'ne C-Control zum Takten davor habe, und die ist nun mal nicht schneller. Ich würde mal die Betriebsspannung jeder einzelnen Platine (wenn alles leuchtet) messen. Außerdem den Spannungsabfall über die Masseleitungen. Kann es vielleicht auch an der Software liegen? Irgendetwas zählt nur bis 7 statt bis 8? Nach Deinem Test mit der 1-Sekunden-Taktung würde ich Timingprobleme als Fehlerursache ausschließen. Gruß Ralf
@ Layouter (Gast) >Ist leider ein Problem aller '595... Nöö. >Das Problem ist dass das die Bits auf die gleiche Clk Flanke >rausgeschoben werden wie sie auch beim nachfolgendem 595 am Eingang >gelesen werden. Das machen 90% aller Digital-ICs und das funktioniert gut. > Abhilfe schaft ein zusätzliches Latch zwischen den >verschiedenen 595er. >Dieses Latch sichert dir den alten Zustand für den nächsten 595. Käse. Schon mal was von Setup- und Hold Zeiten gehört? Und Clock Skew? @ Kolja (Gast) >Kommt ein achtes Register hinten dran, entstehen ab dem 5. Register >fehlerhafte Ausgaben. Da sind dann schon ein paar cm Kabel dazwischen, nicht wahr? >Also ein Schirmungs- Störungs- Masseproblem? Ein Masse und Reflexionsproblem. Siehe Wellenwiderstand. Ein AC-Terminierung am Ende der Taktleitung könnte helfen. Halbwegs gescheite Masseführung vorausgesetzt. MFG Falk
Die Kabellängen sind bei mir schon eine ganz andere Kategorie als 20cm. Bei direkter Verbindung der Kästen sprechen wir von ca. 30-40cm zwischen den Registern. Im finalen Aufbau kommen nach jeweils zwei Registern aber nochmal bis zu 100cm dazu. Alles zusammengerechnet komme ich für die insgesamt 16 Zeichen auf... OMG, das werden 15 Meter Kabel! Ist das überhaupt noch per Terminierung in den Griff zu bekommen? So wie das Fehlerbild jetzt schon aussieht wird das doch am Ende um ein vielfaches schlimmer. Da werde ich wohl nicht drumrum kommen, mindestens das Taktsignal zwischendurch aufzubereiten. Ich wette sowas passiert einem kein zweites Mal, war mir einfach in keinster Weise bewußt, daß die Kabellängen sich so negativ auswirken. Eigentlich bedauerlich, hätte mir schon beim Design klar sein können.
Kolja schrieb:
> ...10Meter... aber schlimm genug.
klar, alles geht - ich würde aber sein lassen und stattdessen z.b. mit
funk versenden - wenn sein muss auch in jedem kasten ein atmega - hast
mehr möglichkeiten, kann nach bedarf abändern und wird garantiert
günstiger und störungsicherer als irgendetwas.
Hi >klar, alles geht - ich würde aber sein lassen und stattdessen z.b. mit >funk versenden - wenn sein muss auch in jedem kasten ein atmega - hast >mehr möglichkeiten, kann nach bedarf abändern und wird garantiert >günstiger und störungsicherer als irgendetwas. Wie hieß der Spruch: Wer Funk kennt, nimmt Kabel Bei diesen Entfernungen einfach RS485-/RS422- oder Can-Treiber/Empfänger verwenden. Damit ist das Problem gegessen. Auf jeden Fall billiger und sicherer als Funk und/oder zusätzliche AVRs. MfG Spess
10Meter werden es insgesamt, also Entfernung zwischen Atmel und letztem Register. die einzelnen Register sind dann maximal mit 1,5m verbunden. Funk steht für dieses Projekt nicht zur Debatte und 16 Atmegas auch nicht.
jaja, Funk für so nen Kram, lieber Gott... Vorher Gedanken machen hilft. Oder wenigstens nachher wie Kolja. Aber dann auch die richtigen. Prinzipiell würde ich bei den Leitungslängen von vornherein auf Leitungstreiber setzen. EMV/slew rate beachten. RS485 oder CAN-Treiber lassen sich auch für solche Sachen einsetzen, ohne wirklich einen Bus aufzubauen.
Kolja schrieb: > 10Meter werden es insgesamt, also Entfernung zwischen Atmel und letztem > Register. > die einzelnen Register sind dann maximal mit 1,5m verbunden. > Funk steht für dieses Projekt nicht zur Debatte und 16 Atmegas auch > nicht. habe 10m zwischen den kästen verstanden, für 1.5m ist natürlich funk overkill
Um die Empfehlung von crazyhorse noch etwas zu konkretisieren: Die billigste Variante düfte sein, die Takt- und Strobe-Leitungen differentiell auszuführen, also hinter die Ausgänge des AVR einen RS-485 Transmitter und vor die Eingänge der einzelnen Platinen jeweils einen Receiver zu setzen. Damit brauchst Du in den Platinen keine zusätzliche Intelligenz, denn Du fährst ja kein RS-485-Protokoll, sondern nuzt nur die Störsicherheit der RS485-Leitungstreiber aus. Ein RS485-Transceiver vom Typ 75176 kostet bei Reichelt gerade mal 26 Cent. Davon bräuchtest Du pro Platine zwei und nochmal zwei für den AVR. Wenn Du der Vollständigkeit halber die Datenleitungen auch noch diferentiell ausführen willst, kannst Du pro Platine einen 75175 (vierfach Receiver, 60 Cent) für die Eingänge und einen 75176 für den Datenausgang verbauen und bleibst damit immer noch unter einem Euro an Mehrkosten pro Platine.
Ich hatte das mal mit mehreren 7 Segment Anzeigen auch so gemacht. Das ganze differenziell mit RS422 Leitungstreibern (also Clock,Strobe und Daten Treibertype 75LBC179) uebertragen und gut ist. Das ganze lief in einer von mehreren Frequenzumrichtern stoerverseuchten Umgebung einwandfrei. So direkt TTL Signale ueber mehrere Meter auf einer Leitung zu uebertragen ohne Leitungsabschluss geht meisten schief. Gruss Helmi
Ich habe ein ähnliches Problem: eine Matrix mit 10x8 LEDs zeigte ein merkwürdiges Verhalten, sobald ich die 74595 über eine 2m lange Leitung an den Controller hängte. Einzelne LEDs flackerten einfach so vor sich hin und die letzte Reihe war permanent leuchtend. Als ich die Leitungen testweise auf 10cm verkürzt hatte, lief alles wie gewünscht. Bei der nächsten Hardwarebestellung werde ich mir ein paar Treiber und abgeschirmte Leitungen besorgen, da auch im Radio Störungen auftraten, sobald ich das Gerät einschaltete. Mal sehen, ob mit den Sachen die Chose sauberer läuft.
>sobald ich die 74595 über eine 2m lange Leitung an den Controller hängte.
Man kann TTL Signale nicht so ohne weiteres ueber mehrere Meter Leitung
schicken ohne die Leitung abzuschliessen. Reflektionen lassen gruessen.
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.