Announcement: there is an English version of this forum on Hallo, ich habe ein seltsames Problem mit einem 74HCT595 (8-bit Schieberegister mit parallelem Ausgang), der von einem Arduino Nano angesteuert wird. Die Pins clk, strb, data und ~clr sind mit dem Arduino verbunden, ~oe liegt fest auf GND. Der Arduino braucht nach dem Starten 1-2 Sekunden, bis die Pins als Ausgänge konfiguriert sind. In dieser Zeit macht der HCT595 seltsame Dinge: Er schaltet (fast immer) alle Ausgänge auf 1, was für die nachfolgende Schaltung ziemlich fatal ist. Im Moment wird der Arduino noch von USB und die 595-Schaltung von einem Labornetzteil versorgt. Wird der Arduino zuerst eingeschaltet und die 595-Schaltung einige Sekunden später, dann tritt das Problem mit dem High-Level an den Ausgängen nicht auf. Folglich war meine Idee, dass der 595 diesen Unsinn macht, weil die Eingänge am Anfang noch floaten, bis sich der Ardunio konfiguriert hat. Also habe ich alle Eingänge gepullt (~clr mit 10k gegen 5V, die anderen mit 10k gegen GND). Das hatte jedoch keinerlei Effekt. Dieser Unsinn, dass der 595 alle Ausgänge auf 1 legt, ist mir vorher noch nicht begegnet. Und selbst wenn es so wäre: Warum tut er das nicht, wenn er nach Prozessor eingeschaltet wird, aber Pull-Widerstände keinen Effekt haben?
Vancouver schrieb: > Und selbst wenn es so wäre: Warum tut er das nicht, > wenn er nach Prozessor eingeschaltet wird, aber Pull-Widerstände > keinen Effekt haben? Vermutlich werden durch Einkopplungen viele virtelle Taktpulse erzeugt. Wenn dann zufällig oder systematisch der Dateneingang auf HIGH liegt, wandern die alle ins Schieberegister. Leg OE an den Arduino und pack einen externen Pull-Up dran. Dann beim Reset erst das Schieberegister mit 0 laden, speichern und dann erst OE auf Ausgang schalten und LOW ziehen.
Falk B. schrieb: > Vermutlich werden durch Einkopplungen viele virtelle Taktpulse erzeugt. > Wenn dann zufällig oder systematisch der Dateneingang auf HIGH liegt, > wandern die alle ins Schieberegister. Aber doch nicht, wenn die Eingänge gepullt sind, oder?
Vancouver schrieb: > Aber doch nicht, wenn die Eingänge gepullt sind, Eigentlich nicht. Aber es kann sein, daß beim Einschalten der Versorgungsspannung komische Dinge passieren. Egal, leg OE an den Arduino und teste.
Vancouver schrieb: > Folglich war meine Idee, dass der 595 diesen Unsinn macht, weil die > Eingänge am Anfang noch floaten Tun sie das wirklich? Was sagt das Oszilloskop? > Im Moment wird der Arduino noch von USB und die 595-Schaltung von einem > Labornetzteil versorgt. Die Masse der beiden ist aber schon verbunden? Ich frage nur, weil diese ungemein wichtige Verbindung in deinem verbalen Schaltplan "Pins clk, strb, data und ~clr sind mit dem Arduino verbunden, ~oe liegt fest auf GND" nicht auftaucht...
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Tun sie das wirklich? Was sagt das Oszilloskop? Das Oszi sagt nichts and dieser Stelle, insbesondere dann nicht, wenn die Pull-Widerstände drin sind. Aber ich muss das nochmal genauer anschauen. Vllt gibt es irgendwelche Spikes beim Einschalten, die ich noch nicht gesehen habe. Und ja, die GND-Verbindung existiert natürlich, das hätte ich erwähnen sollen, sorry. Nachdem der HCT595 korrekt initialisiert ist, funktioniert die ganze Schaltung problemlos. Vor einigen Jahren hatte ich mal ein ähnliches Design mit einem PIC statt Arduino. Da ist das Problem nicht aufgetreten, oder ich habe es nicht bemerkt, weil der PIC seine Ports schneller konfiguriert, da er sich nicht erst durch den Bootloader durcharbeiten muss. Ich werde heute mal die Signale vom Arduino abklemmen und auf harte Logiklevel legen und schauen was beim Einschalten passiert, dann schrittweise immer größere Pull-Widerstände einbauen. Die Lösung mit dem ~oe wäre ziemlich aufwändig, weil ich dann an den 595-Ausgängen überall Pulldowns bräuchte und eine zusätzliche Leitung zum Controller, der aber keinen Pin mehr frei hat. Das wäre in komplettes Redesign.
Was ich mal noch fragen wollte: hat schon mal jemand beobachtet, dass der 595 alle Ausgänge auf high legt, bevor man ihn initialisiert? Ist dieses Verhalten normal? Im Datenblatt steht dazu nichts.
Hi, >Die Lösung mit dem ~oe wäre ziemlich aufwändig, weil ich dann an den >595-Ausgängen überall Pulldowns bräuchte und eine zusätzliche Leitung >zum Controller, der aber keinen Pin mehr frei hat. Das wäre in >komplettes Redesign. und wie wäre es ~MR auf low zu halten? Viel Erfolg, Uwe
Vancouver schrieb: > Was ich mal noch fragen wollte: hat schon mal jemand beobachtet, dass > der 595 alle Ausgänge auf high legt, bevor man ihn initialisiert? Ist > dieses Verhalten normal? Im Datenblatt steht dazu nichts. Der Punkt ist, dass der initiale Zustand nach dem Anlegen der Versorgungsspannung undefiniert ist. Also ja, deine Beobachtung fällt in den Bereich des normalen. Jeder beliebige Zustand ist normal. Wenn dich das stört, musst du wie gesagt mit /OE und Widerständen an den Ausgängen arbeiten. > und wie wäre es ~MR auf low zu halten? oder das
:
Bearbeitet durch User
Vancouver schrieb: > as ich mal noch fragen wollte: hat schon mal jemand beobachtet, dass > der 595 alle Ausgänge auf high legt, bevor man ihn initialisiert? Ist > dieses Verhalten normal? Mehr oder weniger. Der Zustand der Ausgänge beim Einschalten ist ZUFÄLLIG! Das Ding hat keinerlei Power Up Reset oder so eingebaut. Der Reseteingang hilft hier auch nicht, denn der wirkt nur auf des Schieberegister, nicht auf das Ausgangsregister.
Stefan ⛄ F. schrieb: > und wie wäre es ~MR auf low zu halten? > > oder das Nö. Mal wieder so ein aus der Hüfte geschossener "Expertentip" . . .
Falk B. schrieb: > Nö. Mal wieder so ein aus der Hüfte geschossener "Expertentip" . . . Ohne Begründung hilft das keinem. Außerdem kam der Vorschlag nicht von mir.
Vancouver schrieb: > Warum tut er das nicht, wenn er nach Prozessor eingeschaltet wird Läuft zu diesem Zeitpunkt evtl. schon das Programm, das laufend gültige Daten rausschreibt.
Falk B. schrieb: > Der Reseteingang hilft hier auch nicht, denn der wirkt nur auf des > Schieberegister, nicht auf das Ausgangsregister. Ich würde mal sagen, das hängt vom Zustand der STCP Leitung ab, die er ebenfalls unter seiner Kontrolle hat.
:
Bearbeitet durch User
Im Datenblatt steht: "A HIGH on OE causes the outputs to assume a high-impedance OFF-state." Ein Pull-Up Widerstand an diesem Signal würde während der Zeit der undefinierten Zustände, also kurz nach dem einschalten, die Ausgänge im Tri-State halten. An den Ausgängen dieses ICs bzw. an den Eingängen Deiner Schaltung, benötigst Du je nach Fall Pull-Up- oder Pull-Down-Widerstände; das kommt auf deine Schaltung an, was Du an die Ausgänge dieses ICs angeschlossen hast. Die PUs und/oder PDs halten die Leitungen auf definierten Pegeln, bis die Initialisierung des '595 abgeschlossen ist. Nach der Initialisierung, also wenn die Schaltung ganz normal läuft, überschreiben sozusagen die Push-Pull-Ausgänge des '595 dann die vordefinierten Pegel der PUs/PDs.
Du schriebst: "Die Lösung mit dem ~oe wäre ziemlich aufwändig, weil ich dann an den 595-Ausgängen überall Pulldowns bräuchte und eine zusätzliche Leitung zum Controller, der aber keinen Pin mehr frei hat." Dann benötigt die Schaltung ein Monoflop, das den OE-Eingang für die kurze Zeit der Initialisierung auf HIGH legt. Evtl. ergeben sich auch noch weitere Möglichkeiten, wenn du uns zeigst, was du an den Ausgängen des '595 angeschlossen hast.
Mich würde es ja stören, wenn mein Mikrocontroller 1-2 Sekunden braucht, bis er mal dazu kommt, seine Peripherie zu initialisieren. Die Pinfunktionen sind normalerweise das erste, was definiert wird. Und wenn Du schreibst, dass es fatale Folgen für Deine Schaltung hat, wenn die Ausgänge des Schieberegisters zufällige Pegel haben, dann ist die zwingende Konsequenz, dass Du !OE ebenfalls mit Deinem Mikrocontroller verbindest und erst auf LOW ziehst, wenn Du ein Initial-Byte (z.b. 00000000) zu dem 74*595 übertragen hast. Bis dahin wird !OE über ein Pullup Widerstand auf HIGH gehalten, so dass keine zufälligen Ausgangspegel zustande kommen. Erst dann bist Du im definierten Bereich.
Falk B. schrieb: > Der Zustand der Ausgänge beim Einschalten ist > ZUFÄLLIG! Das Ding hat keinerlei Power Up Reset oder so eingebaut. Exakt so ist es. Logik-ICs haben typisch kein POR und stehen deshalb beim Einschalten rein zufällig. Deshalb zieht man beim 595 den /OE mittels Pullup auf tristate und setzt ihn erst auf low, nachdem man gültige Daten eingeschoben hat. In tristate kann man dann die Ausgänge des 595 mittels Pulldowns auf low ziehen.
Stefan ⛄ F. schrieb: > Ohne Begründung hilft das keinem. Außerdem kam der Vorschlag nicht von > mir. Dann lies mal meinen Beitrag Beitrag "Re: Problem mit Arduino-Nano und HCT595"
Lothar M. schrieb: > Läuft zu diesem Zeitpunkt evtl. schon das Programm, das laufend gültige > Daten rausschreibt. Das ist normalerweise der Fall, aber ich habe die SW testweise so geändert, dass sie nur die Pins konfiguriert und auf einem definierten Level hält, sonst nichts. Also genau das gleiche, was PU/PD-Widerstände tun würden.
Vancouver schrieb: > Die Lösung mit dem ~oe wäre ziemlich aufwändig, weil ich dann an den > 595-Ausgängen überall Pulldowns bräuchte und eine zusätzliche Leitung > zum Controller, der aber keinen Pin mehr frei hat. Das wäre in > komplettes Redesign. Tja... Vancouver schrieb: > Was ich mal noch fragen wollte: hat schon mal jemand beobachtet, dass > der 595 alle Ausgänge auf high legt, bevor man ihn initialisiert? Der Zustand ist nicht definiert, daher gibt es MR und OE. Einzig richtig ist es die Schaltung so auszulegen, das die Ausgänge in Ruhe via Pullup/-down im sicheren Zustand verleiben bis ein gültiges Datenwort geschrieben und via OE angelegt wird. Vancouver schrieb: > Da ist das Problem nicht aufgetreten, oder ich habe es > nicht bemerkt, weil der PIC seine Ports schneller konfiguriert, da er > sich nicht erst durch den Bootloader durcharbeiten muss. Du hast im PIC keinen Bootlader benutzt und jetzt im AVR auch noch einen der sich lange Zeit lässt. Programmiere den Chip mittels ISP und setze das SR direkt in den ersten Zeilen, dann geht es deutlich schneller. Und/oder versuch Optiboot, der ist ein wenig schneller.
:
Bearbeitet durch User
Vancouver schrieb: > Das wäre in > komplettes Redesign. Andere würden sowas "Korrektur eines Designfehlers" nennen. ;)
Marko schrieb: > "Korrektur eines Designfehlers" Wenn es nicht anders geht, wird es wohl so sein müssen...
Wenn kurze Spikes (100ms) nicht stören, kann man die 595-Löschroutine ja mit in den Bootloader packen.
Du schriebst: "Das ist normalerweise der Fall, aber ich habe die SW testweise so geändert, dass sie nur die Pins konfiguriert und auf einem definierten Level hält, sonst nichts. Also genau das gleiche, was PU/PD-Widerstände tun würden." Das ist leider nicht so. Während die PU/PD-Widerstände SOFORT funktionieren, ohne zeitliche Verzögerung, legt dein Arduino die Pegel erst nach ein, zwei Sekunden an. Nachdem der Bootloader durchlaufen wurde. Genau dafür sind PU/PD-Widerstände zu berücksichtigen: Definierte Zustände dort zu haben, wo erst etwas später ICs ihre Arbeit aufnehmen.
Der müde Joe schrieb: > Genau dafür sind PU/PD-Widerstände zu berücksichtigen: Definierte > Zustände dort zu haben, wo erst etwas später ICs ihre Arbeit aufnehmen. Genau richtig. Aber warum haben PU/PDs dann keinen Effekt, ein zuvor hochgefahrener Arduino hingegen schon? Das ist ja genau das Rätsel. Wenn ich den 595 mit PU/PDs starte, sieht er definierte Pegel auf den Steuerleitungen und legt trotzdem alle Ausgänge auf High. Starte ich ihn mit einem bereits einige Sekunden zuvor gebooteten Arduino, so sieht er die gleichen definierten Pegel, aber alle Ausgänge sind auf 0.
Vancouver schrieb: > Genau richtig. Aber warum haben PU/PDs dann keinen Effekt, Vermutlich weil sie falsch angeschlossen sind. > ein zuvor > hochgefahrener Arduino hingegen schon? Was macht der? Hält der nur die Pegel konstant oder schreibt der periodisch 0x00 ins Register? > Das ist ja genau das Rätsel. Wenn ich den 595 mit PU/PDs starte, sieht > er definierte Pegel auf den Steuerleitungen und legt trotzdem alle > Ausgänge auf High. Starte ich ihn mit einem bereits einige Sekunden > zuvor gebooteten Arduino, so sieht er die gleichen definierten Pegel, > aber alle Ausgänge sind auf 0. Wie willst du denn dein 595 einzeln "starten"? Das braucht eine Versorgungsspannung. Die kann man nicht einfach abschalten, denn dann wird dein IC parasitär über die Eingangsschutzdioden versorgt.
Hi, >von Falk B. (falk) >Stefan ⛄ F. schrieb: >> und wie wäre es ~MR auf low zu halten? >> >> oder das >Nö. Mal wieder so ein aus der Hüfte geschossener "Expertentip" . . . Dein Tipp ist aber auch nicht so viel wert. Ja, du hast recht. Aber etwas weiter im DB zum 74HCT595 geschaut findet sich die Tabelle3 Schau doch mal nach Zeile 2. Ich würde damit eine ganz einfache Lösung bauen( so mit C und R) Viel Erfolg, Uwe
Uwe schrieb: >>Nö. Mal wieder so ein aus der Hüfte geschossener "Expertentip" . . . > Dein Tipp ist aber auch nicht so viel wert. > Ja, du hast recht. Das reicht. > Aber etwas weiter im DB zum 74HCT595 geschaut findet sich die Tabelle3 > Schau doch mal nach Zeile 2. Es gibt nicht nur ein Datenblatt von dem IC, sondern viele verschiedene. Was steht in DEINEM Datenblatt dort?
Falk B. schrieb: > Vermutlich weil sie falsch angeschlossen sind. Ich bin ziemlich sicher, dass sie richtig angeschlossen sind. Falk B. schrieb: > Was macht der? Hält der nur die Pegel konstant oder schreibt der > periodisch 0x00 ins Register? Er konfiguriert die Pins als outputs, schreibt eine 1 auf ~clr und 0 auf die anderen und tut dann nichts mehr, bis etwas über den CAN-Bus kommt (und da kommt aktuell nichts). Falk B. schrieb: > Wie willst du denn dein 595 einzeln "starten"? Das braucht eine > Versorgungsspannung. Die kann man nicht einfach abschalten, denn dann > wird dein IC parasitär über die Eingangsschutzdioden versorgt. Wie oben beschrieben, hängt der 595 an einem Labornetzteil, das getrennt vom Arduino eingeschaltet werden kann. Wenn der 595 später als der Arduino eingeschaltet wird, verhält er sich so, wie ich es gerne hätte. Das mit der parasitären Versorgung muss ich mal genau untersuchen, das könnte gut sein. Uwe schrieb: > Ich würde damit eine ganz einfache Lösung bauen( so mit C und R) Ja, das macht Sinn. Das RC-Glied wird die Signale etwas verschleifen, dass ich die Impulsebreite im normalen Betrieb vermutlich größer machen muss. Aber das ist kein Problem in diesem Fall.
Vancouver schrieb: > Wenn ich den 595 mit PU/PDs starte, sieht > er definierte Pegel auf den Steuerleitungen und legt trotzdem alle > Ausgänge auf High. Vermutlich weil zwischen dem Einschalten der Stromversorgung und dem ersten Taktimpuls Zeit vergeht. Für genaueres brauchen wir mal deinen Schaltplan. Es ist nämlich nicht klar, welche Pegel die zahlreichen Eingänge nun initial haben.
:
Bearbeitet durch User
Vancouver schrieb: > Wie oben beschrieben, hängt der 595 an einem Labornetzteil, das getrennt > vom Arduino eingeschaltet werden kann. Wenn der 595 später als der > Arduino eingeschaltet wird, verhält er sich so, wie ich es gerne hätte. Da hast du aber großes Glück. Denn eigentlich darf die Spannung an keinem seiner Eingänge höher sein, als die Versorgungsspannung. Wenn dein Netzteil ausgeschaltet ist, hast du aber diese Situation.
Vancouver schrieb: > Wenn ich den 595 mit PU/PDs starte, sieht > er definierte Pegel auf den Steuerleitungen und legt trotzdem alle > Ausgänge auf High. Ich glaube, Du hast das Problem mit der Initialisierung noch nicht ganz überblickt. Die Steuerleitungen und Eingänge sind in erster Instanz gar nicht sooo wichtig. Es geht hier vielmehr um den Zustand der internen Latches. Und der ist undefiniert - ganz egal, was Du gerade an den Eingängen machst. Um zu verhindern, dass diese undefinierten Zustände des Latches auf die Ausgänge des Schieberegisters gelangen, musst Du !OE auf HIGH halten. Das ändert natürlich nichts an der Tatsache, dass auch die anderen Eingänge des Schieberegisters definierte Pegel haben sollten, aber das hat nicht zwangsläufig eine Auswirkung auf den Zustand der Ausgänge beim Einschalten. Also: 1) Power On + !OE HIGH 2) Initiale Serielle Daten auf das SR schicken 3) Latch + !OE auf LOW So "initialisiert" man ein Schieberegister.
Stefan ⛄ F. schrieb: > Da hast du aber großes Glück. Denn eigentlich darf die Spannung an > keinem seiner Eingänge höher sein, als die Versorgungsspannung. Wenn > dein Netzteil ausgeschaltet ist, hast du aber diese Situation. Ja, das ist nicht optimal, ist mir schon klar. War ja auch nur zum Experimentieren. Dummerweise macht die Schaltung damit, was sie machen soll.
Noch als Erweiterung zu der schon sehr guten Klarstellung von Summi: Es ist deine Aufgabe den IC so zu betreiben, dass er im spezifizierten Bereich läuft. (Bezogen auf die Pegel vom Arduino obwohl der HCT595 vom Labornetzteil noch nicht gespeißt wird.) Natürlich zeigt der IC auch ein Verhalten außerhalb seiner Spezifikationen, jeder IC verhält sich da irgendwie und oft genug kommt auch kein Rauch raus. Aber das Verhalten kann sich von IC zu IC verändern und auch der gleiche IC kann sich je nach Temperatur, Lust und Laune unterschiedlich verhalten. In diesem Fall ist zusätzlich noch der Zustand der internen Latches spezifiziert undefiniert. Es gibt sicher Wege da irgendwie, im Rahmen der Statistik, Einfluss zu nehmen - scheinbar hast du so einen Weg gefunden. Um herauszufinden, wieso das so einen Einfluss hat, bräuchte man die exakte Schaltung von dem Ding. Drauf verlassen kannst du dich natürlich trotzdem nicht. Also mach es richtig.
Hi, >Falk B. (falk) >Es gibt nicht nur ein Datenblatt von dem IC, sondern viele verschiedene. Wie wäre es mal mit anklicken? HCT595
>> Da hast du aber großes Glück. Denn eigentlich darf die Spannung an >> keinem seiner Eingänge höher sein, als die Versorgungsspannung. Wenn >> dein Netzteil ausgeschaltet ist, hast du aber diese Situation. > Ja, das ist nicht optimal, ist mir schon klar. Würde ich mal als Design-Fehler bezeichnen (auch wenn's nur eine Experimentierschaltung ist)
Johannes schrieb: > Es gibt sicher Wege da irgendwie, im Rahmen > der Statistik, Einfluss zu nehmen Ja, da hast du vermutlich recht. Durch irgendwas werden alle Bits manchmal zu Null, so wie ich es gerne hätte, aber man kann sich natürlich nicht darauf verlassen. Ich denke es wird darauf hinauslaufen, entweder den Bootloader so umzubauen, dass er den 595 sofort resettet, oder ich versuche das mit RC-Gliedern zu erreichen. Die sauberste Lösung mit gesteuertem ~oe wird aufwändig wegen der zusätzlichen Pull-Widerstände. Nun, mal sehen was daraus wird. Danke jedenfalls für eure Hinweise, das hat mir sehr geholfen!
Vancouver schrieb: > Das mit der parasitären Versorgung muss ich mal genau untersuchen, das > könnte gut sein. Siehe Pegelwandler. Miss einfach mal die Versorgungsspannung am 595 wenn dessen Versorgung ausgeschaltet ist.
Falk B. schrieb: > Siehe Pegelwandler. Miss einfach mal die Versorgungsspannung am 595 > wenn dessen Versorgung ausgeschaltet ist. Das habe ich vor, allerdings hängen da noch andere Lasten an der 5V-Domain. Ich schätze da wird nicht viel Spannung übrig bleiben. Aber das getrennte Einschalten von Arduino und HCT595 ist wohl so oder so keine gute Idee.
Angehängte Dateien:
Ich möchte nochmal auf diesen Vorschlag zurück kommen, den Falk leider ohne Begründung abgelehnt hat: Uwe schrieb: > und wie wäre es ~MR auf low zu halten? Wenn ich initial mittels Pull-Widerstände folgenden Zustand herstelle, müssten die Ausgänge initial alle auf Low sein, denke ich: /MR = LOW STCP = HIGH /OE = LOW Damit kann man sich die vielen Widerstände an den Ausgängen sparen. Falls da jetzt wieder ein "nein" kommt, dann bitte mit Begründung und ohne persönliche Angriffe. https://assets.nexperia.com/documents/data-sheet/74HC_HCT595.pdf
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Wenn ich initial mittels Pull-Widerstände folgenden Zustand herstelle, > müssten die Ausgänge initial alle auf Low sein, denke ich: Laut Datenblatt ist STCP ein echtes Clock-Signal, d.h. die Daten aus dem Schieberegister werden mit einer aktiven Flanke in das Ausgangsregister übernommen. Wenn nun alle Signale gleichzeitig die von dir beschriebenen Werte annehmen (beim Einschalten), dann wird das Schieberegister gleichzeitig gelöscht und ins Ausgangsregister übertragen. Die Frage ist, ob das zuverlässig für alle Bits funktioniert. Wäre STCP ein Latch-Enable, dann wäre es kein Problem, aber wie gesagt, des Datenblatt verlangt hier eine steigende Flanke. Diese könnte man etwas verzögert mit einem RC-Glied erzeugen, wie schon vorgeschlagen wurde.
Hängt von den Laufzeiten ab. Mit Pech latchen die Latches erst und nanosekunden später resettet das Schieberegister. Ich glaub nicht das da ein offiziell sicherer Zustand erreichbar ist, der "immer" funktioniert.
Vancouver schrieb: > die Daten aus dem Schieberegister werden mit einer > aktiven Flanke in das Ausgangsregister übernommen Schade, es wäre so einfach gewesen.
Vancouver schrieb: > Ich denke es wird darauf hinauslaufen, entweder den Bootloader so > umzubauen, dass er den 595 sofort resettet, oder ich versuche das mit > RC-Gliedern zu erreichen. Die sauberste Lösung mit gesteuertem ~oe wird > aufwändig wegen der zusätzlichen Pull-Widerstände. Es gibt beim uC kein 'sofort'. Die GPIO Pins verbleiben im High-Impedance Zustand solange die Resetsequenz noch nicht abgeschlossen ist. Das bedeutet die Spannung muss einen gewissen Level erreicht haben, und der Taktgenerator muss angeschwungen sein. Das kann je nachdem wie das Powersupply hochkommt und wie die Taktfrequenz gewählt ist, von ein paar Mikrosekunden bis Millisekunden dauern. In dieser Zeit, noch bevor der Bootloader läuft, macht der 595 was er will. Ob das für deine angeschlossene Hardware kritisch ist, musst du beurteilen. Vancouver schrieb: > ich habe ein seltsames Problem mit einem 74HCT595 (8-bit Schieberegister > mit parallelem Ausgang), der von einem Arduino Nano angesteuert wird. > Die Pins clk, strb, data und ~clr sind mit dem Arduino verbunden, ~oe > liegt fest auf GND. Wenn ~OE immer auf GND liegt, benötigst du die Tri-State Fähigkeit ja nicht. Weshalb nimmst du dann nicht ein 74HCT594, das hat keine Tri-State Ausgänge, dafür aber zwei Reset-Eingänge, die Shift und Storage Register definiert zurücksetzen. Wenn du diese beiden Eingänge (~SHR und ~STR) zusammenhängst, über einen Pull-Down auf GND legst und mit deinem '~clr' des Arduino verbindest, dann bleiben die Ausgänge solange auf Low bis der Arduino den '~clr' auf High setzt.
Ich sehe gerade, dass die Innenschaltung im Datenblatt von Texas wesentlich klarer dargestellt ist: https://www.ti.com/lit/ds/symlink/sn74hc595.pdf
Kuno schrieb: > Weshalb nimmst du dann nicht ein 74HCT594 Verflucht... der wäre wesentlich besser gewesen. Vor allem, weil beide Reset-Inputs Level-getriggert sind und keine Flanke benötigen. Bis auf den zusätzlichen Reset ist der sogar pinkompatibel. Mit einer durchtrennten Leiterbahn und einer Brücke zwischen den beiden Resets wäre mein Problem gelöst. Ein großes Danke für diesen Tip. Notiz an mich selbst (frei nach Schiller): Drum prüfe, wer den Stein verlöte, ob sich nicht was bessres böte.
Hi, Ok, 594 wäre die eindeutig bessere Variante, aber MR mit 10K gegen GND und STCP mit 470p gegen GND und 47K nach 5P wäre doch einfach mal einen Versuch wert. Könnte mir gut vorstellen das damit ein vernünftiges Reset erzeugt wird. Das sind 5 Lötpunkte. Ist denn das so schwer? Viel Erfolg, Uwe
Komisch, der 74HC594 kann man bei Reichelt und Conrad nicht kaufen. TME hat ihn aber. Die deutschen Händler kann man immer mehr in die Pfeife rauchen. Bei Amazon bekommt man auch nur den 595er.
Uwe schrieb: > Hi, > Ok, 594 wäre die eindeutig bessere Variante, aber > MR mit 10K gegen GND > und STCP mit 470p gegen GND und 47K nach 5P wäre doch einfach mal einen > Versuch wert. Murks. Der Austausch gegen 594 mit bissel Fädeldraht ist solide.
Stefan ⛄ F. schrieb: > Komisch, der 74HC594 kann man bei Reichelt und Conrad nicht kaufen. TME > hat ihn aber. Die deutschen Händler kann man immer mehr in die Pfeife > rauchen. > > Bei Amazon bekommt man auch nur den 595er. Vermutlich einer der Gründe, warum sich der für die meisten Anwendungen besser geeignete 594 NICHT etabliert hat und sie alle Welt mit dem Resetproblem rumplagt. 8-0 Digikey hat das Zeug tonnenweise in allen Gehäusetypen.
:
Bearbeitet durch User
Hi > Falk B. (falk) >Murks. Der Austausch gegen 594 mit bissel Fädeldraht ist solide. Bist du überhaupt in der Lage mal was vernünftiges zu schreiben? Uwe
Uwe schrieb: > Könnte mir gut vorstellen das damit ein vernünftiges Reset erzeugt wird. > Das sind 5 Lötpunkte. Ist denn das so schwer? Nichts ist daran schwer. Das werde ich auch testweise machen. Wenn es klappt, bleibt es so. Der 594 wäre die Alternative. Aber bei einem neuen Design würde ich gleich den 594 nehmen. In der Bucht findet man den übrigens recht häufig.
Vancouver schrieb: > Uwe schrieb: >> Könnte mir gut vorstellen das damit ein vernünftiges Reset erzeugt wird. >> Das sind 5 Lötpunkte. Ist denn das so schwer? > > Nichts ist daran schwer. Das werde ich auch testweise machen. Wenn es > klappt, bleibt es so. Der 594 wäre die Alternative. Aber bei einem neuen > Design würde ich gleich den 594 nehmen. In der Bucht findet man den > übrigens recht häufig. Euch beiden ist aber hoffentlich klar, daß die schnellen Bausteine der 74HCT Serie gewissen Ansprüche an die Flankensteilheit der Eingangssignale stellen. TI gibt 500 nsec als Maximum an, und der Vorschlag von Uwe liegt da weit darüber. Ob das dann bei unterschiedlichen Randbedingungen noch zuverlässig funktioniert ist mehr als fraglich. Der C verlangsamt das Signal übrigens immer, auch wenn es dann später vom uC geschaltet wird. Ich schließe mich der Meinung von Falk an, das ist ein schlechter Workaround der vielleicht funktioniert, aber eigentlich ist es Murks.
Uwe schrieb: > Hi, > Ok, 594 wäre die eindeutig bessere Variante, aber > MR mit 10K gegen GND > und STCP mit 470p gegen GND und 47K nach 5P wäre doch einfach mal einen > Versuch wert. > Könnte mir gut vorstellen das damit ein vernünftiges Reset erzeugt wird. > Das sind 5 Lötpunkte. Ist denn das so schwer? > > Viel Erfolg, Uwe Ohne jetzt nachgerechnet zu haben, aber im TI Dabla (https://www.ti.com/lit/ds/symlink/sn74hc595.pdf) steht z.B. drinnen, dass die Input Transition Time für 4.5V unter 500ns liegen muss/sollte. Es sind ein paar Seiteneffekte aufgelistet die auftreten, wenn man es nicht einhält, z.B. der hier: > If this device is used in the threshold region(from VILmax = 0.5 V to VIHmin = 1.5 V), there is a potential to go into the > wrong state from induced grounding, causing double clocking. Bleibt aber alles recht vage. Vermutlich hat kein Hersteller die Seiteneffekte vollständig dokumentiert weil sie normalerweise auch niemanden interessieren. Sicherheitshalber sollte man die RC Mimik aber mit einem Schmitt-Trigger Buffer ala 7014 entkoppeln, sonst ist man halt wieder außerhalb der Spezifikationen.
Hi,
>unter 500ns liegen muss/sollte
ok, die 470p waren auch nur aus dem Bauch raus, 160 oder 220p kann man
ja auch testen.
Übrigens so ungewöhnlich ist das mit der RC Kombi garnicht. Geht mal 10
bis 15 Jahre zurück, da war sowas recht oft zu finden, auch in der
Industrie.
Viel Erfolg, uwe
Uwe schrieb: > ok, die 470p waren auch nur aus dem Bauch raus, 160 oder 220p kann man > ja auch testen. Gehst du dabei davon aus, dass die Versorgungsspannung schlagartig von Null auf 5V springt? Falls nicht, fehlt mir gerade die Vorstellungskraft wie das funktionieren könnte.
:
Bearbeitet durch User
Der '594 ist wohl viel weniger gefragt. Den '595 gibt es auch als Fast, den '594 nicht.
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.