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
>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.
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.
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?
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.
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.
@ 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.
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.
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.
TimingSTP16CP05.png
(72 KB)
Mega8-595-SPI.png
(3,2 KB)
