Hallo, ich habe eine SPI-Verbindung zwischen 2 uC mit ca. 1 MHz, die nur funktioniert, wenn ein Tastkopf an SCK angeschlossen ist, bzw. ein Kabel auch ohne Oszi. Auch bei einem einfachen BNC-Kabel ohne (1:1/1:10)-Tastkopf. Sonst empfange ich nur Datenmüll, oft um ein paar Bits verschoben, aber meistens ohne Zusammenhang zum gesendeten Signal. Nun habe ich bereits von SCK 10pF, bzw. 100pF nach Masse gezogen, was aber nichts gebracht hat. Dummerweise habe ich keine SS-Leitung, was ich aber nicht ändern kann. Mit dem Kabel funktioniert die Kommunikation einwandfrei. Was kann ich tun? Viele Grüße Munzi
Jürgen Ungerer schrieb: > Mit dem Kabel funktioniert die Kommunikation einwandfrei. Was kann ich > tun? Mit der anderen Clockflanke das Datensignal übernehmen MfG Klaus
Mit Tastkopf oder Kabel hat das vermutlich nichts zu tun. Ein Oszi hat ja in erster Linie eine Eingangsimpedanz. Die hat eine SPI so erstmal nicht also liegt für mich nahe das es irgendwo zu Reflektionen kommt oder die Pegel nicht reichen. Auch die Fehler lassen das vermuten. Also erstmal eine Abschlusswiderstand versuchen, danach einen Reihenwiderstand um die slew rate zu verringern und dann einen pull up Widerstand um den Pegel zu beeinflussen.
A. K. schrieb: > Wie lang ist die Leitung zwischen den µCs? Die Leitung ist vielleicht 3cm lang. Die CPOL habe ich schon umgedreht. Hat nix gebracht.
Jürgen Ungerer schrieb: > Die Leitung ist vielleicht 3cm lang. Hallo Jürgen, wir haben ein ähnliches Problem, auch auf kurze Distanz, bei uns jedoch umgekehrt: Je mehr Last (wenige pF des Tastkopfes) desto mehr Müll kam an. Die Taktleitung der SPI Schnittstelle IST sehr empfindlich. Abschließen ist eine gute Empfehlung, schau auch in das Datenblatt des Herstellers dazu rein. Wir haben im übrigen NICHTS gemacht nachdem die Kommunkation ohne Last stabil geblieben ist. rgds
6A66 schrieb: > Abschließen ist eine gute Empfehlung, schau auch in das Datenblatt des > Herstellers dazu rein. Bei einer 3cm langen Leitung wirkt das nicht wirklich zwingend.
Testweise mal einen Pullup- oder Pulldown-Widerstand an SCK gehängt?
Der Rächer der Transistormorde schrieb: > Mit Tastkopf oder Kabel hat das vermutlich nichts zu tun. Ein Oszi hat > ja in erster Linie eine Eingangsimpedanz. Die hat eine SPI so erstmal > nicht also liegt für mich nahe das es irgendwo zu Reflektionen kommt > oder die Pegel nicht reichen. Auch die Fehler lassen das vermuten. > > Also erstmal eine Abschlusswiderstand versuchen, danach einen > Reihenwiderstand um die slew rate zu verringern und dann einen pull up > Widerstand um den Pegel zu beeinflussen. Ein 10k von SCK gegen Masse und es läuft.
@ Jürgen Ungerer (munzi)
>Ein 10k von SCK gegen Masse und es läuft.
Behauptung oder Beobachtung? Das ist eher ein Zeichen dafür, dass was
faul ist. SPI läuft, wenn man ein paar Grundreglen beachtet sehr stabil,
erst recht bei 3cm Kabellänge. Ohne irgendwelche Pull-Widerstände.
Solange SPI nicht eingeschaltet ist floatet SCK. Wenn der Slave vor dem Master eingeschaltet wird und keine per Pullup deaktivierte SS-Leitung hat, dann taktet er jede Störung auf SCK als Daten durch. Der Pulldown bewirkt, dass SCK keine Störtakte liefert, wenn der Master nicht aktiv konfiguriert ist. Je nach SPI-Modus ist ein Pulldown- oder up angesagt. Ein grundlegendes Problem bleibt: Ein einziger Störtakt und die ganze Chose gerät ausser Tritt, gibt dann eine bleibende Bitverschiebung. Wenn mangels SS oder eines anderen Signal keine Möglichkeit besteht, den Beginn oder Ende eines Frames zu erkennen, dann muss in Software ein Weg gefunden werden, den SPI-Slave beispielsweise bei längerer Inaktivität zurück zu setzen. Und der Master muss ab und zu für eine solche Pause sorgen.
Falk Brunner schrieb: > Behauptung oder Beobachtung? Das ist eher ein Zeichen dafür, dass was > faul ist. SPI läuft, wenn man ein paar Grundreglen beachtet sehr stabil, > erst recht bei 3cm Kabellänge. Ohne irgendwelche Pull-Widerstände. Das ist eine Beobachtung. A. K. schrieb: > Solange SPI nicht eingeschaltet ist floatet SCK. Wenn der Slave vor dem > Master eingeschaltet wird und keine per Pullup deaktivierte SS-Leitung > hat, dann taktet er jede Störung auf SCK als Daten durch. Dann kann ich, abgesehen vom SS-Problem, das Problem lösen indem ich die Master-SPI vor der Slave-SPI initialisiere? Vielen Dank und viele Grüße Munzi
@ A. K. (prx) >Solange SPI nicht eingeschaltet ist floatet SCK. Wenn der Slave vor dem >Master eingeschaltet wird und keine per Pullup deaktivierte SS-Leitung >hat, dann taktet er jede Störung auf SCK als Daten durch. Das klingt plausibel.
Jürgen Ungerer schrieb: > Dann kann ich, abgesehen vom SS-Problem, das Problem lösen indem ich die > Master-SPI vor der Slave-SPI initialisiere? Ja. Aber wie schon erwähnt: Wenn das mal ausser Tritt gerät, dann fängt es sich nicht automatisch wieder sondern bleibt verschoben.
Jürgen Ungerer schrieb: > Dummerweise habe ich keine SS-Leitung, was ich > aber nicht ändern kann. Solange Du Dich nur selber damit rumärgern mußt, bitteschön. Verkaufen würde ich so ein Produkt aber nicht, das gibt mit Sicherheit Probleme. Peter
Ich habe es gerade probiert. Anscheinend ist das mit der Initialisierung nicht so einfach, da es auch in dieser Reihenfolge ohne den 10k nicht funktioniert.
skyperhh schrieb: > Sind die beiden uC's von Atmel, also ATMega32 oder ähnlich? Nein, sie sind ARM Cortex, genauer STM32.
Ok... denn bei den ATMegas ist der SS-Eingang im SPI Master Mode eine schöne Fehlerquelle, wenn der Pin als Eingang konfiguriert ist!! Dann muss er auf High liegen, bei Low schaltet der uC sonst in den Slave Mode ... wenn der SS-PIN als Ausgang gesetzt ist hat er keinen Einfluss ... Evtl. hat der STM32 ein ähnliches Verhalten...
Jürgen Ungerer schrieb: > Nein, sie sind ARM Cortex, genauer STM32. Dann wär das Programm vielleicht interessant. Über die SS-Programmierung des STM32-SPI haben sich schon viele gewundert. Ja, ich weiss du hast kein SS. Aber der STM32 hat trotdem eines, und sei es nur intern, ob du willst oder nicht. Wenn man da nicht aufpasst, dann wird aus dem Master flugs mal ein Slave.
A. K. schrieb: > Dann wär das Programm vielleicht interessant. Beim Slave setze ich im CR1-Register das SoftwareSlaveManagement-Bit (Bit 9), sowie den Prescaler, gemäß Datenblatt: "set the SSM bit and clear the SSI bit in the SPI_CR1 register" Beim Master zusätzlich noch das InternalSlaveSelect-Bit (Bit 8) und das Master-Config-Bit. Nach der Initialisierung geht der Rest über DMA, aber das ist ja für NSS weniger relevant.
skyperhh schrieb: > Ok... denn bei den ATMegas ist der SS-Eingang im SPI Master Mode eine > schöne Fehlerquelle, wenn der Pin als Eingang konfiguriert ist!! Dann > muss er auf High liegen, bei Low schaltet der uC sonst in den Slave Mode > ... wenn der SS-PIN als Ausgang gesetzt ist hat er keinen Einfluss ... Am NSS-Pin liegt an Master und Slave bereits ein Signal an (Pins jeweils als Eingang konfiguriert). Daher kann ich den NSS nicht einfach auf High ziehen.
Jürgen Ungerer schrieb: > Beim Slave setze ich im CR1-Register das SoftwareSlaveManagement-Bit > (Bit 9), sowie den Prescaler, gemäß Datenblatt: "set the SSM bit and > clear the SSI bit in the SPI_CR1 register" > > Beim Master zusätzlich noch das InternalSlaveSelect-Bit (Bit 8) Du löschst also auf dem Master SSI und setzt Bit 8? In welcher Reihenfolge? ;-)
A. K. schrieb: > Jürgen Ungerer schrieb: >> Beim Slave setze ich im CR1-Register das SoftwareSlaveManagement-Bit >> (Bit 9), sowie den Prescaler, gemäß Datenblatt: "set the SSM bit and >> clear the SSI bit in the SPI_CR1 register" >> >> Beim Master zusätzlich noch das InternalSlaveSelect-Bit (Bit 8) > > Du löschst also auf dem Master SSI und setzt Bit 8? > In welcher Reihenfolge? ;-) OK, ich drücke mich klarer aus: Nach der Konfiguration ist CR1 beim Slave 0x0228 (das SSM-Bit ist gesetzt und SSI gelöscht) und beim Master ist CR1 0x032C (sowohl SSM als auch SSI und darüberhinaus MSTR gesetzt).
Jürgen Ungerer schrieb: > Am NSS-Pin liegt an Master und Slave bereits ein Signal an (Pins jeweils > als Eingang konfiguriert). Daher kann ich den NSS nicht einfach auf High > ziehen. ... ich hab keine Ahnung, ob der ARM STM sich ähnlich oder genauso wie ein ATMega verhält. Wenn der STM aber auch Multimaster-Fähigkeit für den SPI-Bus hat, dann könnte das ganze vielleicht damit zusammen hängen... am besten tief in der Doku zum uC nachschauen...
Die einzig professionelle Lösung ist, die Platine wegzuschmeißen und eine neue mit SS-Leitung zu machen. Ansonsten geh lieber in die Politik. Da werden auch nur die Symptome bekämpft, nicht aber die Ursachen. Sonst könnte sich ja was ändern (Gott behüte). Peter
Mir ist völlig klar, dass es SS braucht. Aus der Beschreibung zu SS wird aber kein Mensch schlau, weswegen es ja auch so viele Fragen hier dazu gibt. Da vermisse ich die guten alten AVR-Datenblätter.
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.