Hallo, spricht was dagegen den einzigen SPI Slave dauerzuaktivieren? Also low_activ_slave_select direkt auf die Masse zu legen? Gruß
Al3ko -. schrieb: > Nein, spricht nichts dagegen. Wenn's nicht funktionieren braucht dann stimmt das. Sonst kann sehr wohl was dagegen sprechen. Denn manche, wenn nicht sogar viele Slaves, brauchen die CS Flanken damit sie wissen wann es losgeht und wann es aufhört.
> spricht was dagegen den einzigen SPI Slave dauerzuaktivieren?
Das machen nicht alle Tschipps mit, einfach im Datenplatt nachlesen.
HTH
Al3ko -. schrieb: > Nein, spricht nichts dagegen. > > Gruß, Doch natürlich kann es etwas dagegen sprechen. Viele SPI Slaves nutzen CS für die Synchronisation. Erwarten also z.B. vor einem neuen Kommando erstmal eine CS Flanke. CS dauerhaft aktiv geht hier nicht. Kommt also stark auf den Slave an.
jo mei schrieb: > Denn manche, wenn nicht > sogar viele Slaves, brauchen die CS Flanken damit sie wissen wann > es losgeht und wann es aufhört. Oh, danke für die Aufklärung. Dann nehme ich meine vorige Aussage natürlich zurück. Gruß,
Al3ko -. schrieb: > Oh, danke für die Aufklärung. Seit 11 Jahren hier angemeldet (mit mehr als 1000 Beiträgen) und keine Ahnung wozu ein Chip Select gut sein soll?
jo mei schrieb: > Seit 11 Jahren hier angemeldet (mit mehr als 1000 Beiträgen) > und keine Ahnung wozu ein Chip Select gut sein soll? ;)
Verstehe. Die Synchronisation wäre ein Punkt. Dann müsste der Slave aber auch angeben, wie weit auseinander die SS Flanke und erste Datenflanke sein dürfen und der Master darf das einhalten :) Beim Master ist CS ein normaler IO Pin und nicht Teil der SPI Peripherie wie CLK,MOSI,MISO. Die Zeitpunkte wann die Software CS setzt und ein Byte zum Transfer reinschiebt, sind mehr oder weniger losgekoppelt. Auf der anderen Seite kann ein Master nicht n-Pins für CS vorhalten. Gruß
Elektroniker schrieb: > Dann müsste der Slave aber auch angeben, wie weit auseinander > die SS Flanke und erste Datenflanke sein dürfen und der Master > darf das einhalten :) Nö muss er nicht. Und ist auch nicht üblich. > Beim Master ist CS ein normaler IO Pin und nicht Teil der SPI Peripherie > wie CLK,MOSI,MISO. Die Zeitpunkte wann die Software CS setzt und ein > Byte zum Transfer reinschiebt, sind mehr oder weniger losgekoppelt. Die Zeit spielt auch keine Rolle sofern das setzen von CS jedesmal vor der Übertragung stattfindet und danach CS wieder gelöscht wird.
Elektroniker schrieb: > Beim Master ist CS ein normaler IO Pin und nicht Teil der SPI Peripherie > wie CLK,MOSI,MISO. Die Zeitpunkte wann die Software CS setzt und ein > Byte zum Transfer reinschiebt, sind mehr oder weniger losgekoppelt. Nein, diw Software muss die Signale so erzeugen, dass es dem erforderlichen Timing für den/die Slaves entspricht. CS und Transfer in nicht synchronisierte Tasks zu packen, wird kräftig in die Hose gehen.
Ja, Wolfgang ich stimme Dir zu. Ich hatte vor mich hin laut überlegt. Die FW auf dem Master muss die Timings einhalten.
Elektroniker schrieb: > spricht was dagegen den einzigen SPI Slave dauerzuaktivieren? Kommt auf den Slave drauf an. Aber es ist bei SPI prinzipiell vorgesehen (und sinnvoll ist es allemal) den SS# zur Frame-Synchronisation zu verwenden. Denn wenn der Slave dauernd aktiv ist, und auch nur 1 einziger Spike auf der Clockleitung auftritt (Stichwort EMV z.B. durch brachiale Blitze, brutzelnde Lichtschalter und Keineanhungwasweißichalles), dann läuft der Slave ab diesem Zeitpunkt evtl. um 1 Takt "versetzt" und macht völligen Mist. Elektroniker schrieb: > Dann müsste der Slave aber auch angeben, wie weit auseinander > die SS Flanke und erste Datenflanke sein dürfen und der Master darf das > einhalten :) Ja, das steht im Datenblatt. Und der Master "darf" das nicht einhalten, sondern er "muss" es einhalten, denn sonst "könnte" es funkionieren oder auch nicht.
:
Bearbeitet durch Moderator
Es gibt SPI-Slaves, die synchronisieren auf das erste 1-Bit, z.B. MM5450. Da reichen dann 2 Leitungen (SCK, MOSI), um ihn anzusteuern. https://www.microchip.com/wwwproducts/en/MM5450
Elektroniker schrieb: > Auf der anderen Seite kann ein Master nicht n-Pins für CS vorhalten. warum nicht? Wenn es nur ein Dutzend Slaves sind, reichen oft IO-Pins. Wenn es deutlich mehr sind, geht auch jede beliebige 1 aus n Dekodierung, ein Schieberegister oder ein Latch am Daten/Adressbus. Bei I2C ist meist eher Schluss. Bei modernen komplexen Prozessoren gehören die CS mit zur Peripherie, so dass per DMA und Auftragspuffer ganze Speicherbereiche mit verschieden SPI-Devices ausgetauscht werden können. Bis hin zu Flash-Bausteinen, die wie internes Flash direkt ausführbaren Programmcode enthalten können.
Peter D. schrieb: > Es gibt SPI-Slaves, die synchronisieren auf das erste 1-Bit, z.B. > MM5450. > Da reichen dann 2 Leitungen (SCK, MOSI), um ihn anzusteuern. Wobei das dann aber Exoten sind, da z.B. das erste Bit "verloren" ist und eine feste Anzahl an Bits notwendig ist. Das ist nichts, was man sich für z.B. einen Speicher wünscht.
Beitrag #6354164 wurde von einem Moderator gelöscht.
Elektroniker schrieb: > spricht was dagegen den einzigen SPI Slave dauerzuaktivieren? Kommt auf den Chip an. Alle die ich kenne (sind nicht sehr viele) kommen ohne CS aus. Die meisten synchronisieren auf den Takt per Timeout, andere über nen Bitwechsel auf MOSI wenn der Takt läuft. Es gibt auch welche da kannst du das aus den MISO Daten erkennen. Mit CS kann man z.B. auch keine SPI Kette aufbauen, d.h wenn der Takt durch mehrere Chips läuft, oder du brauchst nen extra Optokoppler bei galvanischer Trennung. Also Datenblatt lesen.
Die SPI-Schnittstelle baut doch urspruenglich auf einem Schieberegister auf. Die Daten werden reingetaktet und der Wert bei fallender Flanke von CS aus dem Schieberegister gelesen/gelatcht/gesampelt.
Elektroniker schrieb: > spricht was dagegen den einzigen SPI Slave dauerzuaktivieren? > Also low_activ_slave_select direkt auf die Masse zu legen? Ja. Das "slave select" hat neben der offensichtlichen Funktion bezüglich der Busarbitrierung noch eine weitere: Den Datenaustausch auf Protokollebene zu synchronisieren. Es gibt gewisse Ausnahmen, die theoretisch ohne diese Synchronisation auskommen könnten, aber in der Praxis sorgt der erste Störglitch auf Taktleitung (woher auch immer eingestreut) für das ultimative Ende der Show (bis zum nächsten Power-Cycle). Sprich: wer das versucht, muss sich seines Layouts, der Versorgung und der EM-Umgebung SEHR sicher sein, sonst fällt er jämmerlich auf die Schnauze...
c-hater schrieb: > Sprich: wer das versucht, muss sich seines Layouts, der Versorgung und > der EM-Umgebung SEHR sicher sein, sonst fällt er jämmerlich auf die > Schnauze... Einspruch, s. mein Posting weiter oven
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.