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 ...
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.
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.
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.
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.
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.
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,5VDerEchteBenedikt 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 gemachtDerEchteBenedikt 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.
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:> 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.
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.
