Hallo Leute Mein Kollege und ich wollen gemeinsam ein Projekt realisieren. Mir ist dabei die Programmierung der Mikrokontroller zugefallen (Atmel AVR). Ich will die Signale von 3 Sensoren auswerten, die an die SPI angeschlossen werden. Mein Problem dabei ist, das ich nicht wirklich kappiere, was denn SPI genau ist. Ich habe mal bei Wikipedia vorbeigeschaut und habe dort herausgelesen, dass man da scheinbar einige Sachen parallel anhängen kann. Das finde ich an und für sich eigentlich recht genial. Aber weiter weiss ich leider nicht mehr. Kann mir da jemand helfen? Sputnik
SPI (Serial Peripheral Interface) ist ein Bus-Interface, das es ermöglicht, seriell Daten zwischen zwei oder mehr Teilnehmern auszutauschen. Dabei ist ein Teilnehmer der Master, die anderen Teilnehmer sind Slaves. Der Master erzeugt den Bustakt und fragt die Slaves ab. Ein Slave darf nur dann Daten senden, wenn er vom Master angesprochen wird. Da das Ansprechen der Slaves über Hardware geschieht (im Falle von mehr als einem Slave), ist SPI sehr schnell, da im Unterschied zu I²C (bei Atmel AVR TWI) keine Slave-Adresse mit übertragen werden muss. Darüberhinaus arbeitet SPI bidirektional, d.h. wenn der Master Daten sendet, sendet gleichzeitig auch der Slave. Du müsstest dir aber, um das Prinzip komplett zu verstehen, einige Grundlagen zu Bussystemen aneignen. In den Controller-Datenblättern steht auch einiges zum Thema drin.
Die Devices haengen nicht parallel, sondern seriell. SPI ist im Prinzip ein Satz Schieberegister, die einen geschlossenen Kreis bilden. Wenn der Controller nichts empfangen muss, kann der Kreis auch offen sein. Gemeinsam ist der Clock, meist vom Master, dem Controller gestellt. Gemeinsam auch das CS, mit dem wird der zuletzt anliegende Wert geladen. Falls man mehrere CS zur Verfuegung stellen kann/will, dann kaoennen die Devices allenfalls auch Parallel sein, vorausgesetzt, bei nicht-CS ist der Ausgang tristate. rene
>Die Devices haengen nicht parallel, sondern seriell. Son Quatsch! Die Devices hängen sehr wohl parallel am Bus. Sie werden nur seriell angesprochen. Devices (Slaves), die nicht per Select-Leitung angewählt sind, "nehmen die Beine vom Bus" - schalten ihre Ausgänge in den hochohmigen Zustand, damit es zu keinem Kurzschluß auf dem Bus kommt. Takt- und MOSI-Leitung betrifft das natürlich nicht. >SPI ist im Prinzip ein Satz Schieberegister, die einen geschlossenen >Kreis bilden Wie lange soll es dauern, bis ein Byte dann beim 5. Schieberegister angekommen ist? >Falls man mehrere CS zur Verfuegung stellen kann/will, dann kaoennen die >Devices allenfalls auch Parallel sein, vorausgesetzt, bei nicht-CS ist >der Ausgang tristate. Endlich etwas richtiges...
@rene:
> Die Devices haengen nicht parallel, sondern seriell.
Das ist eine spezielle Konfiguration von SPI, die zur Ansteuerung von
Schieberegistern genutzt werden kann. I.d.R. baut man den Bus jedoch
(v.a. dann, wenn es sich um irgendwelche Sensoren o.ä. handelt) so auf,
dass alle Teilnehmer parallel an den selben Leitungen (MISO, MOSI und
SCK) hängen und über Slave-Select-Signale ausgewählt werden, da die
meisten Bausteine, die über ein SPI-Interface verfügen, nicht in der
Lage sind, Daten "durchzuschieben" (Schieberegister-Architektur).
@Rahul: Und wieder die entscheidenden Sekunden... rene hat sich da etwas verhauen. Das was er meint, kann man durchaus machen, es ist aber ein spezieller Anwendungsfall... Quasi eine Daisy-Chain- Architektur.
> Die Devices haengen nicht parallel, sondern seriell. SPI ist im Prinzip > ein Satz Schieberegister, die einen geschlossenen Kreis bilden. Was soll das denn ? Das hört sich zumindest arg verquer an ! Alle Geräte hängen parallel an dem SPI Bus, wobei der Slave, der empfangen/senden sollen, CS High bekommt (also quasi ausgewählt wird).
>Quasi eine Daisy-Chain- Architektur.
Ja.
Das Problem ist höchstens, wenn man "dazwischen" Bausteine hat, die
entweder nur Empfänger oder nur Sender sind...
Beim Standard-SPI hängen alle Geräte mit ihren SCK-, MOSI- und
MISO-Leitungen parallel. Jedes einzelne kann durch die /CS- oder
/SS-Leitung ausgewählt.
@Rahul:
Meine Rede. Ich sag ja auch nur, dass das, was rene schreibt, machbar
ist, wenn man eine Reihe Schieberegister hat. Nur ist das in den meisten
Fällen nicht gegeben. Und in diesem Zusammenhang ("Ein Anfänger möchte
wissen, wie SPI funktioniert") ist renes Ansatz fehl am Platze, u.a.
weil er einen (seltenen) Spezialfall beschreibt und ihn zusätzlich noch
als "Regelfall" deklariert. Bringt nur durcheinander...
Danke für die schnellen Antworten. Noch besser wäre, wenn man mich zuerst nicht verwirren würde;) Also kann man bei drei Sensoren unäbhängig voneinander Daten empfangen? Ich habe da was gehört von wegen der Master gibt den Glock vor usw. Allgemein das mit dem Master und Slave habe ich nicht genau verstanden. Ich nehme gerne weitere Informationen entgegen. Bin etwas verwirrt. Sputnik
CS = Chip Select, damit wählt der Controller den entsprechenden Slave aus, wird auch oft SS (Slave Select) genannt. Ja, du hängst Deine 3 Sensoren an das SPI (also jeweils die Leitung MOSI, MISO und SCK vom µC zum Slave führen) und dann noch jeweils ein Pin des µC an den SS Pin des Slaves. Je nachdem welche SS Leitung der µC gerade auf 0 zieht kann der µC mit dem ausgewählten Slave kommunizieren. Stefan
Eine Verbindung eines uP mit einem (Sensor-) Baustein über SPI braucht 4 Signale. Der uP ist der "Master", der Sensor ist der "Slave". Die Kommunikation wird ausschließlich vom Master, also von uP aus gesteuert. Es gibt nur einen Master. Slaves kann es mehrere, theor. beliebig viele geben. Die 4 Signale nennen sich: MOSI Master Out, Slave In Ausgang des uP MISO Master In, Slave Out Eingang des uP CLK Clock immer uP (Master) CS Chip select Auswahlleitung Die CS braucht man (nur), wenn mehrere SPI Baustein (mehrere Slaves) an einem Master angeschlossen sind. Ein Sonderfall ist, wenn man nur einen "Slave" hat; dann kann der CS evtl. fest auf "low" geschaltet werden und man kommt mit nur 3 Leitungen aus. Die anderen 3 Leitungen aller Slaves sind jeweils parallelzuschalten. Die CS des aktiven Slave muss "low" sein. Für jeden Slave braucht man einen eigenen CS. 1 Slave: 3 + 1 CS Leitung --> 4 Leitungen insgesamt (siehe oben) 2 Slave: 3 + 2 CS Leitung --> 5 Leitungen 3 Slave: 3 + 3 CS " Der Master kann sich zu einer Zeit nur mit einem Slave unterhalten. Dazu wird die CS Leitung dieses Slave auf "low" aktiviert, alle anderen Slave CS müssen "high" (inaktiv) bleiben. Der Master muss "wissen", welcher Slave (jetzt) bedient werden soll. Natürlich kann man reihum alle nacheinander "abfragen". Aus einem "Slave" kommt nur was raus, wenn man (zumindest) den CS aktiviert und Clock anlegt. Wieviele Clocks ist von jeweiligen Slave abhängig; können z.B. exakt 25 Takte sein. Oft muss man erst gezielte "Befehle" in den Slave "reintakten", damit dann nach den 8 Takt (Beispiel) dessen Antwort kommt. Um die Antwort rauszubekommen, muss man weiter Takte anlegen (und genau mitzählen). Das Datenblatt des jeweiligen Slave-Bausteins sollte das alles beschreiben. Bei mehreren Slave Bausteinen kann man die erforderlichen CS elegant durch einen 3-zu-8-Decoder, Typ 74HC138 erzeugen lassen. So kann man mit insgesamt 6 Pins des uP dann 8 SPI Bausteine ansteuern (3 Leitungen der eigentlichen SPI, 3 weitere zum Decoder, die 8 Auswahlmöglichkeiten bieten). Die in bisherigen Antworten diskuitierte "Daisy Chain" (serielle SPI) ist ein Sonderfall und nur bedingt anwendbar, z.B. wenn man geeignete GLEICHARTIGE Slavebausteine hat. Oder lauter Schieberegister des Typs 74HC494/495. Das ist dann aber eben nur "EIN besonders langer" SPI Slave. So, ich denke das reicht zunächst.
Herzlichen Dank an euch (besonders Klaus). Jetzt scheint mir das ganze schon etwas überschaulicher. Nehmen wir einmal an, ich benutze den Atmega16 für mein Projekt. Bei dem ist die SPI am PORTB (MOSI = PB5, MISO = PB6, SCK = PB7). 1: Frage: Kann ich meine CS PINs frei wählen? (Ich habe keine solche gefunden) 2: Frage: Wenn ja, kann ich dann auch die restlichen I/O des PORTB (also ausser MOSI, MISO und SCK) als CS nutzen, oder gibt das Probleme? Immanuel
Die Auswahl des Slaves muss der Master über beliebige I/Os selber machen, wei Stefan schon angedeutet hat.
Die pins mit CS Funktionalitaet sind frei waehlbar. Ja, das kann vom Rest des PortB gemacht werden. Rene
johnny.m wrote: > Die Auswahl des Slaves muss der Master über beliebige I/Os selber > machen, wei Stefan schon angedeutet hat. Das kappiere ich nicht ganz. Wie weiss denn der uC an welchen I/O die CS sind? Muss ich dem das sagen, wenn ja wie? Und kann ich die Auswahl der Slaves nicht selber machen? Wenn das der Master ja selbständig macht, dann habe ich evtl. ja nicht die Daten des Sensors zur richtigen Zeit. Tut mir leid, dass ich so schwer von Begriff bin. Immnauel
> Und kann ich die Auswahl der Slaves nicht selber machen?
Eben das MUSST Du selber machen! Du kannst die Slave-Select-Signale für
die Slaves an beliebigen freien I/Os anschließen.
Beispiel: Das Slave-Select-Signal für Sensor 1 ist an PB0 angeschlossen. Wenn Daten von Sensor 1 ausgelesen werden sollen, setzt Du im Programm PB0 auf 0. Anschließend startest Du das SPI....
Ahhhhaaaaaa!! Hehe, ich du hast mir zu einer Epiphanie verholfen. Das tönt schon besser. Ich habe schon fast gedacht, der Controller kann Gedanken lesen. Da bin ich aber beruhigt, dass alles beim Alten bleibt;) OK, jetzt kann ich dann mal mein Schema zeichnen. Das ist schon immerhin etwas. Es ist mir aber noch lange nicht alles klar bei der SPI, aber das Frage ich dann weiter, wenn ich zu diesem Teil komme. Jetzt gieng es mir einfach mal darum, so ganz grob zu wissen, wie SPI funktioniert und wie ich meine Sensoren beschalten muss. Zusatzfrage (not essential): Ich habe im Datenblatt des Controllers (Atmega16) gesehen, dass man auch den Controller selber als Slave schalten kann (mittels !SS). Für was ist das gut? Kann ich so quasi ein Bussystem von Controllern aufbauen? Also fast ein Netztwerk, indem dann einfach einer der Master ist, mit einer Routine, die alle anderen organisiert und ihnen sagt, was sie zu tun haben?
>Kann ich so quasi ein Bussystem von Controllern aufbauen? Also >fast ein Netztwerk, indem dann einfach einer der Master ist, mit einer >Routine, die alle anderen organisiert und ihnen sagt, was sie zu tun >haben? Ja.
Das ist aber geil. Gut das ich das jetzt auch weiss, kann gut sein, dass ich das mal brauchen werde. Immanuel
>Das ist aber geil.
Das Thema wurde in anderen Threads auch schon besprochen: Es ist etwas
sehr anstrengend...
Wenn Du mehrere Controller miteinander verbinden willst, ist es i.d.R. sinnvoller, TWI zu benutzen. SPI-Slave-Betrieb bei den AVRs hat einige Tücken... Aber machbar ist es.
Übrigens, ein Hinweis auf eine kleine aber feine Falle beim SPI-Master-Betrieb: Der SS\-Pin des Masters darf nicht als Eingang konfiguriert werden, außer es ist sichergestellt, dass dieser immer High-Pegel hat. Wenn er als Eingang konfiguriert ist und ein Low-Pegel ankommt, dann schaltet das SPI-Interface automatisch auf Slave-Betrieb um. Zweck dieser Sache ist, eine Möglichkeit zum Aufbau eines Multi-Master-Systems zu liefern. Der SS\-Pin sollte also im SPI-Master-Betrieb nie als Signaleingang benutzt werden. Als Ausgang hingegen kann man ihn problemlos benutzen.
Danke für den Tipp. Der könnte mir nämlich lange Debug-Sesions vom Hals halten. Leute, ich muss sagen, dass das ein sehr gutes Forum ist. Ich kenne auf deutsch kein zweittes, das es mit diesem aufnehmen könnt. Hertzlichen Dank an alle Immanuel
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.