Hallo zusammen, Ich arbeite derzeit an einem Projekt, bei dem über 3 UARTs Daten an 3 Boards von einem µC aus übermittelt werden. Bei einzelnen Modulen funktioniert die Datenübertragung einwandfrei. Stecke ich aber nun zwei Pins neben der einen Datenleitung die andere an, so verliert die Schnittstelle bis zu 10 Bytes an Daten. Dieses Phänomen lässt sich durch ein- und ausstecken des Kabels gut reproduzieren und andere Fehlerquellen sich dadurch meiner Meinung nach auch ausschließen. Jetzt meine Frage: Hat das was mit EMV zu tun oder ist das etwas anderes? Und wie lässt sich das beheben? Zusatz: Im Moment arbeite ich mit Kabeln, die an Buchsenstecker gelötet sind. Ich habe schon versucht durch umwickeln mit einem Kabel, das ich auf GND lege die Leitung zu "schirmen", aber das bringt wenig Erfolg.. Danke schon mal für die Hilfe!
Erstmal die Signale messen. Dann kann man sich ins Reich der EMV begeben. Ach übrigens. Benedikt schrieb: > reproduzieren und andere Fehlerquellen sich dadurch meiner Meinung nach > auch ausschließen. Nein das ist nicht korrekt. Wenn deine "Verbindung" auf Kante läuft und bereits jegliche Margins aufgefressen sind, kann ein Tropen zu viel das Fass zum Überlaufen bringen. Dieses "Phänomen" könntest du theoretisch auch hier beobachten haben. Also erstmal messen. Außerdem kann dir hier keiner Fragen zum EMV-Aufbau beantworten, wenn du nicht mal den Systemaufbau konzeptionell dargestellt hast. EMV zu bewerten macht nur im Hinblick auf das Gesamtsystem Sinn -> GND-Verbindungen, Versorgung, Planes, Schirmung, Gehäuse, Taktquellen, ach so viel Themen...
Grundsätzlich ist mit EMV eigentlich eher das störende Verhalten einer Schaltung gemeint. Du hast vermutlich ein Signalintegritätsproblem. Das ganze beginnt schon damit, dass du längere Strecken (???) über UART brückst. Dafür ist UART nicht gemacht. Ein paar Zentimeter sind meist kein Problem aber darüber hinaus gibt es Probleme. Natürlich gibt es Ausnahmen aber im Gunde ist UART für längere Distanzen nicht geeignet. Darum hat man Schnittstellen definiert welche U(S)ART auf Pegel bringen die einen höheren Störabstand haben. Plug and Play bieten sich dafür RS232 und RS422 an. Für die gibt es sog. Transceiver ICs die dann für eine störunempfindlichere Übertragung sorgen. Natürlich ist das jetzt erstmal ein gedanklicher Schnellschuss und die Probleme könnten auch noch an tausenden anderen Stellen liegen (fehlende Masseverbindungen, Aufbau, ...) Darum solltest du Schaltplan und Foto vom Aufbau hier posten. Vielleicht sieht man da schon was. Als erste Maßnahme kannst du (soweit es die Sensoren zulassen) die Datenrate reduzieren. Je langsamer, desto unwarscheinlicher ist es, dass die Störung für eine Bitänge anhält. Außerdem kannst du versuchen immer nur einen Sensor anzusprechen (?) damit der sog. Crosstalk zwischen den Leitungen nicht stattfinden kann. Natürlich müssen die Sensoren das ganze mitmachen und nicht ungefragt selbst Daten senden. Ein paar weitere Infos (welche Sensoren, Aufbau, ...) wäre gut ...
Bevor ich das Wort EMV in den Mund nehme schau ich immer erst nach den Masseleitungen.
Benedikt schrieb: > Jetzt meine Frage: Hat das was mit EMV zu tun oder ist das etwas > anderes? Wenn die EMV gegeben ist, sich elektromagnetisch also alles verträgt, kann es nicht zu Störungen kommen.
Danke soweit. Könnte jemand die Störung mal simulieren und den entsprechenden Oszi-Screen posten. Brauche einen visuellen Überblick über die Störung. Danke Benedikt
Benedikt schrieb: > Danke soweit. > > Könnte jemand die Störung mal simulieren und den entsprechenden > Oszi-Screen posten. Brauche einen visuellen Überblick über die Störung. Danke, dass du dich nun entlarvt hast.
Beitrag #5819380 wurde von einem Moderator gelöscht.
Hi, danke schonmal für die vielen Antworten. Die Antwort oben drüber war nicht ich.. Ich übertrage über eine Strecke von maximal 15cm und wollte eigentlich auch andere Schnittstellen als UART verwenden, aber das funktioniert leider nicht mit der Hardware. Ich werde mir das ganze heute mal am Oszi anschauen und auch eine geringere Datenrate testen. Prinzipiell funktioniert mein Aufbau so, dass über einen Master an 3 Slaves jeweils 1024 byte gesendet werden und danach ein Enable Signal kommt, sodass die Slaves die Daten mit minimaler Verzögerung an ihre Treiberbausteine geben können. Einen so wirklichen Schaltplan habe ich noch nicht, aber ich bin auch gerade dabei ein Shield zu designen. Hier würde ich sowohl in Top & auch Bottom Layer eine Ground-Fläche einfügen um derartige Störungen zu vermeiden. Sollte das nicht die Lösung bringen würde ich optional schon Sockel für die Rs323 Treiberbausteine einbauen um die Datenübertragung so dann zu sichern.
DerEchteBenedikt schrieb: > Einen so wirklichen Schaltplan habe ich noch nicht, aber ich bin auch > gerade dabei ein Shield zu designen. Hier würde ich sowohl in Top & auch > Bottom Layer eine Ground-Fläche einfügen um derartige Störungen zu > vermeiden. Ich bin zu 99% sicher, dass das nicht dein Problem ist. Jetzt miss doch erst mal die Signale mit dem Oszilloskop. Ich wette, dass irgenwo Masse nicht richtig verbunden ist oder dergleichen. Eine "EMV Störung" bei einer 15cm UART-Leitung klingt nicht besonderes plausiebl.
Foto vom Aufbau würde helfen. Was für eine Datenrate? Datenverlust nur im Zeitpunkt des Einsteckens?
DerEchteBenedikt schrieb: > Hi, danke schonmal für die vielen Antworten. Die Antwort oben drüber war > nicht ich.. Ok dann nehme ich meine Anschuldigung zurück :)
my2ct schrieb: > Wenn die EMV gegeben ist, sich elektromagnetisch also alles verträgt, > kann es nicht zu Störungen kommen. Auch das ist nicht korrekt. EMV ist die Beziehung zwischen zwei Geräten. Es gibt auch außerhalb der EMV Ursachen für Störungen. Signalpegel, Reflexionen usw. Von daher ist die Frage prinzipiell korrekt, ob es sich hier um ein EMV relevantes Problem handelt. Wie aber bereits mehrfach angemerkt wurde, sollten erstmal die internen Vorgänge untersucht (gemessen) werden.
Angehängte Dateien:
-
IMG_4287.jpg
230 KB
Mein derzeitiger Aufbau ist angehängt. Versorgt wird alles im Moment über einen USB HUB, der am Laptop angeschlossen ist, von daher sollte eine gemeinsame Masse ja gewährleistet sein oder? Datenrate sind 115200 Bit/s und die Fehler treten nicht nur beim Einstecken auf.
Messen werde ich jetzt dann, aber wie messe ich richtig, sodass ich Fehler erkennen kann? Bei 1024 (bzw 3072) Byte Daten pro Übertragung sehe ich doch kein Land am Osziloskop oder?
Am besten du lässt dir von einem Hardware-Kollegen mal zeigen wie man mit einem Oszilloskop mist. Es geht um die prinzipielle Signalform und nicht um Bits oder Bytes. Das kann man sich danach anschauen. Sender und Empfänger sind zu unterscheiden und die Wahl des Messpunktes ist hier entscheidend. Fang nicht an hier mit den Masseklemmzangen des Tastkopfes zu messen und den irgendwo nen Meter entfernt anzustecken.
Vermutung, da ich nichts genaues in dem Kabelverschlag erkenne: Dem Signal ist Masseweg viel zu lang. Die aufgezogene Schleife über den langen Masseweg sammelt alles ein. Verbinde mal alle Boards auf kurzem Weg mit GND.
DerEchteBenedikt schrieb: > Messen werde ich jetzt dann, aber wie messe ich richtig, sodass ich > Fehler erkennen kann? Bei 1024 (bzw 3072) Byte Daten pro Übertragung > sehe ich doch kein Land am Osziloskop oder? Mach halt ein Augendiagramm. Triggere auf beide Flanken, stell die Zeitbasis so ein, dass genau 1 Bit auf den Schirm passt. Dann schaltest du "Persist" oder wie auch immer das bei deinem Scope heißt ein und lässt das ein bischen rennen. Da sollte dann so ein Viereck zu sehen sein. Man kann dann ganz gut erkennen, wie Flanken und Pegel aussehen, und ob es Glitches gibt oder dergleichen. Der Aufbau sieht mir übrigens stark nach einem Masseproblem aus. Mehrere PC über die UART verbunden oder dergleichen. Bei so vielen USB-Kabeln kann das gar nicht sauber sein.
Wackelkontakt beim Stecken der Leitungen ist ausgeschlossen? Eingefangenen EM Mist kann ich mir da jetzt nicht wirklich als Ursache vorstellen, GND scheint auch vorhanden und mitgeführt zu sein, und 115200 bps ist langsam genug dass es bei TTL Signalisierung über die 15cm keine Probleme geben dürfte.
DerEchteBenedikt schrieb: > Prinzipiell funktioniert mein Aufbau so, dass über einen Master an 3 > Slaves jeweils 1024 byte gesendet werden und danach ein Enable Signal > kommt, sodass die Slaves die Daten mit minimaler Verzögerung an ihre > Treiberbausteine geben können. Klingt für mich als würdest du mehrere UART Ausgänge aufeinanderschalten? Mach doch mal ne Prinzipskizze.
Angehängte Dateien:
-
IMG_4291.jpg
230 KB -
IMG_4293.jpg
230 KB -
IMG_4295.jpg
240 KB -
Better_SDIO_UART_Signals.JPG
140 KB
Also ich hab mich jetzt ein bisschen mit dem Oszi beschäftigt, musst aber ganz normal mit den Messspitzen messen und habe GND direkt am Empfängerboard angeschlossen & den RX vom Empfänger gemessen. Die ersten beiden Bilder(4291 & 4293) wurden mit der USB Spannungsversorgung versorgt und die GND-Leitungen von jedem Board extra nocheinmal zusammen geschlossen. Hier scheinen mir die Peaks eher zufällig zu kommen. Danach habe ich den ganzen Spaß mit dem Labornetzteil versorgt (4295) und eine Sache ist mir aufgefallen und zwar, dass die Logikpegel um 1,2V höher sind, als bei der USB-Versorgung. Eine Prinzipskizze kann ich in Form eines LogicAnalyzer Diagramms geben. Es werden erst nacheinander die Daten geschickt und dann wie gesagt über einen Enable die Daten an die Treiber weiter gegeben.
Also wenn ich jetzt 1&1 richtig zusammen zählen kann zieht meine gesamte Schaltung zu viel Strom, dass der Laptop sie nicht mehr richtig versorgen kann. Deswegen habe ich zu niedrige Pegel und verliere bytes? Ich würde jetzt im nächsten Schritt die gesamte Schaltung über das Labornetzteil versorgen & schauen ob es dann funktioniert.
Edit zu oben: Es gehen anscheinend immer noch Daten verloren und wenn man an den Verbindern ruckelt funktioniert es manchmal wieder, nachdem es sich "aufgehängt" hat.
DerEchteBenedikt schrieb: > Also wenn ich jetzt 1&1 richtig zusammen zählen kann zieht meine gesamte > Schaltung zu viel Strom, dass der Laptop sie nicht mehr richtig > versorgen kann. Deswegen habe ich zu niedrige Pegel und verliere bytes? Auch das kann man messen. Wenn Sender und Empfänger in zulässigen Spannungsbereich arbeiten (und vor allem im gleichen), dann sollte das funktionieren. Die Pegel sehen gut aus. Auch wenn 3,0 V etwas untypisch sind, das kann viele Ursachen haben. Die Spikes auf den Signalen sind jetzt zwar nicht der Brüller, machen aber vorerst nicht solche Probleme. Begründbar sind die mit der Messmethode und dem Kabelaufbau. Mit Prinzipskizze wurde meiner Meinung nach gemeint, was du mit welchen Signalen verbindest. Also ein einfacher Schaltplan. Jede TX-RX-Verbindung darf nur eine Direktverbindung sein oder Bedarf entsprechende Entkopplung, sonst treiben Signale aufeinander. Das war damit gemeint.
DerEchteBenedikt schrieb: > IMG_4291.jpg > IMG_4293.jpg > IMG_4295.jpg Hast du das USB-Logo links unter dem Bildschirm des Oszis gesehen? Die Asnchlüsse sind bestimmt nicht zum Spaß da, sondern erlauben, Screen Shots zu machen, ohne das sich die halbe Raumbeleuchtung im Bildschirm spiegelt. Wenn schon Smart Phone - dann Raumbeleuchtung und Blitzfunktion aus.
Angehängte Dateien:
-
Prinzipskizze.JPG
33 KB
Phototip schrieb: > Hast du das USB-Logo links unter dem Bildschirm des Oszis gesehen? > > Die Asnchlüsse sind bestimmt nicht zum Spaß da, sondern erlauben, Screen > Shots zu machen, ohne das sich die halbe Raumbeleuchtung im Bildschirm > spiegelt. > > Wenn schon Smart Phone - dann Raumbeleuchtung und Blitzfunktion aus. Ich weiß prinzipiell wie man ein Oszi bedient, habe aber leider kurzer Hand keinen USB Stick gehabt. Ist das im Anhang mit Prinzipskizze gemeint? Und was ist mit "Signale aufeinander Treiben" gemeint?
DerEchteBenedikt schrieb: > Ist das im Anhang mit Prinzipskizze gemeint? > Und was ist mit "Signale aufeinander Treiben" gemeint? Es gibt Leute die meinen UART wäre ein Bus und man könne mehrere Teilnehmer drauflegen. Dann treiben zwei TX-Ports z.B. auf einen RX. Je nach Zustand treiben dann zwei TX aufeinander. Was ist da so schwer zu verstehen. Stell dir vor das eine TX sendet 0 (es "verbindet" den Ausgang mit GND) das andere sendet 1 ("verbindet" den Ausgang mit VCC) --> Dann knallt es.
Msd schrieb: > Es gibt Leute die meinen UART wäre ein Bus und man könne mehrere > Teilnehmer drauflegen. Dann treiben zwei TX-Ports z.B. auf einen RX. Je > nach Zustand treiben dann zwei TX aufeinander. > > Was ist da so schwer zu verstehen. > > Stell dir vor das eine TX sendet 0 (es "verbindet" den Ausgang mit GND) > das andere sendet 1 ("verbindet" den Ausgang mit VCC) --> Dann knallt > es. Ach so, ja das war mir ja klar. Hab ich ja auch so umgesetzt... Konnte nur mit dem Begriff "aufeinander treiben" nicht so wirklich was anfangen.
1. Laut IMG4295 hast du 4,38V. Der STM läuft aber nominal mit 3,3V (Max 3.6). Sieht für mich aus, als würdest du 3,3V und 5V mischen oder was komplett falsches machen. 2. Da du ja eh einen Logic Analyzer hast, könntest du parallel mit messen und überprüfen ob auch hier die Zeichen verloren gehen. 3. Für mich sieht es nach einem Fehler im Hardware Aufbau aus oder deine Software kann keine 3 USARTs gleichzeitig verarbeiten, aber EMV ist es garantiert nicht! mfg
DerEchteBenedikt schrieb: > Also ich hab mich jetzt ein bisschen mit dem Oszi beschäftigt, musst > aber ganz normal mit den Messspitzen messen und habe GND direkt am > Empfängerboard angeschlossen & den RX vom Empfänger gemessen. > Die ersten beiden Bilder(4291 & 4293) wurden mit der USB > Spannungsversorgung versorgt und die GND-Leitungen von jedem Board extra > nocheinmal zusammen geschlossen. Hier scheinen mir die Peaks eher > zufällig zu kommen. > Danach habe ich den ganzen Spaß mit dem Labornetzteil versorgt (4295) > und eine Sache ist mir aufgefallen und zwar, dass die Logikpegel um 1,2V > höher sind, als bei der USB-Versorgung. > > Eine Prinzipskizze kann ich in Form eines LogicAnalyzer Diagramms geben. > Es werden erst nacheinander die Daten geschickt und dann wie gesagt über > einen Enable die Daten an die Treiber weiter gegeben. Da hats was mit den Pegeln. Auf Bild 1 und 2 sind es 3V, auf Bild 3 4,4V. Die 4,4V riechen stark nach 5V auf nicht 5V-Tolerantes Ziel getrieben. Jetzt wärs an der Zeit, ein Blockschaltbild inklusive Versorgung zu liefern.
Msd schrieb: > Wenn Sender und Empfänger in zulässigen Spannungsbereich arbeiten (und > vor allem im gleichen), dann sollte das funktionieren. Hast du das verstanden bzw. mal geprüft?
Quick and dirty-Methode. UART-Verbindung aller Boards trennen und mal überall Daten auf TX raushauen. Pegel messen. Sollte überall gleich sein. Ich nehme mal an die Boards die du da verknüpperst funktionieren in sich als Einzelteilnehmer oder können da prinzipiell auch Fehler drauf sein? Auf deutsch: Habt ihr das entwickelt und gefertigt oder zugekauft?
soso... schrieb: > Da hats was mit den Pegeln. Auf Bild 1 und 2 sind es 3V, auf Bild 3 > 4,4V. > > Die 4,4V riechen stark nach 5V auf nicht 5V-Tolerantes Ziel getrieben. Msd schrieb: > Msd schrieb: >> Wenn Sender und Empfänger in zulässigen Spannungsbereich arbeiten (und >> vor allem im gleichen), dann sollte das funktionieren. > > Hast du das verstanden bzw. mal geprüft? Die TX/RX Pins des Slaves sind 5V Tolerant. (Datenblatt : "The first 14 pins, those that comprise the shortened Arduino Uno footprint, are 5V tolerant. This means that you can safely attach any of your 5V Arduino shields.." Tx/RX sind D0 und D1). Msd schrieb: > Auf deutsch: Habt ihr das entwickelt und gefertigt oder zugekauft? Die Boards sind alle zugekauft. STM32 und Papilio Duo. Kann es auch sein, dass die Baudrate bei beiden durch unterschiedliche Oszilatoren unterschiedlich ist und somit am Ende Bits verloren gehen?
>Kann es auch sein, dass die Baudrate bei beiden durch unterschiedliche >Oszilatoren unterschiedlich ist und somit am Ende Bits verloren gehen? Nicht raten, lernen. Schau Dir doch mal Grundlagen der UART-Übertragung an. Leicht differierende Baudraten werden toleriert.
DerEchteBenedikt schrieb: > Die TX/RX Pins des Slaves sind 5V Tolerant. (Datenblatt : "The first 14 > pins, those that comprise the shortened Arduino Uno footprint, are 5V > tolerant. This means that you can safely attach any of your 5V Arduino > shields.." Tx/RX sind D0 und D1). ist denn auch sichergestellt, dass der 3,3V Treiber vom 5V-Empfänger verstanden wird? Gugg es dir ganz konkret an und zwar für beide Richtungen. Im Datenblatt (operational conditions blablabla). Welche IO-Spannung wird verwendet? Also mit welcher Spannung sendet TX, mit welcher IO-Spannung emfpängt RX. Liegen die zulässigen VIL/VOL VIH/VOH. Wieso liegen die Signale mal auf 3,3V mal auf 5V. Nur weil eine der Senken auch 5V-Tolerant ist, heißt das nicht, dass die andere Seite die geringere Spannung auch versteht.
Msd schrieb: > Liegen die zulässigen VIL/VOL VIH/VOH. > > Wieso liegen die Signale mal auf 3,3V mal auf 5V. > > Nur weil eine der Senken auch 5V-Tolerant ist, heißt das nicht, dass die > andere Seite die geringere Spannung auch versteht. Okay soweit verstanden. Also der Master (Tx only) hat eine VOH von 2.7v-3.6v Die Slaves sind an 5V Toleranten Pins mit dem Master verbunden, das eigentliche LogicLevel des Papilio Duo ist aber 3,3V. Die 5V Toleranz wird über einen limitierenden Vorwiderstand sichergestellt. Was passiert denn wenn ich die 3,3V über den Vorwiderstand gebe? Fehlt dann Spannung zur genauen Level Unterscheidung? Sollte das der Fall sein müsst ich einen Level Shifter zwischen schalten richtig?
Wenn der Master (grüne Platine, stm32f429 discovery?) mit 3V3 arbeitet
und die Slaves (rote Platinen, Papilio Duo) mit 3V3, wo kommen dann die
>4V her?
DerEchteBenedikt schrieb: > Okay soweit verstanden. Also der Master (Tx only) hat eine VOH von > 2.7v-3.6v Die Slaves sind an 5V Toleranten Pins mit dem Master > verbunden, das eigentliche LogicLevel des Papilio Duo ist aber 3,3V. Die > 5V Toleranz wird über einen limitierenden Vorwiderstand sichergestellt. Deine Arbeitsweise ist schon irgendwie verwirrend. Du redest von 5V-Tolleranz, wobei dann doch wieder beides 3,3 V ist. Ich habe geraten dir für beide Richtungen anzuschauen welche Spannungslevel die Ausgänge und Eingänge haben. Dann schaust du dir den Master an aber den Slave wieder nicht!?! Wenn du mit unterschiedlichen Spannungen fährst musst du sicherstellen, dass am Empfänger eine ausreichend hohe Spannung anliegt, damit high erkannt werden kann. Hast du das nun endlich mal geprüft?? Nochmal: Welche VCC nutzen die Teilnehmer? Undzwar nicht nur einer sondern alle.
Robert S. schrieb: > Wenn der Master (grüne Platine, stm32f429 discovery?) mit 3V3 arbeitet > und die Slaves (rote Platinen, Papilio Duo) mit 3V3, wo kommen dann die >>4V her? Hab ich mich auch gefragt und folgendes gemessen: STM32F4 an USB : VOH = 2,91V STM32F4 an 5V Labornetzteil: VOH = 2,92V Papilio DUO an USB: VOH = 3,5V Papilio DUO an 5V Labornetzteil : VOH = 3,5V STM32F4 an Papilio DUO beide an Labornetzteil: VOH = 3V STM32F4 TX an Papilio DUO nur STM32 angeschlossen, GND aber verbunden: VOH = 2V Ich konnte in keinem Fall die 4V reproduzieren..
DerEchteBenedikt schrieb: > Papilio DUO an USB: VOH = 3,5V > Papilio DUO an 5V Labornetzteil : VOH = 3,5V DerEchteBenedikt schrieb: > STM32F4 TX an Papilio DUO nur STM32 angeschlossen, GND aber verbunden: > VOH = 2V Aber das alles lässt dich nicht wundern? Du musst dir schonmal den Schaltplan anschauen um zu verstehen wo solch kruden Spannungen herkommen. 2 V sehen so aus wie 3,3V-Clamping-Voltage. Hast du TX an ein nicht versorgtes Board angelegt?
Msd schrieb: > Ich habe geraten dir für beide Richtungen anzuschauen welche > Spannungslevel die Ausgänge und Eingänge haben. Dann schaust du dir den > Master an aber den Slave wieder nicht!?! > Für den Papilio DUO gibt es kein wirkliches Datenblatt, auf ihm ist der Spartan 6 FPGA, welcher eine "Multi-voltage, multi-standard SelectIO" hat. Zwischen 1.2V bis 3.3V sind hier LogicLevel. Ich habe den FPGA selber, aber nicht programmiert, da ich nur die Datenübertragung sicher stellen soll und nur mit dem auf dem FPGA implementierten Softcore arbeite. > Wenn du mit unterschiedlichen Spannungen fährst musst du sicherstellen, > dass am Empfänger eine ausreichend hohe Spannung anliegt, damit high > erkannt werden kann. Hast du das nun endlich mal geprüft?? Wie soll ich das Überprüfen? Ich hatte an sowas gedacht : (if(pin == High){tu was messbares}) > Nochmal: Welche VCC nutzen die Teilnehmer? Undzwar nicht nur einer > sondern alle. Alle Teilnehmer werden mit 5V versorgt.
Msd schrieb: > Aber das alles lässt dich nicht wundern? Natürlich wundert mich das, aber kann leider keine Schlüsse daraus ziehen. > Du musst dir schonmal den Schaltplan anschauen um zu verstehen wo solch > kruden Spannungen herkommen. > > 2 V sehen so aus wie 3,3V-Clamping-Voltage. Hast du TX an ein nicht > versorgtes Board angelegt? Ich dachte erst, dass die 4V von der Clamping Diode kommen würden, deswegen habe ich auch getestet wie es ausschaut, wenn ich den TX and ein versorgtes und an ein nicht versorgtes Board anlege. GND war aber jeweils verbunden.
DerEchteBenedikt schrieb: > Wie soll ich das Überprüfen? Ich hatte an sowas gedacht : (if(pin == > High){tu was messbares}) Mit dem verdammten Datenblatt des Controllers den du da verwendest. Ich selber habe noch nie Arduino, Papillodingsbums genutzt, die Vorgehensweise ist aber immer die selbe wenn man zwei Interfaces mit einander verbindet. Man überprüft ob die IO-Level zusammen passen. Und nein das macht man nicht in Software, sondern in dem man das Datenblatt und den Schaltplan ließt oder andere Quellen hat die einem bestätigen, dass man diese beiden Boards mit einander verbinden kann. DerEchteBenedikt schrieb: > Für den Papilio DUO gibt es kein wirkliches Datenblatt, auf ihm ist der > Spartan 6 FPGA, welcher eine "Multi-voltage, multi-standard SelectIO" > hat. Zwischen 1.2V bis 3.3V sind hier LogicLevel. Es geht doch nicht um das Datenblatt des blöden Boards, sondern der relevanten Elektronik! DerEchteBenedikt schrieb: > Alle Teilnehmer werden mit 5V versorgt. Ok. Tut mir leid, aber du hast nichts von dem verstanden was wir hier geschrieben haben. Es geht hier im die IO-Spannung des Treibers im Controller. Also den Spannungspegel der Signale und nicht irgendeiner blöden Versorgungsspannung des Gesamtboards. Hast du schonmal mit Elektronik zu tun gehabt? Du kommst eher aus der Software-Ecke oder? Am besten du gehst mit der Problematik mal zu einem Kollegen, der dir die Problematik erklärt. Versteh mich nicht falsch. Ich behaupte nicht, dass die IO-Spannungen falsch sind oder nicht zusammen passen. Aber das zu überprüfen sehe ich als grundlegende Aufgabe. Solange das nicht erfolgt ist, suchst du im Nebel.
DerEchteBenedikt schrieb: > TX and > ein versorgtes und an ein nicht versorgtes Board anlege Wenn du TX an ein nicht versorgtes Board legts, ballerst du die Clamping-Dioden auf Dauer kaputt. Schlauer bist du dann auch nicht.
Msd schrieb: > Es geht doch nicht um das Datenblatt des blöden Boards, sondern der > relevanten Elektronik! Aber die relevante Elektronik ist doch der Spartan 6 FPGA? Er muss doch die Daten verarbeiten können?
DerEchteBenedikt schrieb: > Aber die relevante Elektronik ist doch der Spartan 6 FPGA? Er muss doch > die Daten verarbeiten können? Richtig. Also Datenblatt des Spartan 6 FPGA nutzen.
Ich hatte dir ja eine Quick-and-Dirty-Methode beschrieben damit du nicht irgendwelche Datenblätter wälzen muss. Die hast du aber auch nur zur Hälfte durchgezogen und dann irgendwas anderes gemacht.
Msd schrieb: > Ich hatte dir ja eine Quick-and-Dirty-Methode beschrieben damit du nicht > irgendwelche Datenblätter wälzen muss. Die hast du aber auch nur zur > Hälfte durchgezogen und dann irgendwas anderes gemacht DerEchteBenedikt schrieb: > STM32F4 an USB : VOH = 2,91V > STM32F4 an 5V Labornetzteil: VOH = 2,92V > > Papilio DUO an USB: VOH = 3,5V > Papilio DUO an 5V Labornetzteil : VOH = 3,5V Hier habe ich jeweils über den TX Daten rausgesendet.
Und im Datenblatt des Spartan 6 steht: Msd schrieb: >> Spartan 6 FPGA, welcher eine "Multi-voltage, multi-standard SelectIO" >> hat. Zwischen 1.2V bis 3.3V sind hier LogicLevel.
DerEchteBenedikt schrieb: > Und im Datenblatt des Spartan 6 steht: > Msd schrieb: >>> Spartan 6 FPGA, welcher eine "Multi-voltage, multi-standard SelectIO" >>> hat. Zwischen 1.2V bis 3.3V sind hier LogicLevel. Ja. Mach mal.
Angehängte Dateien:
-
LL-STM32F4_EXT.JPG
96 KB -
LL-STM32F4_EXT_ohne_Papilio.JPG
91 KB -
LL-Papilio_EXT_ohne_STM.JPG
90 KB -
LL-Papilio_EXT_mit_STM.JPG
59 KB
Ich habe jetzt mit dem Logic Analyzer mal die Pegel mitgemessen. Wenn ich den TX vom STM beobachte merke ich keine signfikate Änderung der Pegel, egal ob das Papilio angeschlossen ist, oder auch nicht. Mache ich das selbe aber mit dem Papilio, sinkt der Pegel (trotz gemeinsamer Masse) wenn der STM angeschlossen ist auf 0,1V High und 0V low..woran liegt das?
Zusatz: Ich habe beides sowohl an USB als auch an einer externen Spannungsquelle probiert, das Ergebnis bleibt das gleiche. Genauso zu beiden Massen hin. Das selber erstellte Shield hat auch nichts geholfen..
1. Wieso sehen die Signale nun völlig anders aus als in den ersten Bildern? Dies sind doch völlig rundgeschliffen und erreichen nicht einmal 3,3 V. Hängt da etwa so eine riesen Kapazität dran? Allein durch den Fädelaufbau ist das nicht zu erklären, bei den zeitlichen Dimensionen. Was wurde also geändert? 2. Statt ins Datenblatt zu gucken und/oder die IO-Spannungsebene am Controller zu messen, um festzustellen warum du 3,0 statt 3,3 V hast, wirst du lieber mit dem Marketing-Geblubber aus dem Datenblatt umher: "Multi-voltage, multi-standard SelectIO" >>> hat. Zwischen 1.2V bis 3.3V sind hier LogicLevel" Das ist doch eine völlig schwachsinnige Aussage. Wem soll die helfen? Schau verdammt nochmal in die Specs und nicht auf Seite Eins. Kann 1,2 bis 3,3V. Na toll und welche IO-Spannung wird nun verwendet?
DerEchteBenedikt schrieb: > Das selber erstellte Shield hat auch nichts geholfen.. Das ist auch bei weitem nicht dein Problem.
DerEchteBenedikt schrieb: > wenn der STM angeschlossen ist auf 0,1V High und 0V > low..woran liegt das Ist auf dem STM das Signal als Output low konfiguriert? Ist das STM ausgeschaltet?
Msd schrieb: > 1. Wieso sehen die Signale nun völlig anders aus als in den ersten > Bildern? Dies sind doch völlig rundgeschliffen und erreichen nicht > einmal 3,3 V. Hängt da etwa so eine riesen Kapazität dran? Allein durch > den Fädelaufbau ist das nicht zu erklären, bei den zeitlichen > Dimensionen. Was wurde also geändert? Ich habe rein gar nichts am Aufbau geändert, nur im Programm den TX des Papilio Boards programmiert und an den RX des STMs geschlossen. Deswegen würde ich das auf den Logic Analyzer zurück schließen. Msd schrieb: > 2. Statt ins Datenblatt zu gucken und/oder die IO-Spannungsebene am > Controller zu messen, um festzustellen warum du 3,0 statt 3,3 V hast, > wirst du lieber mit dem Marketing-Geblubber aus dem Datenblatt umher: > "Multi-voltage, multi-standard SelectIO" >>> hat. Zwischen 1.2V bis 3.3V > sind hier LogicLevel" Das steht nicht auf Seite 1. Ich hab die Boards nicht konfiguriert..und weiß auch nicht wie, da ich nur die auf Arduino basierte Oberfläche verwenden soll/kann. Setze ich aber anstatt dem STM32 ein Papilio Board ein taucht dieselbe Problemtik auf. Msd schrieb: > Ist auf dem STM das Signal als Output low konfiguriert? Ist das STM > ausgeschaltet? Der STm ist angeschaltet und das Signal auf den definierten RX-PIN gelegt.
DerEchteBenedikt schrieb: > Msd schrieb: >> 2. Statt ins Datenblatt zu gucken und/oder die IO-Spannungsebene am >> Controller zu messen, um festzustellen warum du 3,0 statt 3,3 V hast, >> wirst du lieber mit dem Marketing-Geblubber aus dem Datenblatt umher: >> "Multi-voltage, multi-standard SelectIO" >>> hat. Zwischen 1.2V bis 3.3V >> sind hier LogicLevel" > > Das steht nicht auf Seite 1. Ich hab die Boards nicht konfiguriert..und > weiß auch nicht wie, da ich nur die auf Arduino basierte Oberfläche > verwenden soll/kann. Setze ich aber anstatt dem STM32 ein Papilio Board > ein taucht dieselbe Problematik auf. Ich habe auch nicht gesagt, dass etwas konfiguriert werden soll! Herausbekommen, welche IO-Spannung das Pin verwendet! Mit Datenblatt und Schaltplan. Noch einmal gehe ich da nicht drauf ein. DerEchteBenedikt schrieb: > Der STm ist angeschaltet und das Signal auf den definierten RX-PIN > gelegt. Ok du verwendest das richtige Pin, aber ist das Pin auch als RX konfiguriert? Meistens bieten Controller die Möglichkeit verschiedene Funktionen auf ein Pin zu legen.
DerEchteBenedikt schrieb: > Der STM ist angeschaltet und das Signal auf den definierten RX-PIN > gelegt In deinem Bild weiter oben ist der STM aber Tx? Beitrag "Re: EMV von Datenleitungen?" Signal an Rx gelegt hört sich irgendwie komisch an. Rx wäre ein Eingang und somit Hochohmig. Kann es sein das du irgendwo noch eine Problem mit der Definition von Rx und Tx und deren Überkreuzung hast so das du eventuell zwei Tx-Ausgänge gegeneinander arbeiten lässt? Das würde auch erklären warum das Low des einen das Hi des anderen in den Keller zieht.
1) Wurden Softwareprobleme komplett ausgeschlossen? 2) Hat sich das jemand mit Ahnung von Elektrik und HW das vor Ort mal angeschaut?
Noch mal von Vorne schrieb: > 1) Wurden Softwareprobleme komplett ausgeschlossen? > 2) Hat sich das jemand mit Ahnung von Elektrik und HW das vor Ort mal > angeschaut? Wurde ja nun schon mehrmals gefragt. So richtig wirkt das hier aber nicht.
Felix F. schrieb: > Für mich sieht es nach einem Fehler im Hardware Aufbau aus oder deine > Software kann keine 3 USARTs gleichzeitig verarbeiten, aber EMV ist es > garantiert nicht! > > mfg Werden in der Software die Fehlerflags, wie z.B. Rahmenfehler, ausgewertet? Ich für die Tests nur einen UART gleichzeitig senden lassen. Tritt dann der Datenverlust immer noch auf. Werden auf den beiden anderen "stillen Stecken" Geisterzeichen oder UART Interrupts empfangen. Geisterzeichen entstehen, wenn Störungen Startbis vortäuschen.
Noch mal von Vorne schrieb: > 1) Wurden Softwareprobleme komplett ausgeschlossen? Wenn Zeichen verloren gehen, dann liegt es meisten an der UART Software. Ich hoffen der Empfang ist Interrupt gesteuert und nicht gepollt. Ich würde über zwei Schnittstellen das System stressen und die dritte Schnittstelle genau beobachten, ob z.B Empfangsinterrupts verloren gehen.
GEKU schrieb: > Wenn Zeichen verloren gehen, dann liegt es meisten an der UART > Software. > > Ich hoffen der Empfang ist Interrupt gesteuert und nicht gepollt. > > Ich würde über zwei Schnittstellen das System stressen und die dritte > Schnittstelle genau beobachten, ob z.B Empfangsinterrupts verloren > gehen Der Junge hat hier ganz andere Probleme, als Software. Ist ja an den Bildern zu erkennen.
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.