Ich suche eine Schieberegister zum Anschluß an eine SPI für eine
Ausgangserweiterung...ja nichts leichter als das.. :-)
An der SPI hängt aber nicht nur das SR sondern auch noch eine RTC und
ein EEPROM, ich brauche also ein SR, das sich mit einem "SlaveSelect"
enablen läßt, d.h. der Clock Eingang wird gesperrt wenn die SPI nicht
mit dem SR, sondern z.B: mit der RTC reden will.
Ein 74HC299 kann Sowas, gibts noch Andere?
Klar, man kann auch immer einschieben und statt dem SS Signal mit einem
LatchEnable dann auf die Ausgänge freischalten wenn wirklich was
interessantes geschickt wurde, das ist aber IMHO nicht so das Gelbe vom
Ei und entspricht nicht der SPI Philosophie..
Ein 74HC595 kann das so nicht, der würde aber die Sache mit dem Latch
ermöglichen.. beim 4014 oder 4094 geht das auch nicht..
Was nehmt Ihr da? ..soll an einem AtXmega werkeln..
Gruß,
Holm
2€ für 16bit ist ziemlich überteuert. Im Ernst: Was spricht gegen die
Variante mit dem 74hc595? Der Latch Enable Pin ist u.a. genau dafür da.
Warum sollte es einen CS-Pin geben wenn das Latch (fast) genau die
gleiche Funktion erfüllt.
>2€ für 16bit ist ziemlich überteuert.
1.25€ bei Reichelt. Im bastelfreundlichen DIP Gehäuse.
Das man jeden Pin als Eingang oder Ausgang benutzen
kann ist sicher auch interessant.
Holm T. schrieb:> Klar, man kann auch immer einschieben und statt dem SS Signal mit einem> LatchEnable dann auf die Ausgänge freischalten wenn wirklich was> interessantes geschickt wurde, das ist aber IMHO nicht so das Gelbe vom> Ei
Und warum nicht?
Es funktioniert doch einwandfrei.
Peter D. schrieb:> Holm T. schrieb:>> Klar, man kann auch immer einschieben und statt dem SS Signal mit einem>> LatchEnable dann auf die Ausgänge freischalten wenn wirklich was>> interessantes geschickt wurde, das ist aber IMHO nicht so das Gelbe vom>> Ei>> Und warum nicht?> Es funktioniert doch einwandfrei.
..weil eine SPI sonst anders funktioniert, halt mit einem ChipSelect.
Ich habe dann 2 ICs bei denen ich SlaveSelect aktivieren muß wie
vorgesehen, und einen mit einem komischen Latch enable.. das ist doch
von der Verfahrensweise her nicht sauber und ich muß für den einen
Ausnahmefall programmieren, gehen tut es freilich, aber ich wundere
mich, das es das nicht so ohne Weiteres aus der Dose gibt, SPI ist ja
verbreitet.
Den 74HC299 hat kaum einer (gibts bei Mouser), mit dessen Mode Eingängen
läßt sich die richtige Funktionalität erreichen, aber das Ding kann fast
zu viel und hat einen Haufen Pins die ich dann nicht brauche..
Ein zusätzliches Und Gatter scheidet aus, weil ich dann ein zusätzliches
BE auf der Platine brauche (das ist ne kommerzielle Platine).. genauso
wie ein Einkauf bei Reichelt (ich brauche nicht wieder was das
explodiert, die liefern Zeug von dem sie glauben das es auch geht..) und
Bastelfreundlich muß es auch nicht sein (eher klein).
Für 2 Euro kann ich auch gleich noch einen Prozessor als Slave da
draufbasteln..
Gruß,
Holm
Holm T. schrieb:> Ich habe dann 2 ICs bei denen ich SlaveSelect aktivieren muß wie> vorgesehen, und einen mit einem komischen Latch enable
Nö, da ist nichts komisch.
595:
RCLK = 0
8 Bit schieben
RCLK = 1
fertich
Holm T. schrieb:> Ich habe dann 2 ICs bei denen ich SlaveSelect aktivieren muß wie> vorgesehen, und einen mit einem komischen Latch enable..
Kannst Du mir den Unterschied erklären? Ich bin Laie ...
Dieter F. schrieb:> Holm T. schrieb:>> Ich habe dann 2 ICs bei denen ich SlaveSelect aktivieren muß wie>> vorgesehen, und einen mit einem komischen Latch enable..>> Kannst Du mir den Unterschied erklären? Ich bin Laie ...
Was hat das mit Laie zu tun?
Es gibt keinen, bis auf Zeit und Pegel-Unterschiede (atkiv/passiv).
@peda: ich werde mal mit den 595 spielen, habe jetzt immerhin ein DB in
dem RCLK überhaupt vorkommt :-)
Gruß,
Holm
@ Peter Dannegger (peda)
>> Ich habe dann 2 ICs bei denen ich SlaveSelect aktivieren muß wie>> vorgesehen, und einen mit einem komischen Latch enable>Nö, da ist nichts komisch.>595:>RCLK = 0>8 Bit schieben>RCLK = 1>fertich
EBEN!
Was mal wieder nur zu DEUTLICH zeigt, welche Luxusprobleme selbst
Bastler in diesem Land haben 8-(
Es lebe das Overengineering!
Holm T. schrieb:> Was hat das mit Laie zu tun?
Sollte nur meine Unwissenheit untermauern - ich bin nicht vom Fach. Mir
war nicht bekannt, ob wirklich noch irgendein anderer, signifikanter
Unterschied besteht. Ob ich einen "slave" mit low oder high aktiviere
ist für mich nicht entscheident.
Falk B. schrieb:> @ Peter Dannegger (peda)>>>> Ich habe dann 2 ICs bei denen ich SlaveSelect aktivieren muß wie>>> vorgesehen, und einen mit einem komischen Latch enable>>>Nö, da ist nichts komisch.>>595:>>RCLK = 0>>8 Bit schieben>>RCLK = 1>>fertich>> EBEN!>> Was mal wieder nur zu DEUTLICH zeigt, welche Luxusprobleme selbst> Bastler in diesem Land haben 8-(>> Es lebe das Overengineering!
Du wirst mir bitte nicht das Recht nehmen wollen zu machen was mir
gefällt..oder?
Mit Bastelei hat das Ganze freilich nichts zu tun, das hatte ich
angemerkt, stößt das Dir eventuell dann auch mal auf?
Gruß,
Holm
Holm T. schrieb:> Ein zusätzliches Und Gatter scheidet aus, weil ich dann ein zusätzliches> BE auf der Platine brauche
Naja, eins in der Größe eines SC70, plus ein KerKo von vielleicht 0603
oder kleiner (je nachdem, was du dir antun willst).
Ansonsten sehe ich das aber auch als akademisches Problem an.
In meiner Nixie-Uhr mit deinen Nixies ;) werkelt auch eine '595-Kette,
für die die einzelnen Stellen als BCD durchgeschoben werden. Man muss
halt jedesmal die Kette komplett bedienen, aber ansonsten erfüllt /LE
den Zweck völlig.
Ich sehe das Problem durchaus. Das Problem ist nicht, dass es unmöglich
ist, den 595 mit SPI zu verwenden, sondern eher, dass man keine
gemeinsame Protokollimplementierung für "normale" SPI-Geräte und den 595
bauen kann.
Ich mag SPI nicht, aber ich kenne das so: Jedes device hat ein ~CS. Ist
~CS low, reagiert das jeweilige device auf Daten auf dem SPI. Ist ~CS
high, dann nicht. Man würde das Protokoll also so implementieren:
~CS->low, Daten senden, ~CS->high. Verwendet man das nun für den 595 und
schließt ~CS an das output latch, funktioniert es nicht wie gewünscht.
Man braucht also extra für den 595 eine eigene Protokollimplementierung.
Dass das nervig ist, kann ich gut verstehen.
Nun ist es eben allerdings so: Es gibt Lösungen, einige wurden hier
schon vorgeschlagen. Wenn die alle zu teuer und zu aufwendig sind, dann
muss eben die Software angepasst werden. Mir persönlich ist in diesem
Zusammenhang übrigens auch unklar, warum für die Anwendungen SPI
verwendet wird und nicht das deutlich unproblematischere I2C.
someone schrieb:> Verwendet man das nun für den 595 und> schließt ~CS an das output latch, funktioniert es nicht wie gewünscht.
Richtig.
> Man braucht also extra für den 595 eine eigene Protokollimplementierung.
Ja, die braucht man aber sowieso, denn das /LE muss man ja in
jedem Falle bedienen: die Ausgänge sollen ja (normalerweise) nicht
das Durchschieben der Bits durchs SR „sehen“.
Wenn man das SPI-kompatibel haben will, müsste man einfach mit der
steigenden Flanke des /CS-Signals einen /LE-Impuls generieren:
1
+----+
2
|| | 1 |
3
/CS o------||----*-----| o------o /LE
4
|| | | |
5
--- +----+
6
| |
7
| |
8
---
9
|
10
¯¯¯¯¯
> Wenn die alle zu teuer und zu aufwendig sind, dann> muss eben die Software angepasst werden.
Was in diesem Falle vermutlich die preiswerteste Lösung ist.
> Mir persönlich ist in diesem> Zusammenhang übrigens auch unklar, warum für die Anwendungen SPI> verwendet wird und nicht das deutlich unproblematischere I2C.
I²C ist nicht unbedingt unproblematischer. Das fängt damit an, dass
man externe (in der Regel) Pullups braucht, dass es langsamer ist
etc. pp. I²C ist gut, wenn man Slaves hat, die selbst nicht so
schnell sind (also insbesondere Controller, in denen erst eine
Software auf die Anforderung reagieren muss). SPI dagegen ist
inhärent ein Schieberegister, sodass sich Hardware-Slaves dafür gut
eignen. Dafür ist das dann einiges schneller.
Der 595 übernimmt die Daten ins Ausgangslatch, wenn er eine steigende
Flanke am RCLCK sieht.
Denk dir einfach der RCLCK würde CS heissen und die Beschreibung zum IC
würde darauf hin lauten, dass er erst nach deaktivieren des CS die Daten
an die Ausgänge legt. Was ja auch sinnvoll ist, damit man mehrere
Bausteine kaskadieren kann, die dann auch noch möglichst gleichzeitig
die Ausgänge durchschalten.
Inwiefern ist das jetzt komplett anders als bei anderen SPI IC's?
OK. eines sollte man vermeiden: den Chip zu selektieren und dann keine
Daten reinschreiben. Das ist allerdings jetzt nicht wirklich der grosse
Showstopper.
Alles nur eine Frage der Sichtweise.
someone schrieb:> Man würde das Protokoll also so implementieren:> ~CS->low, Daten senden, ~CS->high. Verwendet man das nun für den 595 und> schließt ~CS an das output latch, funktioniert es nicht wie gewünscht.
Das ist Quatsch, natürlich funktioniert das genau so.
Dem 595 ist vollkommen wurscht, ob Du das RCLK für Dich /CS nennst.
Der RCLK übernimmt mit der 0->1 Flanke und genau das willst Du doch.
In gestörter Umgebung oder bei Spikes gibt es einen Unterschied zu
"echtem SPI".
Echte SPI ignorieren ein Signal an /CS, solange kein Takt dazwischen
liegt. Manche SPI-DAC zählen sogar mit und ignorieren bis zu 15
SCK-Takte, wenn 16 benötigt werden.
Der 595 übernimmt bei Spikes auf /CS=RCLK aber den zufälligen Inhalt des
Schieberegisters. Es gibt dazu 2 Abhilfen:
1.
Eine OR-Verknüpfung des SCK mit /CS. Solange SCK=1 ist, ändern Störungen
auf /CS nicht den Inhalt des SRG.
2.
Störfestes Layout und Abblockkondensatoren, sowie keine Spikes in der
Software.
someone schrieb:> Ich mag SPI nicht,
Ich finde SPI gut, auf jeden Fall viel besser als die Alternative I2C.
>aber ich kenne das so: Jedes device hat ein ~CS.
Es gibt auch Devices die ein High-Aktives CS haben, RTCs zum Beispiel.
Zusätzlich passiert es auch gerne mal, dass verschiedene SPI Slaves den
SPI unterschiedlich brauchen, sei es was den maximalen Takt angeht oder
einen anderen Modus.
Ich habe hier eine Schaltung die ein DOG-M Display, ein 74HC595 und zwei
Winkel-Sensoren mit SSI an einen SPI anbindet - läuft. :-)
Peter D. schrieb:> Manche SPI-DAC zählen sogar mit und ignorieren bis zu 15> SCK-TakteAVR mit der SPI im Slave Modus machen das auch so.
Gestern hatte ich den Fall, dass die Clock Polarität nicht gestimmt hat
und ich mich gefragt habe, warum die SPI keinen Interrupt auslöst,
obwohl ich doch am Oskar deutlich 8 Takt-Pulse gesehen habe. Der SS
wurde (für die eingestellte Clock-Polarität) zu früh zurückgenommen, so
dass die 8.te Flanke nicht mehr galt.
D.h. eigentlich hat mich erst der Oskar auf die Spur mit der Polarität
gebracht.
someone schrieb:> Ich sehe das Problem durchaus. Das Problem ist nicht, dass es unmöglich> ist, den 595 mit SPI zu verwenden, sondern eher, dass man keine> gemeinsame Protokollimplementierung für "normale" SPI-Geräte und den 595> bauen kann.> Ich mag SPI nicht, aber ich kenne das so: Jedes device hat ein ~CS. Ist> ~CS low, reagiert das jeweilige device auf Daten auf dem SPI. Ist ~CS> high, dann nicht. Man würde das Protokoll also so implementieren:> ~CS->low, Daten senden, ~CS->high. Verwendet man das nun für den 595 und> schließt ~CS an das output latch, funktioniert es nicht wie gewünscht.> Man braucht also extra für den 595 eine eigene Protokollimplementierung.> Dass das nervig ist, kann ich gut verstehen.
[..]
Das war exakt mein Problem.
Gruß,
Holm
Holm T. schrieb:>> ~CS->low, Daten senden, ~CS->high. Verwendet man das nun für den 595 und>> schließt ~CS an das output latch, funktioniert es nicht wie gewünscht.>> Man braucht also extra für den 595 eine eigene Protokollimplementierung.>> Dass das nervig ist, kann ich gut verstehen.> [..]>> Das war exakt mein Problem.
Ich verstehe es noch immer nicht. Kann es sein, dass du den ~CS an den
falschen Pin angeschlossen hast? Falsch wäre z.B. ~OE.
Richtig wäre RCLK (so nennt ihn TI) oder STCP (NXP) oder Latch Clock
(ON). Wenn du den mit ~CS verbindest, sollte die oben beschriebene
Signalfolge ohne irgendwelche Änderungen funktionieren.
Anders gefragt: was genau ist die Beobachtung, auf der folgene Aussage
beruht "... funktioniert es nicht wie gewünscht"? Wie sehen deiner
Meinung nach die notwendigen Änderungen am Protokoll aus, um den 595 zu
betreiben?
Achim S. schrieb:> Holm T. schrieb:>>> ~CS->low, Daten senden, ~CS->high. Verwendet man das nun für den 595 und>>> schließt ~CS an das output latch, funktioniert es nicht wie gewünscht.>>> Man braucht also extra für den 595 eine eigene Protokollimplementierung.>>> Dass das nervig ist, kann ich gut verstehen.>> [..]>>>> Das war exakt mein Problem.>> Ich verstehe es noch immer nicht. Kann es sein, dass du den ~CS an den> falschen Pin angeschlossen hast? Falsch wäre z.B. ~OE.>> Richtig wäre RCLK (so nennt ihn TI) oder STCP (NXP) oder Latch Clock> (ON). Wenn du den mit ~CS verbindest, sollte die oben beschriebene> Signalfolge ohne irgendwelche Änderungen funktionieren.>> Anders gefragt: was genau ist die Beobachtung, auf der folgene Aussage> beruht "... funktioniert es nicht wie gewünscht"? Wie sehen deiner> Meinung nach die notwendigen Änderungen am Protokoll aus, um den 595 zu> betreiben?
Das schrieb "someone" nicht ich.
Ich habe in diesem konkreten Fall überhaupt noch nichts ausprobiert,
mein Ziel war einfach zu fragen was andere Leute für SR benutzen.
Ich habe an anderen Prozessoren mit SPI schon andere SR benutzt, aber
den 74x595 noch nicht.
Nun gibt es hier ein existierendes Projekt das geändert werden soll, ich
wollte nicht das Fahrad neu erfinden und die früher geschriebenen
Prozeduren für die SPI möglichst mit verwenden und dabei erschien mir
der 74HC595 nicht so sonderlich kompatibel sondern "sah nach
Sonderbehandlung" aus.
So weit so gut, das Ergebnis der Nachfrage hier geht mir aber eher auf
die Nerven, ich hätte einfach nicht fragen sollen.
Manche sind eben einfach was Besseres als Andere.
Gruß,
Holm
Holm T. schrieb:> ich hätte einfach nicht fragen sollen.
Ich denke fragen geht schon in Ordnung ;-) Ein bisschen verwirrend war
die Aussage, dass der 595 nicht in dem beschriebenen SPI-Modus
funktionieren soll. (kam in someones Beitrag und in deinem ersten
Beitrag als Aussage rüber, erst im letzten Beitrag wird deutlich, dass
es von deiner Seit nur eine Vermutung war).
Also nochmal wiederholt die Antwort auf den eigentlichen Kern deiner
Frage: solange du mit ~CS einen vollen 8-Bit Zugriff einschließt, merkst
du keinen Unterschied zwischen RCLK und dem "normalen Chipselect bei
SPI".
