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
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?
Eine eigene Frage?
Dieser Thread ist über 14 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
