Problem mit Arduino-Nano und HCT595

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?

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

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.

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.

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.

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:
> 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...

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.

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

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.

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

Oh, meinte 74HCT595

>> 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!

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.

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

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.

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.

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.

Der '594 ist wohl viel weniger gefragt.
Den '595 gibt es auch als Fast, den '594 nicht.