Moin, ich sitz hier an einer kleinen Baustelle. Ich hab zwei STM32F417 und wollte, dass sie sich miteinander unterhalten. SPI läuft auch soweit nur gibt es bei der Testimplementierung - RND-number von Master nach Slave und die Number vom Slave als Echo zurück - das Problem, dass sich die Rückgabe um einen Byte(auch die Datenbreite) verzögert. Der Test auf Gleichheit von gesendetem und empfangenem Wert schlägt also jedes mal fehl. Die Frage ist nun ob das grundlegend so ist und ich an einem Workaround arbeite oder ob ich weiter im source suchen muss - grundsätzlich sieht das nämlich gut aus. Sourcen habe ich leider grad nicht zur Hand. Könnte ich aber nachliefern. Grundsätzlich halte ich mich an die Beispiele von STM hab aber unnötige Methodenaufrufe teilweise durch Macros ersetzt. - wie gesagt gundlegend funktioniert es, bis auf den delay oder offset oder wie man das auch gernen nennen möchte. Was evtl noch zu sagen ist, dass der offset sich erhöht auf wenn ich den master chip über JTAG debugge(auch mehrfach). Hierbei werden dann aus einem Byte gerne mal vier - könnten auch nochmehr werder, das habe ich weiter nicht getestet. Hierbei könnte es alerdings daran liegen, dass der Slave noch das Echo zurück sendet wärend der Master grad neu via JTAG-debugger bootet und die Echos dan aber verzögert noch im Master ankommen. Bitte auch Feedback wenn ihr das Problem nicht habt, dann weiß ich zumindest, dass es nicht grundsätzlich so ist.
OK, das war wohl ein bisschen viel Text ohne klare Frage: Problem: Senden über SPI erfolgt korrekt, jedoch antwortet der Slave erst ein Byte später mit der richtigen Antwort (gesendetes Byte). Zuerst sendet er eine 0, danach schickt er alle Bytes genauso zurück, wie gewünscht. Wieso sendet der Slave zuerst die Null? Wie kann ich das umgehen bzw. was mach ich falsch?
Das ist doch richtig! Der Slave übernimmt die Daten ja Byteweise. Heißt er wartet so lange bis das erste Byte angekommen ist, um dieses bei dem nächsten Byte zurückzusenden. Das was der Slave als erstes im Puffer hat ist ein DummyByte. Er kann zu dem Zeitpunkt ja nicht wissen was kommt und die Daten bitweise zurückschicken.
OK, aber genau dieses dumme Byte macht mir schwer zu schaffen ... Wie werde ich das los? Ich möchte beispielsweise einen Befehl senden und erwarte eine bestimmte Antwort, diese bleibt aber aus, da Dummy-Byte sich vordrängelt. Gibt es da ein Work-Arround? Wo hängt dieses Byte eigentlich fest? Wenn ich mit dem Master sende, dann kommt das ja auch direkt beim Slave an, ohne ein Dummy. Da der Slave genauso sendet wie der Master muss das Byte also im RX-Buffer des Masters sitzen ?? Ich steh da echt auf dem Schlauch :(
OK, OK ... langsam bekomme ich eine düstere Ahnung, wo mein Verständnisproblem liegt: Ist es richtig, dass SPI-Slave nur antwortet, während der Master sendet?
Verwende die Bytes doch erst ab dem 2ten Zeichen... Schmeiss das Erste einfach nach dev/null oder beachte es nicht... Um aber alle Zeichen zu empfangen musst du wohl auch noch ein Dummy Byte am Ende senden.. Cheers
Grins, eigentlich wollte ich dem Slave mitteilen: DMA-Stream initialisieren, xBytes lang, gib Bescheid wenn ich loslegen darf ... Jetzt also statt ursprünglich 3 zu sendenden Bytes also 5 ... naja. Ist das nur bei den STM32s so? Dafür hab ich heute den ganzen Tag gebraucht ... echt traurig
Das ist das Prinzip von SPI. Funktioniert eben genau so. ==> Grundlagen von SPI nachlesen und verstehen
Ist nun schon einige Zeit her. Ich frage mich nun ob ich wieder ein grundlegendes Verständnisproblem habe oder ob da irgendetwas anderes faul ist. Ich habe hier zwei STM32f4 die sich unterhalten sollen, SPI und DMA laufen auch. Wenn ich die CRC- Summe dazu schalte, sendet der MASTER(auch als Master SPI konfiguriert) ab einem offset nur noch 0en. Der Offset ist hier offenbar Zeitabhängig.Da es läuft wenn ich direkt nach der Aktivierung den eine Wartezeit einbaue, was aber nicht Sinn der Sache bei der Benutzung von DMA ist. Ich hab schon darauf spekuliert, dass zwischendurch dass der Chipselect(NSS) deaktivert wird, zumal das bei mir in den gleichen Methoden behandelt wird, allerdings kann ich das ausschließen. Code-Technisch sieht das alles garnicht schlecht aus. Eins sollte ich evtl noch sagen parallel zum Senden über den SPI(hier SPI 1) ist auch noch ein zweiter SPI aktiv der mit einem Netzwerkchip spricht. Das ganze läuft über eine Pipliningprinzip via verschiedenen Statemachines(SM), die nacheinander abgearbeitet werden. Wenn alle einmal durchwandert wurden kommt die erste wieder dran. Was in diesem Fall heist, dass der SPI 1 TX DMA auf Abschluß der Arbeit geprüft wird(falls nicht weiter mit dem nächsten). Achso die Synchronizität des des CRC Aktivierens kann es auch nciht sein, da ich auf inaktivität des SPIs warte bis ihn aktiviere bzw deaktiviere(Master und Slave-Seite). Also nun meine Frage ist jemeandem ein solches evtl. schematische Problem bekannt? zB als Wechselwirkung bei der Benutzung mehrere SPIs oder darf man neben dem Senden via DMA(incl CRC) nichts anderes(oder Rechenintensives) machen? In der STM32 Doku hab ich dazu nicht gefunden?
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.