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
Nimm RS485 Treiber, die haben einen groesseren Gleichtaktbereich. LVDS hat nu ein paar mV
St. D. schrieb: > eventuell verlangsamen... Das hilft genau nullkommanix. Franz schrieb: > Welche Maßnahmen gibt es konkret Abgeschirmtes Kabel.
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
SPI ist für sowas nicht gedacht. Mit langsamen Schmitt-Triggern (CD40106BE) könnte man die Eingänge unempfindlicher machen.
:
Bearbeitet durch User
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?
Checksumme ins Protokoll einbauen, Daten mehrmals übertragen und fehlerhafte Daten einfach ignorieren wäre auch noch eine schnelle Massnahme.
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.
Franz schrieb: > RS485 habe ich noch nie gehört Dann wirds Zeit. 2MHz bei 10m Länge sind da locker drin MAX490 z.B. Grüße Runout
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.
>Das ist aber unschön
Dann mache es richtig und platziere den uC direkt am Display. Oder Dein
uC muss ein VIdeosignal (VGA, HDMI etc) bereitstellen.
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.