Hallo ! Ich habe bisher SPI immer nur in Senderichtung verwendet. Nun habe ich erstmalig eine Situation, wo ich auch Daten vom Slave empfangen muss. Mein Controller XMC4500 sendet hinaus, sobald ich etwas in ein Transmit-Buffer-Register schreibe. Der Controller sendet dann für ein Byte 8 Takte und setzt auch die richtigen Daten zu den Flanken auf MOSI - alles OK. Wenn ich nun aber eine Antwort erwarte, gibt es ja keine Clock - diese wird ja vom Master generiert. Wie gehe ich da vor? ich habe zwar ein Receive-Buffer Register, aber da kann ja nichts drinstehen, wenn keine CLK generiert wird. Die Frage ist nun, wie ich eine CLK generiere, wenn ich empfangen möchte. Muss ich etwa ein Byte gezielt raussenden, um gleichzeitig etwas empfangen zu können? Und wie verhindere ich, dass dieses "zweckentfremdete" Byte beim Slave als Kommando interpretiert wird? Ich kann das ja überhaupt nicht verhindern, da ja immer irgendein Signal am Sendeausgang liegt. Kann jemand meinen gedanklichen Knoten entwirren und mich aud die richtige Fährte bringen? Vielen Dank, Michael
Michael W. schrieb: > Muss ich etwa ein Byte gezielt raussenden, um gleichzeitig etwas > empfangen zu können? Und wie verhindere ich, dass dieses > "zweckentfremdete" Byte beim Slave als Kommando interpretiert wird? Ja, ein Dummy-Byte, welches beim Slave nicht als Befehl verstanden werden kann. Kommt da halt auf den Slave an.
Joe F. schrieb: > http://www.corelis.com/education/SPI_Tutorial.htm > http://www.mct.de/faq/spi.html Danke für diese Links, aber ich finde dort nichts, was meine Frage beantworten könnte... Diese sind: 1) wie erzeuge ich ein CLK Signal, wenn ich empfangen will? Nach dem Senden eines Kommandos geht CLK auf den IDLE Zustand. 2) Falls ich für das Empfangen extra senden muss: woher weiß der Slave, dass die gesendeten Daten nicht relevant sind? Ich verstehe halt einfach nicht, wie man hier richtigerweise vorgeht...
Dirk Knoblich schrieb: > Ja, ein Dummy-Byte, welches beim Slave nicht als Befehl verstanden > werden kann. Kommt da halt auf den Slave an. Und das ist tatsächlich üblich und nicht nur ein "Workaround"?
Michael W. schrieb: > 2) Falls ich für das Empfangen extra senden muss: woher weiß der Slave, > dass die gesendeten Daten nicht relevant sind? Der Master muss (dummy bytes) senden, wenn er empfangen will. Wie viele genau, hängt vom jeweiligen Chip und dessen Protokoll ab, und ist im jeweiligen Datenblatt dokumentiert. Die Abgrenzung/Synchronisation einzelner Transactions ist über das Chip Select Signal gelöst.
Michael W. schrieb: > 2) Falls ich für das Empfangen extra senden muss: woher weiß der Slave, > dass die gesendeten Daten nicht relevant sind? Das kommt auf den Slave an. Wenn du den unter Kontrolle hast (sprich selbst programmierst), dann weiss dein Programm, dasss nur jedes 2.te reingetaktete Byte ein Befehl sein kann. Alternativ kann man natürlich auch dem Slave ein Kommando 'Do Nothing' verpassen, dass der Master immer dann ausgeben kann, wenn er eigentlich eine Antwort vom Slave haben will, die er vorher bereits mit einem anderen Kommando angefordert hat. Ansonsten taktest du ihm halt ein harmloses 'Kommando' rüber, welches de facto am äusseren Verhalten des Slaves nichts bewirkt.
:
Bearbeitet durch User
Michael W. schrieb: > Danke für diese Links, aber ich finde dort nichts, was meine Frage > beantworten könnte... http://www.corelis.com/education/SPI_Tutorial.htm Im Abschnitt "Simple Read Transaction" ist es sehr gut beschrieben.
Michael W. schrieb: > Wenn ich nun aber eine Antwort erwarte, gibt es ja keine Clock - diese > wird ja vom Master generiert. Wie gehe ich da vor? Bei SPI gibt es kein Senden und Empfangen als getrennte Funktionen. SPI kennt nur den Transfer, d.h. den Austausch der Daten zwischen Sender und Empfänger. Der Master gibt dabei den Takt vor - darum heißt er Master.
Was passiert eigentlich, wenn nach einem Kommando an einen Slave dieses 3 Antwortbytes liefern soll, und ich stattdessen 4 Bytes auslese? Einen Takt kann ich immer anlegen, und logische Pegel auf MOSI/MISO sind immer vorhanden. Ich nehme an, dass das Verhalten in diesem Fall von der Implementierung abhängt, aber gibt es da irgendwelche Konventionen?
Das steht eigentlich immer in der Beschreibung vom Slave, wie er sich verhält bzw. was er erwartet. Wenn du 3 Bytes erwartest, mußt du auch 3 Bytes senden bzw. wenn der Sendepuffer nur jeweils Bytepaare senden kann (wie z.B. beim MSP430) dann mußt du das nicht erwartete Byte, das du dann vom Slave auch obendrauf bekommst, verwerfen. Aber meistens ist das schon recht brauchbar in den Slaves implementiert, ohne daß man viel im Controller herumschieben muß. Interessant wird es auch bei SDIO, wo du nur eine Leitung zum Slave hast, die nach jeweils ein paar erwarteten Bytes, die du schickst, automatisch vom Sende- in den Empfangsmodus schaltet und du dann die erwartete Byteanzahl auch mit 'dummen Bytes' takten mußt.
Man muß auch bedenken, das MC-Slaves oft keinen Buffer oder DMA haben. D.h. der Master muß erstmal nach jedem Dummy-Byte eine genügend lange Gedenkpause einlegen, damit der Slave in den Interrupt springen und das nächste Byte ins Schieberegister schreiben kann.
:
Bearbeitet durch User
Michael W. schrieb: > Was passiert eigentlich, wenn nach einem Kommando an einen Slave dieses > 3 Antwortbytes liefern soll, und ich stattdessen 4 Bytes auslese? Du musst begreifen, was SPI ist und wie SPI funktioniert: SPI sind nur gekoppelte Schieberegister. Ein Taktimpuls schiebt den Inhalt dieser Register um eins weiter. Mit dem SS-Signal wird dem Slave dann meist signalisiert: genug geschoben, Daten übernehmen. http://www.lothar-miller.de/s9y/archives/15-SPI.html > Ich nehme an, dass das Verhalten in diesem Fall von der > Implementierung abhängt, aber gibt es da irgendwelche Konventionen? Nein. Aber in der Regel ist es so, dass die zuletzt eingeschobenen Daten in den Registern stehen und übernommen werden. Du kannst üblicherweise einfach Durchtakten: das was am Eingang des Slaves reingeht, kommt irgendwann am Ausgang wieder raus. Du musst nur lange genug takten und nachschieben. Aber was konkret passiert steht entweder im Datenblatt oder es ist undefiniert und du willst es gar nicht erfahren...
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.