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
Ein MCP29017 SPI Portexpander kostet selbst bei Conrad unter 2€ und bietet gleich 16 Bit an. Da macht man doch nix mehr mit 74er oder 40er Bausteinen.
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
Holm T. schrieb: > ..weil eine SPI sonst anders funktioniert, halt mit einem ChipSelect. Wenn es danach geht, dürftest du niemals 2 SPI Chips kaskadieren. Willst du Analog Devices absprechen, dass die ein vernünftiges SPI bei ihren Chips hinbekommen? Beispiel AD5422 (Fig. 68 auf S.28) http://www.analog.com/media/en/technical-documentation/data-sheets/AD5412_5422.pdf
@ 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.
:
Bearbeitet durch User
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.
Karl H. schrieb: > Denk dir einfach der RCLCK würde CS heissen Klar, stimmt auch. Manchmal hat man große rote Gemüseteile auf den Augen. ;-)
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-Takte AVR 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.
:
Bearbeitet durch User
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".
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.