Moin zusammen, ich spiele gerade mit zwei 74HC595 die ich mit einem Arduino betreibe, dazu gibt es haufenweise Tutorials, hier mal ein Beispiel: https://www.kollino.de/arduino/schieberegister-am-arduino-anschliessen/ Das Ganze funktioniert mit einem 74HC595 einwandfrei, der Zweite jedoch "macht das Gleiche wie der erste". Wenn man sich den Kaskadenausgang am Oszi anguckt, ahne ich auch warum. Die Flanke wechselt zwar wie am Q7 doch zwischendurch kommen Spitzen im Abstand wie Q0. Wo kann ich hier für die Fehlersuche ansetzen? Den IC habe ich schon getauscht, gleiches Verhalten. LG Tobias
Beitrag #6027791 wurde von einem Moderator gelöscht.
Beitrag #6027800 wurde von einem Moderator gelöscht.
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?
:
Bearbeitet durch User
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
Beitrag #6028126 wurde von einem Moderator gelöscht.
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".
Beitrag #6028218 wurde von einem Moderator gelöscht.
Beitrag #6028221 wurde von einem Moderator gelöscht.
Beitrag #6028229 wurde von einem Moderator gelöscht.
Beitrag #6028240 wurde von einem Moderator gelöscht.
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; } }
Beitrag #6028256 wurde von einem Moderator gelöscht.
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?
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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?
:
Bearbeitet durch Moderator
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.
:
Bearbeitet durch User
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.
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.