74HC595 Pegel am Kaskaden-Ausgang

Tobias M. schrieb:
> Das Ganze funktioniert mit einem 74HC595 einwandfrei...

Deshalb wäre es schon mal hilfreich deine Schaltung bzw. deinen Aufbau 
zu sehen. Die Verlinkung ist hierbei nicht besonders hilfreich.

Auf ggf. fehlende Abblockkondensatoren wurde bereits hingewiesen.

Und was heißt...“der Zweite jedoch macht das Gleiche wie der erste"?
Du schiebst ein „H“ in den ersten Chip, und der 2te Chip zeigt das auch 
an?

Moin zusammen,

ich hatte heute Morgen nur kurz Zeit das händisch zu testen. Ein 
Anklemmen eines (100nF) Abblockkondensators hat keines der Signale auch 
nur ansatzweise verändert.

Wenn ich mir den Pegel der Versorgungsspannung angucke ist der auch 
schön glatt.

Was mich wundert: Am Q7 kommt ein sauberes Signal raus, am Q7' dieses 
Rumgekasper.

Der zweite zeigt genau das Gleiche an wie der erste (ist ja klar wenn 
der Takt durch diese Spitzen exakt der ist wie am Takteingang vom 
ersten).

Das Ganze ist auf einer Platine wo noch einige andere Sachen mit rauf 
sollen, außer dem Arduino und den beiden 74HC595 ist aber noch nichts 
bestückt. Trotzdem machen die anderen Sachen das Ganze sehr 
unüberichtlich, ich versuche das nachher mal alleine auf ein Steckbrett 
zu bringen...

LG
Tobias

Tobias M. schrieb:
> Der zweite zeigt genau das Gleiche an wie der erste (ist ja klar wenn
> der Takt durch diese Spitzen exakt der ist wie am Takteingang vom
> ersten).

Sehr unwahrscheinlich.
Das ginge nur, wenn Du beide SER (14) parallel schaltest.
SER des 2. kommt an QH' (9) des 1.
Und ohne Flanke an RCLK (12) bleiben alle QA..QH unverändert.

Peter D. schrieb:
> Und ohne Flanke an RCLK (12) bleiben alle QA..QH unverändert.

Woher soll er wissen ob und wann da eine Flanke kommt. Er wird eine 
fertige lib nutzen welche das alles tut. Er muss die Dinger nur korrekt 
verschalten. Schon daran scheitert er. Komm ihm doch nicht mit der 
Funktionsweise der Dinger. Das ist Low-level der 80er.

Cyblord -. schrieb im Beitrag #6028126:
> Ich habe genau diese Dinger schon zig mal aufm Steckbrett ohne Abblock C
> betrieben, ohne irgendwelchen SchnickSchnack und die tun halt einfach
> was sie sollen. Da brauchts kein Vodoo.

Stimmt, kann ich so bestätigen, die Teile sind extrem brav.

lowlevel schrieb im Beitrag #6027791:
> Lol, vom Dickethaloszi Bilder abfotografieren.

Statt des Oszilloskops hätte er mal besser den Schaltungsaufbau 
fotografiert. Den aktuellen Sketch anzuhängen wäre auch nicht zu viel 
verlangt.

Hier noch ein kleines Bildchen wie ich die Teile beschalte um möglichst 
wenig IOs zu benötigen. Die Kondensatoren kann man tatsächlich 
weglassen, ich bestücke sie trotzdem, quasi "Angstkondensatoren".

Sketch...

int shiftPin = 8;
int storePin = 11;
int dataPin = 12;

unsigned short counter = 0;

void setup() {
 pinMode(storePin, OUTPUT);
 pinMode(shiftPin, OUTPUT);
 pinMode(dataPin, OUTPUT);
}


void loop () {
 digitalWrite(storePin, LOW);
 shiftOut(dataPin, shiftPin, MSBFIRST, counter);
 digitalWrite(storePin, HIGH);
 delay(15);

 counter ++;
 if (counter > 65536) {
   counter = 0;
 }
}

Tobias M. schrieb:
> Sketch...

Hallo Tobias,

weshalb zeigst Du den Aufbau und DEIN Schaltbild nicht, so dass man was 
erkennen kann?

Tobias M. schrieb:
> hier mal ein Beispiel:

https://www.kollino.de/arduino/schieberegister-am-arduino-anschliessen/

Was heißt denn Beispiel? Wenn du Hilfe benötigst ist es wichtig dass zu 
sehen um was es tatsächlich geht. Wie soll das Problem sonst gelöst 
werden. Zudem habe ich ehrlich gesagt keine Lust anhand dieses Aufbaus 
nach evtl. Fehlern zu suchen.

Unabhängig davon, hast Du mal andere ICs verwendet, oder hast Du nur die 
2?

Den IC habe ich getauscht, Aufbau schaffe ich hoffentlich heute Abend...

Er könnte auch mal mit dem Oszi mehrere Signale gleichzeitig messen. Vor 
allem den Schiebetakt und die Daten. Gleich am Eingang des ersten 
Schiebergisters. Dann würde man mal sehen ob der Arduino überhaupt das 
ausgibt was du haben möchtest.
Das hat nämlich einen Grund wieso so Oszis mehrere Eingänge haben ...

Tobias M. schrieb:
> shiftOut(dataPin, shiftPin, MSBFIRST, counter);

Wie ist das definiert?
Üblich sendet das SPI nur 8 Bit.
Das erklärt dann auch, warum beide das gleiche ausgeben. Es wird beim 
nächsten Durchlauf das gleiche Byte (MSB) gesendet.

Tobias M. schrieb:
> if (counter > 65536) {

Diese Zeile ist immer false.

Peter D. schrieb:
> Wie ist das definiert?
> Üblich sendet das SPI nur 8 Bit.

Wie kommst du hier auf SPI?!

Hier ist die Referenz die man auch selber schnell hätte googeln können 
... 
https://www.arduino.cc/reference/de/language/functions/advanced-io/shiftout/

So wie ich das verstehe macht

shiftOut(dataPin, shiftPin, MSBFIRST, counter);

folgendes:
Es schiebt den Wert von Counter, also alle 16 Bits, auf dem dataPin 
hinaus und für jedes Bit wird einmal am shiftPin gewackelt.

Gustl B. schrieb:
> Wie kommst du hier auf SPI?!

Ob HW-SPI oder SW-SPI ist doch nun wurscht.

Gustl B. schrieb:
> Hier ist die Referenz die man auch selber schnell hätte googeln können

Und was steht denn da?
"Shiftet ein Byte von Daten hinaus"

Quod erat demonstrandum

Peter D. schrieb:

> Tobias M. schrieb:
>> if (counter > 65536) {
>
> Diese Zeile ist immer false.

Ja hast natürlich Recht, ich ändere den Typ. Ändert aber nichts am 
Grundproblem wenn man am zweiten IC am Q1 oder Q2 misst... Das war auch 
mal int, war aber das gleiche Problem...

Ich reiche die ganzen Infos heute Abend nach...

Tobias M. schrieb:
> Ja hast natürlich Recht, ich ändere den Typ.

Warum? Die Zeilen sind einfach nur völlig sinnlos, da der Typ da ja eh 
wieder auf Null spring!

Tobias M. schrieb:
> der Zweite jedoch
> "macht das Gleiche wie der erste".

Logisch! Da shiftOut nur mit 8 Bit arbeitet werden beim zweiten Aufruf 
die ersten 8 Bit in das zweite Schieberegister geschoben. Die Ausgänge 
der beiden Schieberegister unterscheiden sich, von weiteren Überträgen 
abgesehen, im Wesentlichen in Bit 0.

Mario M. schrieb:
> Tobias M. schrieb:
>> der Zweite jedoch
>> "macht das Gleiche wie der erste".

Warum ist es eigentlich schon zuviel, wenn man schon kein HW SPI 
verwendet, dass man einfach mal die 3 Signale selbst bedient, anstatt 
alle Daten in ne lib Funktion zu rotzen die dann das falsche tut?

Probier mal das:

1

int shiftPin = 8;

2

int storePin = 11;

3

int dataPin = 12;

4

5

unsigned short counter = 0;

6

7

void setup() {

8

 pinMode(storePin, OUTPUT);

9

 pinMode(shiftPin, OUTPUT);

10

 digitalWrite(shiftPin, LOW); //wegen steigender Flanke

11

 pinMode(dataPin, OUTPUT);

12

}

13

14

15

void loop () {

16

 digitalWrite(storePin, LOW);

17

 shiftOut(dataPin, shiftPin, MSBFIRST, highByte(counter));

18

 shiftOut(dataPin, shiftPin, MSBFIRST, LowByte(counter));

19

 digitalWrite(storePin, HIGH);

20

 delay(15);

21

 counter++;

22

}

Mario M. schrieb:
> Die Ausgänge der beiden Schieberegister unterscheiden sich, von
> weiteren Überträgen abgesehen, im Wesentlichen in Bit 0.
Und von der Polarität, weil der /Q Ausgang weitergereicht wird.

Peter D. schrieb:
> Tobias M. schrieb:
>> if (counter > 65536) {
> Diese Zeile ist immer false.
Aber zum Glück auch völlig unnötig. Denn den Überlauf von 65535 nach 0 
kann so ein short von ganz alleine...

Tobias M. schrieb:
> Wo kann ich hier für die Fehlersuche ansetzen?
Bei einer synchronen seriellen Schnitte müssen immer die Daten zusammen 
mit dem Clock angeschaut werden. Und dann musst du nur noch 
kontrollieren, ob das Timing sämtlicher Steuersignale insgesamt zu dem 
passt, was der Baustein an seinen Pins laut Datenblatt erwartet.


BTW: können wir bitte diesen unnötig unflätigen und unsachlichen Tonfall 
zuhause lassen?

Peter D. schrieb:
> Und was steht denn da?
> "Shiftet ein Byte von Daten hinaus"

Respekt! Du hast es vermutlich gefunden. Da war ich zu ungründlich. 
Wieder was gelernt.

Cyblord -. schrieb:
> Warum ist es eigentlich schon zuviel, wenn man schon kein HW SPI
> verwendet, dass man einfach mal die 3 Signale selbst bedient, anstatt
> alle Daten in ne lib Funktion zu rotzen die dann das falsche tut?

Also Libs machen das Leben einfacher. Aber gerade um Bauteile oder Dinge 
in Betrieb zu nehmen mit denen man noch nichts gemacht hat und die man 
verstehen will ist eine Lib hinderlich.
Wenn man nicht lernen will oder zumindest nicht das lernen will sondern 
schnell zu einem anderen Ziel kommen will finde ich Libs völlig OK. Sie 
machen aber oft den Code fett.

Gustl B. schrieb:
> Also Libs machen das Leben einfacher. Aber gerade um Bauteile oder Dinge
> in Betrieb zu nehmen mit denen man noch nichts gemacht hat und die man
> verstehen will ist eine Lib hinderlich.

Das Problem ist eben, kennt man die Funktion des Bausteins nicht, kann 
man nicht beurteilen ob eine lib, vor allem wenn sie eine generische 
Funktion erfüllt, überhaupt geeignet ist. Und selbst wenn, verwendet man 
sie vielleicht falsch.

Und um ein Schieberegister in Betrieb zu nehmen würde ich erst mal Bit 
Banging machen wenn man keine Ahnung hat. Und später sowieso auf HW-SPI 
gehen wenns ordentlich sein soll.

Gustl B. schrieb:
> Aber gerade um Bauteile oder Dinge
> in Betrieb zu nehmen mit denen man noch nichts gemacht hat und die man
> verstehen will ist eine Lib hinderlich.

Nö, man muß eben nur die Beschreibung der Lib lesen. Niemand hindert 
Dich daran diese Funktion mehrfach aufzurufen.
Man könnte die Lib auch um eine Blockroutine erweitern, der dann die 
Anzahl Bytes und der Pointer auf das Array übergeben wird.

Der Fehler befindet sich ja außerhalb der Lib, nämlich das nach nur 
einem Byte das Latch gepulst wird.

Peter D. schrieb:
> Und was steht denn da?
> "Shiftet ein Byte von Daten hinaus"

Mario M. schrieb:
> Probier mal das:
>
>  shiftOut(dataPin, shiftPin, MSBFIRST, highByte(counter));
>  shiftOut(dataPin, shiftPin, MSBFIRST, LowByte(counter));


Oh mann, ja das war es, 1000 Dank!


Der Überlauf bei short passiert laut reference übrigens schon deutlich 
früher.

https://www.arduino.cc/reference/de/language/variables/data-types/short/

Ich denke die Abfrage unten ist ok, nur sollte der Typ dann int sein.

LG
Tobias

Tobias M. schrieb:
> Der Überlauf bei short passiert laut reference übrigens schon deutlich
> früher.

Überlauf eines vorzeichenbehafteten Datentyps verursacht undefiniertes 
Verhalten. Der Wert kann also von 32767 auf -32768 überlaufen, er kann 
bei 32767 stehen bleiben, oder er kann genauso gut 42 werden.

Im Gegensatz dazu hast du einen vorzeichenlosen Datentyp; dessen 
Überlauf ist wohl definiert, und bei 16 Bit läuft er von 65535 nach 0 
über.