Moin, ich steuere mit einem AT89S8252 zwei 74HC595 zur Porterweiterung an. Nicht über SPI, sondern "zu Fuß" in ASM programmiert. Das ganze läuft seit vielen Jahren korrekt, jedoch gibt es manchmal falsche Ausgangsdaten aufgrund von EMV-Störungen (wenn induktive Verbraucher in der Nähe geschaltet werden). Nun wollte ich mich diesem Problem endlich mal annehmen und habe einfach jeweils ein RC-Glied (100R / 1nF) in die Steuerleitungen Data, Shiftclock, Latchclock geschaltet. Dies führte jedoch zu einem anderen Problem: Die Ausgänge des zweiten Shiftregisters sind nun jeweils um ein Bit nach hinten verschoben. Außerdem schaltet das letzte Bit des ersten Registers auch gleich das erste Bit des zweiten Registers mit. Ich dachte mir, dass das zweite Register wohl auf eine andere Schwelle des Clock triggert (durch die RC-Glieder sind die Flanken ja nun sehr flach). Also habe ich probeweise ein zweites RC-Glied in die Clock-Leitung vor das zweite Register geschaltet, damit dieses den Clock noch etwas später sieht. Das machte aber alles noch viel schlimmer und total chaotisch. Anpassen der Setup- und Hold-Zeiten hab ich schon versucht, indem ich diverse "NOPs" in meinen Code eingefügt habe. Aber auch das hat nicht wirklich geholfen. Nun habe ich nur noch eine Idee: Ich schalte jeweils zwischen RC-Glied und Register-Eingang noch einen Schmitt-Trigger (74LVC2G17), damit die Register wieder steile Flanken sehen. Macht das Sinn oder hole ich mir damit nur neue Probleme? Was würdet ihr machen, um die Datenleitungen EMV-sicherer zu machen? Die Register sind mit der CPU über ein etwa 10cm langes Flachbandkabel verbunden, das in der Nähe der Relais verläuft, die wiederum die induktiven 230V Verbraucher schalten... Dass das Probleme gibt, ist ja eigentlich klar. Vielleicht würde ja auch schon ein abgeschirmtes Kabel helfen??? Vielen Dank!
Ich wette, du hast an deinen Schieberegistern die Stützkondensatoren eingespart.
@ Robert S. (efyzz) >jeweils ein RC-Glied (100R / 1nF) in die Steuerleitungen Data, >Shiftclock, Latchclock geschaltet. Das 1nF ist viel zu viel! Selbst 100pF machen an der Taktleitung schon arg Probleme. >noch etwas später sieht. Das machte aber alles noch viel schlimmer und >total chaotisch. Was dir zeigt, dass dein Lösungsansatz untauglich ist. >Macht das Sinn oder hole ich mir damit nur neue Probleme? >Was würdet ihr machen, um die Datenleitungen EMV-sicherer zu machen? Dazu müsste man erstmal den IST-Zustand sehen. Wo liegt die Masse? Wie sieht die Abblockung der ICs aus? https://www.mikrocontroller.net/articles/Kondensator#Entkoppelkondensator >Die Register sind mit der CPU über ein etwa 10cm langes Flachbandkabel >verbunden, das in der Nähe der Relais verläuft, die wiederum die >induktiven 230V Verbraucher schalten... Hast du über den Schaltkontakten einen Snubber? >Dass das Probleme gibt, ist ja >eigentlich klar. Vielleicht würde ja auch schon ein abgeschirmtes Kabel >helfen??? Eher nicht.
100nF schrieb: > Ich wette, du hast an deinen Schieberegistern die Stützkondensatoren > eingespart. Nein, die sind drin. Falk B. schrieb: > Das 1nF ist viel zu viel! Selbst 100pF machen an der Taktleitung schon > arg Probleme. Kommt auf die Frequenz an oder? Bei meinem Controller können max. 1 MHz auftreten, also 1 us lange Pulse. bei 100 R / 1 nF ist Tau = 100 ns. Also ist nach 500 ns ganz sicher der Pegel erreicht. So hab ich anfangs gerechnet und das klappt ja auch, nur dass die beiden Register halt nicht mehr wirklich synchron laufen. Von daher hast Du wohl Recht. > Dazu müsste man erstmal den IST-Zustand sehen. Wo liegt die Masse? Wie > sieht die Abblockung der ICs aus? 100 nF in die Fassung integriert. Das Ganze ist natürlich ein wilder Lochraster-Aufbau. Auf sternförmige Masseverteilung hab ich geachtet, aber perfekt ist das alles sicher nicht. > Hast du über den Schaltkontakten einen Snubber? Jo. 100 R / 100 nF. Klar, ich könnte jetzt alles neu bauen, aber dafür bräuchte ich ne Woche Urlaub... Ich brauch ne quick+dirty Lösung, die heute noch läuft ;)
@Robert S. (efyzz) >> Das 1nF ist viel zu viel! Selbst 100pF machen an der Taktleitung schon >> arg Probleme. >Kommt auf die Frequenz an oder? Oder. Normale Schieberegister ohne Schmitt-Trigger Eingang am Takt wollen gern knackige, schnelle Flanken sehen. >Bei meinem Controller können max. 1 MHz >auftreten, also 1 us lange Pulse. bei 100 R / 1 nF ist Tau = 100 ns. Das ist schon recht langsam. Typische Anstiegszeiten liegen bei 5-10ns. >Jo. 100 R / 100 nF. Hmmm. >Klar, ich könnte jetzt alles neu bauen, aber dafür bräuchte ich ne Woche >Urlaub... Ich brauch ne quick+dirty Lösung, die heute noch läuft ;) Aber auch dafür braucht man mal ein Bild vom Aufbau.
Robert S. schrieb: > Falk B. schrieb: >> Das 1nF ist viel zu viel! Selbst 100pF machen an der >> Taktleitung schon arg Probleme. > > Kommt auf die Frequenz an oder? Nein! Es kommt auf die FLANKENSTEILHEIT an. Robert S. schrieb: > Das Ganze ist natürlich ein wilder Lochraster-Aufbau. Wenn schon Lochraster, dann Lochraster mit Masselage. Lötaugen nach oben, Masselage nach unten --> Pseudo-SMD (mit bedrahteten Bauteilen).
Robert S. schrieb: > Das Ganze ist natürlich ein wilder > Lochraster-Aufbau. klar... Was ist denn mit den Output-Enable und Reset-Eingängen? Wie sind die angeschlossen? Welchen CLK Takt benutzt du? Sehr hilfreich wären ein Schaltplan, und ein Screenshot deiner Ansteuersignale (Timing). RC in die Signalleitungen ist definitiv kontraproduktiv (Verzögerung, schlechtere Flankensteilheit).
Falk B. schrieb: > Oder. Normale Schieberegister ohne Schmitt-Trigger Eingang am Takt > wollen gern knackige, schnelle Flanken sehen. Dann könnte meine Idee mit den vorgeschalteten Triggern doch klappen?! Dann laufen die Register jedenfalls wieder synchron. Es könnte dann natürlich sein, dass die 3 Signale untereinander weglaufen, aber mit ein paar NOPs zwischen Data und Clock sollte man das ja in den Griff kriegen?! > Aber auch dafür braucht man mal ein Bild vom Aufbau. Das willst Du nicht wirklich :) Das Gerät steuert insgesamt an die 30 Verbraucher, die sowohl mit Netzspannung, als auch mit DC laufen. Hinzu kommen PWMs, Sensoren usw... Ich steuere damit diverse Aquarien, d.h. die ganzen Steuerleitungen laufen auch noch über mehrere Meter quer durch den Raum. 230 V Leitungen liegen mit Sensorleitungen in einem Kabelkanal usw... Außerdem ist das Ganze über zig Jahre gewachsen und wurde immer wieder erweitert / umgebaut. Natürlich ist das alles Mist. Ich arbeite auch schon an einer neuen Lösung auf Basis STM32, die dann auch von vornherein diverse EMV-Filter haben wird. Statt Relais gibt's dann auch Triacs. Aber bis es soweit ist, muss die alte Kiste halt noch irgendwie rennen. Am Aquarium kann man nicht einfach den Stecker ziehen, denn die Tiere sind auf funktionierende Technik angewiesen. Daher jetzt quick+dirty, auf lange Sicht vernünftig.
Robert S. schrieb: > 100 nF in die Fassung integriert. Das Ganze ist natürlich ein wilder > Lochraster-Aufbau. Auf sternförmige Masseverteilung hab ich geachtet, > aber perfekt ist das alles sicher nicht. Lochraster ist ok, aber bitte keine Massesterne. Das ist '60er Jahre, als die Röhrentechnik noch langsam und hochohmig war. Digitalschaltungen brauchen eine Massefläche. Wenn Du die nicht hast, dann bau ein möglichst engmaschiges Netz. Das geht auch auf Lochraster, und 8 MHz-Schaltungen funktionieren dann problemlos.
@soul eye (souleye)
>Digitalschaltungen brauchen eine Massefläche.
Übertreib's nicht! Eine handvoll CMOS-ICs kriegt man auch auf normalem
Lochraster ohne Massefläche stabil zum laufen!
@ Robert S. (efyzz) >> Aber auch dafür braucht man mal ein Bild vom Aufbau. >Das willst Du nicht wirklich :) Sollen wir hellsehen? >Natürlich ist das alles Mist. Ich arbeite auch schon an einer neuen >Lösung auf Basis STM32, Das löst keine EMV-Probleme. >Daher jetzt quick+dirty, auf lange Sicht vernünftig. Schau dir an, wo die Masse verläuft. Die muss eng und parallel zu den Signalen laufen. Auf dem Flachbandkabel sollen mindestens 2 Masseleitungen liegen, die beidseitig angeschlossen sind. Im Idealfall ist jede 2. Leitung Masse.
Falk B. schrieb: > Übertreib's nicht! Eine handvoll CMOS-ICs kriegt man auch auf normalem > Lochraster ohne Massefläche stabil zum laufen! Falk B. schrieb: > Schau dir an, wo die Masse verläuft. Die muss eng und parallel zu den > Signalen laufen. Auf dem Flachbandkabel sollen mindestens 2 > Masseleitungen liegen, die beidseitig angeschlossen sind. Im Idealfall > ist jede 2. Leitung Masse. Auch das ist ein Massenetz. Bei Lochraster kann man unter jeder IC-Reihe einen Massedraht durchziehen und diese dann am oberen und unteren Leiterplattenrand verbinden. So laufen problemlos 8 MHz auf Lochraster.
Robert S. schrieb: > Nun wollte ich mich diesem Problem endlich mal annehmen und habe einfach > jeweils ein RC-Glied (100R / 1nF) in die Steuerleitungen Data, > Shiftclock, Latchclock geschaltet. > > Dies führte jedoch zu einem anderen Problem: Die Ausgänge des zweiten > Shiftregisters sind nun jeweils um ein Bit nach hinten verschoben. > Außerdem schaltet das letzte Bit des ersten Registers auch gleich das > erste Bit des zweiten Registers mit. Das bedeutet dass mit der Übernahme etwas nicht mehr stimmt, die beiden übernehmen nicht synchron (stimmt die Flankenlage?). Mach es halt so schnell wies geht dann merkst du den Fehler ev. nicht. Oder du sorgst dafür dass keine Einstrahlung erfolgt. Kurt
Die 8051 machen nur für ~2µs strong high an der 0-1 Flanke, danach gehen sie in weak Pullup. Wenn Das RC-Glied länger braucht, hast Du verloren. Generell: RC-Glieder in Digitalschaltungen lösen keine Probleme, sondern sie machen welche.
Moin, ich habe die Probleme letztendlich mit einer abgeschirmten Leitung zwischen CPU und SR gelöst ;)
:
Bearbeitet durch User
Hallo, naja, Alufolie rum und an GND wäre wohl mein erster Versuch gewesen, um zu schauen, ob es da reinsaut. Wie ich mich kenne, wäre das dann so geblieben bis... Lochraster ist kein prinzipielles Problem, mein 80MHz Logianalyzer ist auch Loachraster. 8MHz, wie oben angenerkt, geht noch ohne größeres nachdenken. http://www.avr.roehres-home.de/logikanalyzer/h_index.html Gruß aus Berlin Michael
Robert S. schrieb: > Das ganze läuft seit vielen Jahren korrekt, jedoch gibt es manchmal > falsche Ausgangsdaten aufgrund von EMV-Störungen (wenn induktive > Verbraucher in der Nähe geschaltet werden). > > Nun wollte ich mich diesem Problem endlich mal annehmen und habe einfach > jeweils ein RC-Glied (100R / 1nF) in die Steuerleitungen Data, > Shiftclock, Latchclock geschaltet. > > Dies führte jedoch zu einem anderen Problem: Die Ausgänge des zweiten > Shiftregisters sind nun jeweils um ein Bit nach hinten verschoben. > Außerdem schaltet das letzte Bit des ersten Registers auch gleich das > erste Bit des zweiten Registers mit. Das sieht mir nach Setup-hold-Problem aus. Bitte mal anschauen wie die Daten zum Takt stehen und gegebenenfalls Taktflanke prüfen/wechseln. Schöne Veranschaulichung: https://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus#/media/File:SPI_timing_diagram2.svg rgds
Falk B. schrieb: >>Natürlich ist das alles Mist. Ich arbeite auch schon an einer neuen >>Lösung auf Basis STM32, > > Das löst keine EMV-Probleme. Das ist so pauschal nicht richtig. Was man mit einem Prozessor verbessern könnte, wäre die Sicherheit der Übertragung z.B. durch Prüfsummen. Wenn die Übertragungsstrecke nicht total versaut ist, sondern fast immer funktioniert ausser bei sporadischen starken Störungen, kann man so verhindern, dass diese Auswirkungen auf die Ausgänge haben. Es gibt Störungen, etwa beim Schalten einer grossen induktiven Last, die man ohne Umbau der Verkabelung garnicht in den Griff bekommt, dann baut man sich kein störungsfreies, sondern ein störungstolerantes System. Ein 32-bit-Prozessor muss das natürlich nicht sein, schadet aber auch nicht. Georg
@Robert S. (efyzz) >ich habe die Probleme letztendlich mit einer abgeschirmten Leitung >zwischen CPU und SR gelöst ;) Die Schirmung war hier wahrscheinlich nicht die Lösung, wohl aber die eng geführte Masse. Eine verdrillte Leitung hätte es wahrscheinlich auch getan.
Als zusätzliche Maßnahme zur Fehlerminimierung könnte man, nachdem eine Ausgabe über die HC595 erfolgt ist, die serielle Übertragung zu den HC595 wiederholen und dabei den seriellen Ausgang des letzten HC595 in der chain wieder einlesen. Stimmen die eingelesenen Daten mit den zuvor gesendeten überein, war die Übertragung korrekt, und das Signal für die Ausgangsflipflops braucht nicht nochmals bedient zu werden.
Georg schrieb: > Was man mit einem Prozessor > verbessern könnte, wäre die Sicherheit der Übertragung z.B. durch > Prüfsummen. Das will ich sehen, wie du deine Daten mit Prüfsumme an ein 74HC595 schickst.
T. .. schrieb: > Das will ich sehen, wie du deine Daten mit Prüfsumme an ein 74HC595 > schickst. Deswegen steht da ja "Prozessor" - sieh dir mal das Datenblatt zum 595 an, ein Prozessor ist das ganz sicher nicht. Und die Idee einen Prozessor stattdessen zu verwenden stammt vom TO selbst. Georg schrieb: > Ein 32-bit-Prozessor muss das natürlich nicht sein, Was kann danach noch unklar sein? Georg
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.