Hallo zusammen,
ich habe einen Slave via SPI am Microcontroller verbunden.
Der Slave sitzt im Auto-Motorraum und der Microcontroller im
Handschuhfach.
Kabellänge ca. 1,8m.
In regelmäßigen Abständen habe ich Bitfehler, was ich auf dielangen
Leitung, Zündspulen, etc zurückführe.
Welche Maßnahmen gibt es konkret, um die Störempfindlichkeit zu
verbessern?
Würde es sinnvoll sein, einen LVDS-Treiber/Empfänger für die Daten- und
Clockleitung zu verwenden? Ich meine der Hub beträgt ja nur ja +/- 0,3
V???
Über Tipps und sonstige Hinweise würde ich mich bedanken.
Grüße Franz
Erstmal wäre es sinnvoll zu wissen mit welcher Frequenz das SPI
Arbeitet.
Ansonsten ist SPI grundsätzlich eher ungeeignet um Daten über eine so
weite Strecke zu transportieren.
Franz schrieb:> Würde es sinnvoll sein, einen LVDS-Treiber/Empfänger für die Daten- und> Clockleitung zu verwenden?
Das könnte helfen. Außerdem wäre eine Geschirmte Leitung zu verwenden.
Franz schrieb:> Über Tipps und sonstige Hinweise würde ich mich bedanken.
-Wie gesagt geschirmte Leitung ist nie verkehrt.
-Die Datenrate sinnvoll wählen (um nochmal auf die SPI Frequenz zu
kommen)
-Dafür gedachte Schnittstellen nutzen (CAN, LIN, RS485, usw.)
Hi,
bei allen Maßnahmen wie Verstärkern, Treibern usw. ist zu bedenken das
Jede Stufe Verzögerungen zur Folge hat und das die SPI Kommunikation
durch die Taktvorgabe durch den Master zumindest für den Datentransfer
SLAVE->Master anfällig gegenüber Latenzen ist (Zeitkritisch).
Der Master gibt ja die Taktflanke auf die SCL Leitung und erwartet dann
nach Ablauf der Zeit t ein gültiges Datensignal auf der MISO Leitung.
Wenn aber erst das Taktsignal durch einen Treiber verzögert beim Slave
ankommt und dann noch das Datensignal wiederrum durch einen Treiber
verzögert wird, dann KANN es dazu führen das der MAster den Pegel an
MISO zu einem Zeitpunkt einliest wo dieser noch gar keinen gültigen Wert
hat.
Man muss daher die Verzögerungen immer im Blick haben und vor der
Auswahl von Treibern immer schauen ob es dann noch zu der gewählten
Datenrate passt.
(Die Zeiten für die Verzögerungen findet man in den Datenblättern der
Treiber, die Zeit wann der Master nach dem setzen der Clock ein gültiges
Signal erwartet in dessen Datenblatt)
Generell ist SPI aber kein für größere Leitungslängen geeigneter Bus und
genau wie I2C in erster Linie für Datenübertragun innerhalb eines
Gerätes vorgesehen. Dieses über längere Verkabelung, noch dzu in einem
so Störkritischen Umfeld wie ein Auto o.ä., zu führen ist Pfusch.
Wenn man dies aber unbedingt machen will, dann erreicht man eine
Störunempfindlichkeit dadurch das man die ganze Leitung möglichst
niederohmig macht. So das auch wirklich ein paar mA über die Leitung
gehen.
Also guter Treiber und niederohmiger Abschluss.
Allerdings ist SPI nicht nur hinsichtlich der Störempfindlichkeit
kritisch, sondern auch hinsichtlich der Störemission. Und diese Maßnahme
würde die Störabstrahlung noch erheblich steigern. Das muss einem
bewusst sein.
Die "richtige" Lösung wäre es so zu machen wie es die großen auch
machen:
Die Daten des Sensors "vor Ort", also schon im Motorraum o.ä., auswerten
und das ganze dann schon aufbereitet über einen für dieses Umfeld
geeigneten Bus an die Zentraleinheit übertragen.
Also einen kleinen µC mit SPI und CAN Schnittstelle zum Sensor und dann
mittels CAN Bus die Daten in den Innenraum weiterleiten.
So wie es bei (fast) jedem anderen Sensor/Steuergerät im Auto auch
gemacht wird.
Gruß
Carsten
Hallo, vielen Dank für eure Antworten.
Ich weis bei der Vielzahl an Antworten gar nicht, wo ich jetzt anfangen
soll.
Ich habe im Motorraum ein kleines 1.8" Display, auf welchen ich mir
Motorwerte anschaue, die vom Steuergerät (Handschuhfach) stammen.
Das Display habe ich so programmiert, dass da eine "Menge" Daten
unidirektional übertragen werden. Das Display, d.h. jeder Pixel wird
einmal in der Sekunde geupdatet.
SPI läuft mit 4 MHz.
Die Idee mit den CAN-Bus gefällt mir bisher am besten.
RS485 habe ich noch nie gehört, aber bevor ich da jetzt groß die Timings
anschaue, ist es vielleicht am besten, auf CAN zu wechseln.
Vielen Dank für eure ausführlichen Antworten!
Franz schrieb:> SPI läuft mit 4 MHz.
Na, dann wäre das Problem ja präzise geklärt. Macht die SPI-Leitung kurz
(wenige Zentimeter), verlegt den Controller direkt neben das Display und
dafür die CAN-Datenleitung länger. Die ist nämlich genau dafür gebaut.
Franz schrieb:> Welche Maßnahmen gibt es konkret, um die Störempfindlichkeit zu> verbessern?
Wie sieht denn die Schnittstelle jetzt aus?
Und was für Störungen hast Du? Zuviele clocks, zu wenige oder falsche
Daten?
Welche leitung.und wie abgeschlossen?
Walter T. schrieb:> Macht die SPI-Leitung kurz> (wenige Zentimeter), verlegt den Controller direkt neben das Display und> dafür die CAN-Datenleitung länger. Die ist nämlich genau dafür gebaut.
Das beschreibt eigentlich genau, wie das normalerweise gemacht wird.
Hallo,
vielen Dank, ich habe mich jetzt doch für RS485 entschieden, da ich
einen Microchip µC nutze und die Implementierung des CAN-Busses für mich
einfach zu komplex ist. (ich nutze die HAL nicht)
Den zweiten µC auf der Empfängerseite möchte ich somit "versuchen" weg
zu lassen, d.h. das SPI direkt über RS485 übertragen, in der Hoffnung,
dass Clock und Daten im Timing identisch verzögert werden und es beim
Empfänger-Display zu keinen Timingproblemen kommt.
Ich habe Pixelfehler, d.h die Farbe stimmt bspw. bei einigen Pixeln
nicht.
In unregelmäßigen Abständen (ca. alle 10 min) hängt sich das Display
auch mal auf. Zur Zeit "starte" ich das Display deshalb in regelmäßigen
Abständen neu(alle 10 sek). Das ist aber unschön (geht dann einmal kurz
aus und an). Bedeutet aber, dass ich nach spätestens 10 Sekunden wieder
Messwerte empfange.
Genau so schlimm sind aber die Pixelfehler. Um diese zu verhindern,
schreibe ich jede Sekunde das komplette Display neu, was ordentlich
Traffic generiert, der eigentlich unnötig ist.
Beides erhoffe ich, durch RS485 verhindern zu können.
