Hi, ich bin grad am studieren der SPI Beschreibung im Reference Manual für den STM32. So weit so gut, abgesehen, dass sie full duplex und bidirectional wechselseitig verwenden. Was sich mir allerdings überhaupt nicht erschließt, ist dieser NSS Pin, bzw. wieso man wenn man diesen nicht verwendet, ein NSS Bit setzen muss oder hab ich das falsch verstanden. Beim SPI auf den AVRs gibts das ja gar nicht. Liebe Grüße Tom
NSS (STM32) = SS (AVR) Das N symbolisiert active low. Achtung: Der komplizierten Beschreibung zum Trotz ist dieser Pin bei normalem Master-Betrieb leider keine SS-Automatik, sondern genauso manuell wie bei AVRs.
Obacht: bidirektional = half duplex (simplex). Es gibt eine auch SPI-ähnliche Kommunikation, die mit einer einzigen bidirektionalen Datenleitung arbeitet.
@PRX: Ich hab beim AVR gar keinen SS verwendet, wenn ich mich da richtig erinnere. Ich brauch doch nur CLK, MOSI, MISO und CS um einen Slave anzusprechen. wozu dann noch SS? Full duplex != bidirektional Ja genau, daher ist mir bis jetzt noch nicht ganz klar was ST da genau meint. Full duplex ist doch auf jeden fall immer bidirektional, andersherum nicht zwingend. Tom
Thomas Burkhart schrieb: > @PRX: Ich hab beim AVR gar keinen SS verwendet, wenn ich mich da richtig > erinnere. Ich brauch doch nur CLK, MOSI, MISO und CS um einen Slave > anzusprechen. wozu dann noch SS? SS = CS. Aber auch beim AVR heisst dieser Pin SS, nur die dran hängenden Devices sagen oft CS dazu. Und CLK heisst normalerweise SCK. Man kann auch über die eigenen Füsse stoplern. > Full duplex ist doch auf jeden fall immer bidirektional, andersherum > nicht zwingend. Full duplex geht schlecht mit einer einzigen Datenleitung. "Bidirektional" meint hier, dass die gleiche Leitung mal in die eine mal in die andere Richtung überträgt. Also half duplex, was ST simplex nennt.
Ah, danke, jetzt weiß ich auch endlich was Simplex sein soll. Ähm, wieso definieren die für das SS dann einen speziellen PIN? Ich hab bisher einfach irgendeinen IO-Pin genommen. Tom
Thomas Burkhart schrieb: > Ähm, wieso definieren die für das SS dann einen speziellen PIN? Ich hab > bisher einfach irgendeinen IO-Pin genommen. Weil man genau wie beim AVR das SPI auch als Slave betreiben kann.
Achso, und in dem Fall ist das SS-Pin der CS des AVRs/STM32, verstehe. Als Slave funktioniert der dann automatisch. Als Master ist er eigentlich nicht notwendig, richtig? Tom
Thomas Burkhart schrieb: > Achso, und in dem Fall ist das SS-Pin der CS des AVRs/STM32, verstehe. > Als Slave funktioniert der dann automatisch. Als Master ist er > eigentlich nicht notwendig, richtig? Richtig. Genau wie beim AVR tut es jeder andere Pin auch.
Dank Dir, das hat mir einige Verwirrung beseitigt. Werde dass auch in den STM32 Artikel einfließen lassen. Tom
HI, naja so HALB ist das alles wahr. Der NSS Pin kann auch von der Hardware automatisch gesetzt werden, mit der geeigneten Einstellung. Allerdings hat der Modus in meinem STM32 noch nen Bug(älteres Modell). --> SPI_InitStructure.SPI_NSS = SPI_NSS_Hard; -->SPI_InitStructure.SPI_NSS = SPI_NSS_Soft; Gruß
Jean Player schrieb: > Der NSS Pin kann auch von der Hardware automatisch gesetzt werden, mit > der geeigneten Einstellung. Allerdings hat der Modus in meinem STM32 > noch nen Bug(älteres Modell). Wie ST sich das wirklich gedachte hatte kann ich der Doku dazu nicht sauber entnehmen. Es wird zwar ein Hardware-Modus erwähnt, in dem der Pin als Ausgang definiert wird, dummerweise widersprechen sich dabei aber die Teile der Doku gegenseitig. Von einer automatischen Aktivierung/Deaktivierung steht allerdings nirgends etwas. Die einzig dokumentierte Automatik ist der Fallback in den Slave-Modus, abhängig vom NSS-Pin, was mit Multi-Master-Betrieb zu tun hat. Klar scheint aber auf Basis entsprechender Diskussionen im STM32-Forum, dass man im Master-Modus die SS/CS-Funktion vom SPI manuell steuern muss. Ob man dafür den NSS-Pin oder einen anderen verwendet, ist egal. Wer es anders versuchte fiel auf die Nase. Und darauf bezog ich mich hier im Thread. Ob das mit Bugs zu tun hat, mit Dokumentations-, Implementierungs oder Denkfehler weiss ich nicht. Jedenfalls ist die letzte öffentliche Doku (STM32F100 Reference) dazu nicht signifikant anders als die ältere und die Errata-Sheets erwähnen keinen Bug dazu. Wenn du die ganze Wahrheit dazu kennst, immer raus damit. Grad im DMA-Betrieb wäre eine automatische Deaktivierung nach erfolgtem Transfer recht hilfreich.
A. K. schrieb: > Wie ST sich das wirklich gedachte hatte kann ich der Doku dazu nicht > sauber entnehmen. Es wird zwar ein Hardware-Modus erwähnt, in dem der > Pin als Ausgang definiert wird, dummerweise widersprechen sich dabei > aber die Teile der Doku gegenseitig. Von einer automatischen > Aktivierung/Deaktivierung steht allerdings nirgends etwas. Die einzig > dokumentierte Automatik ist der Fallback in den Slave-Modus, abhängig > vom NSS-Pin, was mit Multi-Master-Betrieb zu tun hat. Richtig. > Klar scheint aber auf Basis entsprechender Diskussionen im STM32-Forum, > dass man im Master-Modus die SS/CS-Funktion vom SPI manuell steuern > muss. Ob man dafür den NSS-Pin oder einen anderen verwendet, ist egal. > Wer es anders versuchte fiel auf die Nase. Und darauf bezog ich mich > hier im Thread. Nicht ganz, der Select funzt. Allerdings bleibt der Pin danach für immer Low und muss per Hand zurück gesetzt werden. Das Beispiel Programm in der Firmware Lib (Spi->DMA) funktioniert zum Beispiel, aber wie gesagt, der Deselect leider nicht. > Ob das mit Bugs zu tun hat, mit Dokumentations-, Implementierungs oder > Denkfehler weiss ich nicht. Jedenfalls ist die letzte öffentliche Doku > (STM32F100 Reference) dazu nicht signifikant anders als die ältere und > die Errata-Sheets erwähnen keinen Bug dazu. Ja, mit dem Bug hat ja auch leider niemand von den Herren im ST Forum zu gegeben. Es sollte nur in späteren Revisions erfolgen, das der NSS ordentlich funktioniert. Ist jetzt mittlerweile glaube ich 1 1/2 Jahre her und es scheint sich noch nix ergeben zu haben. Oder ? > Wenn du die ganze Wahrheit dazu kennst, immer raus damit. Grad im > DMA-Betrieb wäre eine automatische Deaktivierung nach erfolgtem Transfer > recht hilfreich. Tja leider weiss ich auch nur das oben beschriebene. Das Deselect muss per Hand geschehen ;-( Ich wollte auch nur hinweisen, das es auch so funktioniert, damit keine Halbwahrheiten im WIKI stehen. Gruß
Jean Player schrieb: > Nicht ganz, der Select funzt. Allerdings bleibt der Pin danach für > immer Low und muss per Hand zurück gesetzt werden. Dass da was automatisch aktiviert wird war mir entgangen, danke, aber im üblichen ausschliesslichen Master-Mode bringt das ziemlich wenig, denn das vordere Ende vom Transfer hat man sowieso unter Kontrolle, nur am hinteren Ende hätte das wirkliche Vorteile. > ordentlich funktioniert. Ist jetzt mittlerweile glaube ich 1 1/2 Jahre > her und es scheint sich noch nix ergeben zu haben. Oder ? Wie gesagt, der F100 ist taufrisch, seine separate Referenz ebenfalls, und die ist an dieser Stelle fast identisch. Da die Doku zudem nirgends eine automatische Deaktivierung erwähnt nehme ich an, dass ST das schlicht unter "works as designed" abbucht, nicht unter "bug".
Folgendes Szenario : Zwei Stm32F101 sollen über SPI kommunizieren. Einer als Master ,der andere entsprechend Slave. Bei dem Slave "Board" habe ich NSS entsprechend verbunden. Ist es nun problematisch das NSS des Slave mit dem NSS des Master STM ohne Widerstand zu verbinden ? Bzw. macht es sinn ? Oder sollte ich besser das NSS des Slave mit einem anderen I/O des Master STM verbinden ? Brauche ich einen Pull-Up am NSS oder geschieht dies (wenn implementiert ) intern ? Vielen Dank !
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.