www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik 74HC595 am Atmega8 => Verzweiflung


Autor: Kolja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: kurz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kolja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Langsamere Taktrate z.B.

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leitungen treiben und richtig abschliessen.

Autor: H.Joachim Seifert (crazyhorse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: kurz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kolja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: kurz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kolja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Layouter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kolja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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

Autor: Kolja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kolja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...10Meter... aber schlimm genug.

Autor: Thomas R. (tinman) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Kolja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: H.Joachim Seifert (crazyhorse)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas R. (tinman) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Joachim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig, siehe Wellenwiderstand.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.