74hc595 + 74hc165 clock phase an SPI hardware

OP #4092757
Lesenswert?

Huhu,

ich bastel gerade an einer Benutzeroberfläche herum, die u.a. 74HC595 
und 74HC165 für eine Matrixschaltung verwendet.
Die Schieberegister hängen an einem gemeinsamen SPI (SCK teilen sie 
sich, MISO/MOSI und die beiden LOAD-Leitungen sind getrennt). Ich möchte 
parallel Daten an den 74hc595 rausschieben und Daten vom 74HC165 
einlesen. Das hat man so ja schon oft gesehen und sollte eigentlich kein 
Problem sein.

Mich verwundert etwas bezüglich der Clock-Phase: Der 595 übernimmt die 
Daten mit der steigenden Flanke (CPHA=1), der 165 schiebt die Daten mit 
der steigenden Flanke raus (CPHA=0). Das bedeutet doch, dass ich die gar 
nicht parallel an einem Hardware SPI betreiben kann, da der sich ja nur 
auf entweder CPHA=1 oder CPHA=0 einstellen lässt. Der SPI Master müsste 
für meine Aufgabe also bei fallender Flanke die Daten auf den MOSI 
senden und ebenfalls bei fallender Flanke die Daten vom MISO einlesen. 
Ich habe bisher nicht gesehen, dass man das an einem Hardware-SPI so 
einstellen könnte...

Sehe ich da etwas falsch?

Mich verwundert, dass es so viele Schaltungen gibt, die trotzdem die 
beiden Schieberegister an einem gemeinsamen SPI betreiben. Man kann 
natürlich immer per Software-SPI arbeiten, dann kann man sich ja selbst 
aussuchen, in welcher Clock Phase man die Daten liest und schreibt - 
aber beispielsweise im MIDIBox Projekt wird der Hardware SPI eines 
STM32F4 mit CPHA=1 in der selben Konfiguration (595 + 165) verwendet und 
dort scheint es zu funktionieren.

LG,
StrangeMan
#4092935
Lesenswert?

Man kann den 74HC165 ruhig auf der falschen Flanke einlesen.
Die Hold-Zeit beträgt z.B. beim ATmega48 10ns, die Durchlaufzeit des 
74HC165 ist aber mit 15ns deutlich höher.
Hinzu kommen noch die Verzögerungen durch die Schaltungskapazitäten.
Das Signal muß ja von SCK zum 74HC165 hinlaufen und dann wieder zu MISO 
zurück, d.h. die Laufzeiten addieren sich.

Bei einem Output-Slave laufen aber SCK und MOSI in die gleiche Richtung, 
d.h. die Laufzeiten kompensieren sich, da ist die falsche Flanke nicht 
erlaubt.
OP #4093195
Lesenswert?

@peter:
Hmm, ich nutze hier einen STM32F429 und möchte hohe clock speeds fahren. 
Ich beobachte momentan immer wieder, dass der controller Dinge einliest, 
die so gar nicht gesendet wurden. Das zeigt jedenfalls der Vergleich mit 
dem Oszi. Daher komme ich überhaupt erst darauf, mir diese 
Stardardschaltung noch mal im Detail anzuschauen.

@Frank:
Danke für den Tip. Laut Datenblatt schiebt der 597 seine Daten aber auch 
auf der positiven Flanke raus. Insofern für mich das selbe Problem.


Mein Ansatz ist jetzt, zuerst eine Übertragung für die 595er zu machen, 
und dann eine zweite für die 165er - mit umkonfiguriertem SPI. Dank 
separater LOAD-Leitungen kann ich das ja trennen. Auch wenn das alles 
andere als elegant ist. Immerhin habe ich einen DMA, sodass die CPU Last 
nicht so hoch ist.

Ich hatte ja insgeheim gehofft, es gibt zum 165 eine pinkompatible 
Alternative mit invertierter Clockpolarität. Leider kann ich sowas nicht 
finden.
Gast #4093235
Lesenswert?

Als eine etwas andere Variante zum hc595 gibt es noch den HC4094. Da hat 
man einen zusätzlichen verzögerten Datenausgang bei der fallenden 
Flanke. Das hat ggf. Vorteile beim Kaskadieren.

Zur Not könnte man den Takt für die HC165 invertieren.
Gast #4094005
Lesenswert?

Hi Johannes,

jo, stimmt so, was du schreibst.
595: CPOL = 0, CPHA = 0
165: CPOL = 1, CPHA = 1

Den uCapps-Sequenzer hatte ich mal als Testaufbau zusammengebaut. Die 
Kabel waren etwas lang und wg. der Leitungs-Reflexionen hat das Triggern 
auf die Flanke nicht mehr funtioniert. Ergebnis war, dass die Buttons 
ständig "button_pressed" von sich gegeben haben. Mit etwas Terminierung 
war es dann halbwegs in den Griff zu bekommen.

Ich nutzen den LPC4337 von NXP mit SPI und DMA. Taster und LEDs sind als 
separate SPI-Devices mit oben gezeigter Konfiguration angeschlossen.

Umschalten von CPOL und CPHA wirkt auf dem LPC erst mit dem nächsten 
Senden von Daten. Man muss also immer ein Leer-Byte schicken bevor man 
eine Switch-Mode aufruft.

Ich würds so einschätzen: Für einfache Test-/Hobbyzwecke kann man das 
mit dem gleichen SPI-Mode machen, wenns gut/professionell/sicher sein 
soll/muss würde ich immer den Mode schalten.

Viel Erfolg,
Bränko

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren