Hallo,
ich steuere über einen 74HC595 eine 7-Segment LED-Anzeige an. Das ganze
ist auf einem Steckbrett montiert, und einem ATmega8515L auf dem STK500
verbunden. Alles funktioniert auch so wie ich will, allerdings habe ich
folgendes Phänomen: In ca. 50cm Abstand steht eine Tischlupenleuchte mit
Kaltlicht-Neonring. Wenn ich diese An-/Ausschalte, läuft der uC
problemlos weiter, aber der 74HC595 setzt alle Ausgänge auf low, bis die
nächste Ansteuerung kommt (1-mal pro Sekunde). 100nF Kondensator
zwischen Vcc und Gnd ändert auch nichts daran. Hat jemand eine Idee, wie
man dieses Verhalten verhindern kann?
Zum grundlegenden Verständnis: Wie "synchronisiert" sich eigentlich die
serielle Eingabe zum 595, also woher "weiß" dieser, welches das erste
Bit von den insgesamt acht ist? Wird das mit der Übernahme in den
Speicher zurückgesetzt?
Gruß
Achim
Achim Helmken wrote:
> Hallo,>> ich steuere über einen 74HC595 eine 7-Segment LED-Anzeige an. Das ganze> ist auf einem Steckbrett montiert, und einem ATmega8515L auf dem STK500> verbunden. Alles funktioniert auch so wie ich will, allerdings habe ich> folgendes Phänomen: In ca. 50cm Abstand steht eine Tischlupenleuchte mit> Kaltlicht-Neonring. Wenn ich diese An-/Ausschalte, läuft der uC> problemlos weiter, aber der 74HC595 setzt alle Ausgänge auf low, bis die> nächste Ansteuerung kommt (1-mal pro Sekunde). 100nF Kondensator> zwischen Vcc und Gnd ändert auch nichts daran. Hat jemand eine Idee, wie> man dieses Verhalten verhindern kann?
Kontrolliere den Reset-Eingang vom 595. Der ist wahrscheinlich etwas
hochohmig/wackelig gegen irgend einen Pegel gepullt. Mach den Pull
kräftiger.
> Zum grundlegenden Verständnis: Wie "synchronisiert" sich eigentlich die> serielle Eingabe zum 595, also woher "weiß" dieser, welches das erste> Bit von den insgesamt acht ist? Wird das mit der Übernahme in den> Speicher zurückgesetzt?
Garnicht. Die letzten acht Bit die man in das Schieberegister geschoben
hat sind die aktuellen und werden mit dem Strobe übernommen - die "alten
fallen hinten raus". Für gewöhnlich schreibt man über die SPI acht Bit
raus, man muss sich also keine tiefergehenden Gedanken darüber machen.
> Garnicht. Die letzten acht Bit die man in das Schieberegister geschoben> hat sind die aktuellen und werden mit dem Strobe übernommen - die "alten> fallen hinten raus". Für gewöhnlich schreibt man über die SPI acht Bit> raus, man muss sich also keine tiefergehenden Gedanken darüber machen.
Heißt das, dass man sich um Synchronisierung selbst kümmern muss, also
das das erste gesendete Bit vom uC auch das erste empfangene vom 595
sein muss? Ist es dann so, dass wenn der 595 zufällig resettet, während
Daten gesendet werden, danach alles Müll ist was ankommt?
>Heißt das, dass man sich um Synchronisierung selbst kümmern muss, also>das das erste gesendete Bit vom uC auch das erste empfangene vom 595>sein muss?
So isses der Prozessor muss halt mitzaehlen wieviel Bits er schon
gesendet hat und dann denn Strobeimpuls ausgeben.
>Ist es dann so, dass wenn der 595 zufällig resettet, während>Daten gesendet werden, danach alles Müll ist was ankommt?
"zufällig resettet" sollte eigentlich nicht vorkommen sonst ist etwas
faul an deiner Hardware. Beispiele dazu: Zulange nicht abgeschlossene
Leitungen, schlechter nicht EMV gerechter Aufbau , offene Eingaenge ,
keine oder zuwenige Stuetzkondensatoren.
Gruss Helmi
Das Problem kann auch das Steckbrett sein. Die Teile neigen durch ihre
EMV-technisch ungünstige Verdrahtung zum Einfangen und Aussenden
sämtlicher Störungen.
Mach dich mal mit der grundsätzlichen Arbeitsweise eines SR vertraut. Du
kannst vo viele Bits reinschreiben wie du willst, aber es hält nur die
letzten 8. Die schreibst du mit RCLK in die Ausgangsregister.
Ich vermute aber auch RESET als Übeltäter.
Schuld war tatsächlich ein suboptimal verbundener Reset, danke für den
Tipp.
@Bensch: Ich hab gerade gemerkt, dass ich die ganze Zeit falschrum
gedacht hab ... natürlich ist das beim Schieberegister total egal,
irgendwie war ich gedanklich bei nem Ringspeicher ;)
