Servus, leider ist es mir untersagt meinen Code und Schaltplan zu veröffentlichen :( Bei mir funktioniert das Einlesen der Daten wohl nicht richtig. Die Schieberegister des 74HCT595 und STP16CP hängen am SPI-Modul meines ATmega1284p. OUTPUT-Enable des 74HCT595 und STP16CP sind an getrennten Pins. RCK-PIN des 595 ist am SS-Pin des SPI-Moduls, der Latch-Enable des STP16CP an einem verfügbaren Portpin. SCK des SPI-Moduls hängt an den 595er und dem STP16CP parallel MOSI ist mit dem ersten 595er verbunden, der dann mit einem zweiten verbunden ist, danach kommt erst der STP16CP, also alles kaskadiert hintereinander mithilfe der dafür vorgesehenen Ausgänge (*QH) Zur Vorgehensweise: Daten werden über MOSI gesendet (zuerst ein kleines Dummybyte, dann der Rest) SCK wird dabei abwechselnd auf High und Low geschaltet und bleibt nachdem das letzte Byte(8 Stück) auf High RCK wird nachdem das letzte Byte gesendet wurde kurz auf Low geschaltet und danach wieder auf High, Latch-Enable des STP16CP ist dauerhaft auf High während die Daten eintrudeln und wird dann auf Low geschaltet. Die Output-Enable Pins werden erst nachdem der Sendevorgang abgeschlossen ist, aktiviert. Ich hab so bissle den Verdacht, dass das Problem mit dem Latchenable des STP16CP zusammen hängt, allerdings brachte das dauernde Takten dieses Pins auch nichts :( Gruß Christian
Angehängte Dateien:
-
TimingSTP16CP05.png
72 KB -
Mega8-595-SPI.png
3,2 KB
>leider ist es mir untersagt meinen Code und Schaltplan zu >veröffentlichen :( Wieder ein Ratespiel? Deine Beschreibung ist recht wirr, ohne Schaltplan wirds auch nicht einfacher. Willst Du auf den 595 Daten ausgeben oder vom 595 welche einlesen?
Ziel ist es Daten an die Ausgänge der zwei 74HCT595 und des einen STP16CP05 zu liefern. Ich mals mal auf, wies verschalten ist. MOSI --> --|595|---|595|---|STP16CP05|-- SCK --> ---|595| SCK --> ---|595| SCK --> ---|STP16CP| SS --> RCK --|595| PINB0 -> LE --|STP16CP| PINB2 -> OE --|595| PINB3 -> OE --|STP16CP| Aktuell werden in der Software Timer 1 und Timer 3 verwendet. Das Problem ist, dass irgendwie die Daten nicht richtig eingelesen werden.
>die Daten nicht richtig eingelesen
Du willst doch was ausgeben, oder was versteh ich falsch????
ausgeben auf die Ausgänge der ICs und dazu muss ich sie zuerst ins Schieberegister eingeben
Christian schrieb: > leider ist es mir untersagt meinen Code und Schaltplan zu > veröffentlichen :( Das will auch keiner. Es reicht die relevante SPI-Funktion völlig aus. Bei SPI gibt es auch keine Geheimnisse. Man beachte die /SS = Input Falle. Christian schrieb: > danach kommt erst der STP16CP, also alles kaskadiert > hintereinander Ist der überhaupt für Kaskadierung geeignet? Nicht jeder SPI-Chip kann das.
Christian schrieb: > ausgeben auf die Ausgänge der ICs und dazu muss ich sie zuerst ins > Schieberegister eingeben Der Sprachgebrauch ist trotzdem 'ausgeben'. Aus Sicht des µC gibst du etwas an die Schieberegister aus. Man kommt sonst durcheinander, wenn jeder andere Begrifflichkeiten benutzt. Wenn nicht speziell und explizit anders angegeben, ist der µC das bestimmende Bauteil. Denn dort läuft ja auch das Programm.
Angehängte Dateien:
-
2013-06-26_124408.png
10 KB -
2013-06-26_124707.png
28 KB
Nachdem dieses IC über einen SDO (Datenausgang) verfügt, siehe Bild, denk ich mal, dass es eigentlich funktionieren müsste, auch wenn ich zugeben muss, dass ich das Bild mit den Taktflanken bezogen auf den Datenoutput doch etwas verwirrend finde. zum Thema SS-Pin: Er ist als Ausgang konfiguriert Da der Pin nur am RCK der zwei 595 parallel angeschlossen ist empfangen beide 595er quasi gleichzeitig den Low-Strobe, der Latch-Enable (LE-Pin) wird direkt danach kurz auf High gesetzt und sofort wieder auf Low, also quasi ein High-Strobe, wenn man das so sagen darf. Also liegen auch ein paar Takte dazwischen
kleiner Nachtrag: Der SPI-Modus ist auf 0 eingestellt CPOL (Clock Polarity) 0: Takt ist in Ruhe LOW, ein Wechsel auf HIGH zählt als steigende steigende Taktflanke CPHA (Clock Phase) 0: Daten werden bei steigender Taktflanke (=abh. von CPOL) eingelesen, bei fallender ausgegeben Zitat von mikrocontroller.net
Christian schrieb: > Nachdem dieses IC über einen SDO (Datenausgang) verfügt, siehe Bild, > denk ich mal, dass es eigentlich funktionieren müsste [...] Ähem....nicht jedes SPI-IC taktet am Ausgang das Gleiche heraus wie am Eingang hereinkommt. Bei einem EEPROM sollte z.B. am Eingang die Addresse und am Ausgang das gespeicherte Datum kommen. Oder sollen die Schieberegister die Rückgabewerte des STP16CP05 als Bitmuster darstellen?
Die sparen sich im Datenblatt da schon sehr aus, es steht aber auch nirgends, dass man die nicht kaskadieren könnte. Es gibt nur zwei Warnhinweise: If the device is connected in cascade, it may not be possible achieve the maximum data transfer. Please considered the timings carefully. Ob da jetzt mit Kaskadierung eine Kaskadierung von mehreren STP16CP gemeint ist oder in Verbindung mit anderen geht nicht klipp und klar hervor, jedenfalls für mich. Die beiden Pins für Dateneingang und Datenausgang heißen halt auch Serial Data input terminal, Serial Data out terminal Eigentlich müsste doch da im Datenblatt erwähnt werden, dass es nicht möglich ist, weitere Schieberegister anzuschließen, falls das nicht möglich ist?
Angehängte Dateien:
-
2013-06-26_133357.png
14 KB
sorry für den neuen Nachtrag, das ist die Schaltung des Serial Data out Ich bin erst im 2. Lehrjahr, wenn ich das richtig sehe wird das Signal inventiert? N-Kanal FET unten ist bei einem Highpegel durchlässig, der P-Kanal FET oben sperrt. Also wird die SDO-Leitung bei einem Highpegel am Anfang auf einen Low-Pegel am Ausgang gezogen? Das steht aber etwas im Widerspruch zum Timing-Diagramm
Christian schrieb: > Eigentlich müsste doch da im Datenblatt erwähnt werden, dass es nicht > möglich ist, weitere Schieberegister anzuschließen, falls das nicht > möglich ist? Soweit mir bekannt, ist es in Datenblättern genau umgekehrt. Features werden nur dann genannt, wenn sie möglich sind. Alles, was nicht geht, wird verschwiegen. Ein Datenblatt soll ja auch Werbung sein. Ich bin da auch schon reingefallen. Z.B ein R2R-OPV, wo nicht drin steht, daß er Latchup fest ist, der hat definitiv einen Latchup.
Angehängte Dateien:
-
2013-06-26_142404.png
110 KB
also in der Application Note hängen die auch 2 hintereinander, siehe Bild. Die Typen sind zwar nicht ganz identisch, der Aufbau ist aber gleich
Mir hat man jetzt endlich erlaubt den aktuellen Code, der so nicht funktioniert zu veröffentlichen
1 | //'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' |
2 | |
3 | void SPI_MasterInit(void) |
4 | {
|
5 | // SPI Ausgänge und Ports konfigurieren |
6 | DDRB |= (1<<DDB0) | (1<<DDB1) | (1<<DDB2) | (1<<DDB3) | (1<<DDB4); // LE (STP16), SCL, OE595, OESCP16, SS in genau dieser Reihenfolge auf Ausgang |
7 | DDRB |= (1<<DDB5) | (1<<DDB7); // MOSI, SCK, genau in dieser Reihenfolge auf Ausgang |
8 | DDRB &= ~ (1<<DDB6); // MISO auf Eingang |
9 | |
10 | // SPI Master, Takt FPU / 4 |
11 | SPCR |= (1<<SPE)|(1<<MSTR); |
12 | SPCR &= ~ (1<<SPR0) | (1<<SPR1); |
13 | |
14 | // Set SPI Mode 0 |
15 | SPCR &= ~((1 << CPHA) | (1 << CPOL)); // SPI-Modus |
16 | |
17 | SPSR |= (0<<SPI2X); |
18 | |
19 | } |
20 | |
21 | //'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' |
22 | |
23 | void SPI_MasterTransmit(unsigned char cData) |
24 | {
|
25 | /* Start transmission */ |
26 | SPDR = cData; |
27 | /* Wait for transmission complete */ |
28 | while(!(SPSR & (1<<SPIF))); |
29 | |
30 | // Verzögerung |
31 | |
32 | _delay_us(1); |
33 | |
34 | } |
35 | |
36 | //'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' |
37 | |
38 | void SPI_refreshData(void) |
39 | {
|
40 | PORTB &= ~ (1<<PB4); // Lowstrobe für RCK |
41 | PORTB |= (1<<PB0); // Highstrobe für LE des STP16CP05 |
42 | |
43 | _delay_us(1); |
44 | |
45 | PORTB |= (1<<PB4); |
46 | PORTB &= ~ (1<<PB0); |
47 | } |
Eine Datenfolge sieht dann bei mir so aus: SPI_MasterTransmit(0x0F); SPI_MasterTransmit(0x00); SPI_MasterTransmit(0xF0); SPI_MasterTransmit(0x02); SPI_refreshData(); Die delays sind drinne, weil ich gelesen hab, dass man mindestens 2 Takte Zeit dazwischen braucht, was so aber sicher nicht ganz optimal ist? SPI_refreshData() soll den Low, beziehungsweise Highstrope auslösen, damit die Daten auch übernommen werden Gruß Christian
UNd wenn ich dich jetzt richtig verstanden habe, dann sind die Outputs
der 595 korrekt, während die Output-Pins des 16CP falsch sind?
d.h. die beiden 595 zeigen
0x02
0xF0
der 16CP sollte eigentlich 0x00
ausgeben, gibt aber was? aus?
ich kann dir nicht genau sagen was passiert, das ganze Ding flattert umher. Mal ist was gesetzt, mal nix genau, die ersten 2 Byte sind für die 2 IC 74 595, die letzten 2 Byte für das IC STP16CP05 was haltet ihr denn überhaupt von dem Code? Gruß Christian
Lt. Datenblatt ist der STP16CP05 auch nur ein SRG, Kaskadieren also möglich. Die Übernahme erfolgt mit LE = high, wie beim CD4094. Beim Schieben muß LE = low sein. Schick doch mal 0xFFFFFFFF und mal 0x00000000 an die Kette und erzähle, was rauskommt. Die SRG sind ja schnell (30MHz), da kann es leicht zu Störungen kommen. SPI geht eh nur mit ganz kurzen Leitungen, schon der Weg zu einer Tochterplatine kann zu lang sein. Eine GND-Plane und 100nF an jedem IC sind Pflicht.
@ Peter Dannegger (peda) >Die SRG sind ja schnell (30MHz), da kann es leicht zu Störungen kommen. Jain. >SPI geht eh nur mit ganz kurzen Leitungen, schon der Weg zu einer >Tochterplatine kann zu lang sein. Und morgen fällt uns der Himmel auf den Kopf. 8-0 Wenn man weiß was man tut, geht SPI über recht lange Kabel. >Eine GND-Plane Nein. > und 100nF an jedem IC sind Pflicht. Sicher. http://www.mikrocontroller.net/articles/Kondensator#Entkoppelkondensator
100nF an der VCC sind natürlich dorten, GND Plane ebenfalls, ob des sogut war wie ichs gemacht hab... Wenn ich alle auf 0xffffffff setze kommen da trotzdem sehr seltsamme Muster raus, manche sind Low, manche High, selbes passiert bei 0x00000000 Der Weg zur Tochterplatine sind über die verdrillten Kabel etwa naja 8cm kommen ganz gut hin. Der SPI-Takt beträgt 5 Mhz Ist der Code mit den Pausen und so wirklich in Ordnung. Die aus der Hardwareabteilung haben gemeint, dass die Platine zwar nicht optimal designed ist, aber für so eher niedrigere Frequenzen doch noch gut genug ist.
Christian schrieb: > manche sind Low, manche High Solche Fehlerbeschreibungen sind sinnlos. Du must schon konkret werden. Z.B. 10-mal 0xFFFFFFFF Messung 1: *** ... Messung 10: *** Christian schrieb: > Ist der Code mit den Pausen Die Pausen sind egal. Die Flanken können übersprechen und stören oder Reflexionen.
Falk Brunner schrieb: > Und morgen fällt uns der Himmel auf den Kopf. Nicht jeder macht von Geburt an gute Layouts (außer Dir natürlich). SPI klingt nur einfach, isses aber nicht. Ich hab schon Leute tagelang daren verzweifeln gesehen, mit Kondensatoren und Widerständen daran rumlötend. Ich meide ihn, sobald die Platine verlassen wird. SPI ist kein Anfängerbus, wenn man es zuverlässig mag.
@ Peter Dannegger (peda) >Nicht jeder macht von Geburt an gute Layouts (außer Dir natürlich). Das hat keiner behauptet. >SPI klingt nur einfach, isses aber nicht. Bitte nicht übertreiben. >Ich hab schon Leute tagelang >daren verzweifeln gesehen, mit Kondensatoren und Widerständen daran >rumlötend. Leute, denen es an Grundlagen fehlt. Das macht SPI aber nicht wirklich anspruchsvoll. Gehauso wie die leidigen Diskussionen über - LEDs ohne Vorwiderstand - UART mit RC-Oszillator - etc. >Ich meide ihn, sobald die Platine verlassen wird. Dafür ist er auch nicht gedacht, aber eine Handbreit über Kabel zur nächsten Platine/Frontplatte etc. geht schon, auch wenn es Stolperfallen gibt. >SPI ist kein Anfängerbus, wenn man es zuverlässig mag. Sehe ich anders. Siehe oben.
Insgesamt sind für alle Schieberegister ja nur eigentlich 4 Byte erforderlich Messung 1 bis 5: Versuch: Gesendet wurde 0xFFFFFFFF Ergebnis: An den Ausgängen der Bausteine 74HCT595 treten wirre Sachen auf, obwohl eigentlich alle gesetzt sein sollten. Wirre Sache heißt, dass die Ausgänge zwischen High und Low-Pegel immer hin und herwechseln. der genaue Code war
1 | SPI_MasterInit(); |
2 | |
3 | PORTB &= ~ (1<<PB0); // LE des STP16CP05 auf Low |
4 | |
5 | SPI_MasterTransmit(0xFF); |
6 | SPI_MasterTransmit(0xFF); |
7 | SPI_MasterTransmit(0xFF); |
8 | SPI_MasterTransmit(0xFF); |
9 | |
10 | SPI_refreshData(); |
Kann es was mit dem RCK des 595 zu tun haben? Ich dachte dieser erfordert einen High --> Low --> High Wechsel, hier im Wiki hab ich gerade eben gelesen, dass es Low --> High --> Low sein muss
Falk Brunner schrieb: > aber eine Handbreit über Kabel zur > nächsten Platine/Frontplatte etc. geht schon, auch wenn es Stolperfallen > gibt. Ich hab auch SPI früher oft über Kabel eingesetzt. Aber daß es so richtig rock-solid läuft, kann ich nicht behaupten. Z.B. hatte ich ne Anzeige mit MAX7219 an 20cm Flachkabel. Und wenn das Plasma zündete, hat er manchmal seine Einstellungen verloren. Ich hab dann in der Main-Loop den MAX7219 jedesmal neu initialisiert und neu ausgegeben. In einem anderen Projekt habe ich vor die HC595 einen langsamen CD4093 zur Filterung setzen müssen, erst dann lief es an 30cm Kabel. Nur ein EA-DOGM scheint auch an langem Kabel (50cm) stabil zu laufen, vermutlich ist es langsam genug.
hallo Leute, Christian sind denk ich mittlerweile die Probleme mit SPI klar, ihm gehts ja um den Code
@ Peter Dannegger (peda) >Ich hab auch SPI früher oft über Kabel eingesetzt. >Aber daß es so richtig rock-solid läuft, kann ich nicht behaupten. Das kann viele Gründe haben. Ist aber nicht die Schuld von SPI sondern von vielen Missverständnissen zum Thema Wellenwiderstand. >Z.B. hatte ich ne Anzeige mit MAX7219 an 20cm Flachkabel. Und wenn das >Plasma zündete, hat er manchmal seine Einstellungen verloren. >Ich hab dann in der Main-Loop den MAX7219 jedesmal neu initialisiert und >neu ausgegeben. Naja, ein Workaround, manchmal geht es nicht besser. >In einem anderen Projekt habe ich vor die HC595 einen langsamen CD4093 >zur Filterung setzen müssen, erst dann lief es an 30cm Kabel. ;-) Die bösen Kabel. Es geht auch mit recht langen Kabeln. Beitrag "Re: Skurriles Problem mit BS170 Mosfets" Hier der Aufbau, deutlich mehr als 30cm. Beitrag "Re: Skurriles Problem mit BS170 Mosfets"
Christian schrieb: > Ich dachte dieser erfordert einen High --> Low --> High Wechsel, hier im > Wiki hab ich gerade eben gelesen, dass es Low --> High --> Low sein muss Was sagt das Datenblatt zum 595? Das sagt, dass es die steigende Flanke ist, die dafür sorgt, dass die Werte aus der Schiebekette in die Ausgangsregister übernommen werden. Du musst auf solche Details achten, ob Eingänge pegelgesteuert oder flankengesteuert sind.
Wart mal, ich muss mal mit dem Datasheet aufdröseln was hier
> SPCR &= ~ (1<<SPR0) | (1<<SPR1);
wirklich passiert und ob das kritisch ist. Da fehlt nämlich eine Klammer
SPCR &= ~ ((1<<SPR0) | (1<<SPR1));
Edit:
Hast Glück gehabt (eigentlich Pech), das macht nichts ungewolltes.
mein aktueller Code: Die Klammern wurden sobald mehr als nur eins gesetzt wird, komplett drum herumgefügt :) Es scheint jetzt schon deutlich weniger herumzuzicken, aber leider ist es immernoch so, dass die Bausteine 595 und STP16 das eingegebene Zeug nicht korrekt ausgeben.
1 | //'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' |
2 | |
3 | void portDefinition_SPI(void) |
4 | {
|
5 | //SPI |
6 | |
7 | DDRB |= ((1 << DDB4) | (1 << DDB5) | (1 << DDB7)); // SPI Pins auf Ausgang |
8 | DDRB &= ~ ((1 << DDB6)); // MOSI auf Eingang |
9 | DDRB |= ((1 << DDB0) | (1 << DDB1) | (1 << DDB2) | (1 << DDB3)); // LE, SCL, OE595 und OESCP16 auf Ausgang, genau in dieser Reihenfolge |
10 | |
11 | PORTB &= ~ (1<<PB4); // RCK für 595 auf Low |
12 | PORTB &= ~ (1<<PB0); // LE auf Low setzen |
13 | |
14 | PORTB |= ((1<<PB2) | (1<<PB3)); // OutputEnable auf High --> Status Z |
15 | } |
16 | |
17 | //'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' |
18 | |
19 | void SPI_MasterInit(void) |
20 | {
|
21 | // SPI Ausgänge und Ports konfigurieren |
22 | DDRB |= ((1<<DDB0) | (1<<DDB1) | (1<<DDB2) | (1<<DDB3) | (1<<DDB4)); // LE (STP16), SCL, OE595, OESCP16, SS in genau dieser Reihenfolge auf Ausgang |
23 | DDRB |= ((1<<DDB5) | (1<<DDB7)); // MOSI, SCK, genau in dieser Reihenfolge auf Ausgang |
24 | DDRB &= ~ ((1<<DDB6)); // MISO auf Eingang |
25 | |
26 | // SPI Master, Takt FPU / 4 |
27 | SPCR |= ((1<<SPE)|(1<<MSTR)); |
28 | SPCR &= ~ ((1<<SPR0) | (1<<SPR1)); |
29 | |
30 | // Set SPI Mode 0 |
31 | SPCR &= ~((1 << CPHA) | (1 << CPOL)); // SPI-Modus |
32 | |
33 | SPSR |= (0<<SPI2X); |
34 | |
35 | } |
36 | |
37 | //'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' |
38 | |
39 | void SPI_MasterTransmit(unsigned char cData) |
40 | {
|
41 | /* Start transmission */ |
42 | SPDR = cData; |
43 | /* Wait for transmission complete */ |
44 | while(!(SPSR & (1<<SPIF))); |
45 | |
46 | // Verzögerung |
47 | |
48 | _delay_us(1); |
49 | |
50 | } |
51 | |
52 | //'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' |
53 | |
54 | void SPI_refreshData(void) |
55 | {
|
56 | PORTB |= (1<<PB4); // Highstrobe für RCK |
57 | PORTB |= (1<<PB0); // Highstrobe für LE des STP16CP05 |
58 | |
59 | _delay_us(1); |
60 | // |
61 | PORTB &= ~ (1<<PB4); // RCK für 595 wieder auf Low |
62 | PORTB &= ~ (1<<PB0); // LE wieder auf Low setzen |
63 | } |
64 | |
65 | //'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' |
66 | |
67 | void SPI_enableOutputs(void) |
68 | {
|
69 | PORTB &= ~ ((1<<PB2) | (1<<PB3)); // OutputEnable auf Low --> Status Output an |
70 | //_delay_us(1); |
71 | } |
72 | |
73 | //'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' |
74 | |
75 | void SPI_disableOutputs(void) |
76 | {
|
77 | PORTB |= ((1<<PB2) | (1<<PB3)); // OutputEnable setzen --> Status Z |
78 | //_delay_us(1); |
79 | } |
Die Sequenz sieht folgendermaßen aus: Das Ergebnis: Nicht alle Bits sind auf High
1 | for(int j=0 ; j=1; j++) |
2 | {
|
3 | |
4 | portDefinition_SPI(); |
5 | |
6 | SPI_MasterInit(); |
7 | |
8 | SPI_MasterTransmit(0xFF); |
9 | SPI_MasterTransmit(0xFF); |
10 | SPI_MasterTransmit(0xFF); |
11 | SPI_MasterTransmit(0xFF); |
12 | |
13 | SPI_refreshData(); |
14 | |
15 | SPI_enableOutputs(); |
16 | } |
2. Versuch: dieses Mal ohne for-Schleife Das Ergebnis: Die Ausgänge sind mal gesetzt, mal nicht, springen also hin und her
Hmm. Wenn ich daran zurückdenke, dass bei meinen ersten Versuchen mit einem 595 dieser eigentlich auf Anhieb am SPI funktioniert hat, erscheint mir die Möglichkeit eines Hardware-Fehlers (Lötbrücke, sonst irgendwas) nicht mehr als völlig ausgeschlossen. Zum STP16CP kann ich nichts sagen, den kenn ich nicht und hatte den noch nie in den Fingern. Ich kann dir nur sagen, was ich jetzt mal machen würde. Ich würde mal alles abklemmen, bis auf einen einzigen 595. Und dann würde ich schön langsam und händisch (also nicht mit der SPI Einheit) durch Pinwackeln dem ein Testbyte reintakten. Wenn das an den Ausgängen sauber erscheint, dann gut, dann steigere ich erst mal die Geschwindigkeit und wenn dann immer noch nichts aussergewöhnliches passiert, dann probier ich dasselbe mit der SPI Einheit. Wenn aber das händische Reintakten schon nicht funktioniert, dann klemm ich mir Messmittel an die Leitungen (Logik-Analyser oder wenn keiner verfügbar ist auch einfach nur ein paar LED, daher auch die Sache mit 'langsam') und seh mir mal an, welche Leitungen nicht die erwarteten und vorgegebenen Pegel haben. Dann sieht man schon mal mehr. Zugegeben, das hört sich jetzt aufwändig und zeitraubend an. Wenn ich jetzt auf der anderen Seite bedenke, dass du jetzt schon fast 3 Tage an diesem Problem sitzt und nicht weiter kommst, dann relativiert sich das alles wieder. So wie jetzt allerdings ist das ein Stochern im Nebel und kein zielgerichtetes Debugging.
TamTam schrieb: > Das Ergebnis: Die Ausgänge sind mal gesetzt, mal nicht, springen also > hin und her Bei der Ausgabe oder danach? Die Ausgänge müssen stabil bleiben, solange der der STP low an LE und 595 keine high Flanke auf RCLK sieht. Für mich sieht das so aus, als hängen RCLK/LE in der Luft.
bereits überprüft, Lötstellen sehen sauber aus, Durchpiepser zeigt auch ne gute Verbindung an.
Früher hatten sich Bastler als erstes einen TTL-Prüfstift gebaut. Der konnte low, high, verboten und gepulst anzeigen. "verboten" war nützlich, um Kurzschlüsse zu anderen Ausgängen (Datenkämpfe) zu erkennen. Aufgebrauchte Textmarker dienten als Gehäuse.
Also, wenn man langsam was reintacket scheints meistens zu gehen. Ich hab bei mir übersehen, dass die Ansteuerung ja durch die P-Mosfets inventiert ist, allerdings erklärt das nicht das flackern.
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.