Hallo zusammen, ich setze bei einem Projekt bereits erfolgreich zwei Leitungstransceiver SN65HVD1780P als SMD Variante ein bei 9600 Baud und ca. 6 Meter Kabel dazwischen. Nun dachte ich daran, da der IC gut funktionierte im ersten Projekt, diesen auch für ein weitere Projekt einzusetzen. Gesagt getan aber hier funktioniert es gar nicht. Der Aufbau ist wie folgt: ATXmega - SN65 - 10 cm Kabel (Soll später ca. 30 cm Kabel sein und über einen Schleifring gehen) - SN65 - FT232. Nun kann ich den ATXmega direkt mit dem FT232 verbinden und alles geht. Sobald die SN65 dazwischen sitzen, muss ich auf 2800 Baud runter gehen und nach jedem gesendeten Zeichen 10ms Pause einlegen. Auf der A-Seite des SN65 gehen 35K richtig + und von der B-Seite Richtung GND. Das System läuft auf 3,3V. Gibt es für diese Bausteine eine Mindestkabellänge damit das überhaupt funktioniert? Würde mich zwar sehr wundern aber man lernt nie aus. Sollte man dann mit Serienwiderständen oder Kondensatoren ein längeres Kabel simulieren? Danke für eure Antworten im voraus. BG Peter
@Peter (Gast) >Nun kann ich den ATXmega direkt mit dem FT232 verbinden und alles geht. >Sobald die SN65 dazwischen sitzen, muss ich auf 2800 Baud runter gehen >und nach jedem gesendeten Zeichen 10ms Pause einlegen. Dann stimmt was nicht. >Auf der A-Seite >des SN65 gehen 35K richtig + und von der B-Seite Richtung GND. Das >System läuft auf 3,3V. Wie sehen die Signale mit dem Oszi aus? >Gibt es für diese Bausteine eine Mindestkabellänge damit das überhaupt >funktioniert? Nein. >Sollte man dann mit Serienwiderständen oder Kondensatoren ein längeres >Kabel simulieren? Nein. Klingt nach nicht angeschlossenem Pin, Masse oder ähnlichem.
Mit dem Oszi habe ich noch nicht nachgesehen. Wenn ich jedoch eine Zeichenkette mit 10 Zeichen sende und die SN65 dazwischen sitzen, kommen nur die ersten 4 Zeichen an. Mit 10ms zwischen jedem Zeichen, kommen alle an.
Schnapp Dir ein Scope und schau nach. Hardwarefehler findest Du nicht mit Software.
Christian K. schrieb: > Schnapp Dir ein Scope und schau nach. Hardwarefehler findest Du > nicht > mit Software. Wie sollten die Flanken aussehen? Wann sind mögliche Probleme und Lösungen?
@Peter (Gast) >Wie sollten die Flanken aussehen? Ja wie wohl? Rund und wellig oder eher eckig und knackig? >Wann sind mögliche Probleme und >Lösungen? Sollen wir jetzt den großen Katalog aufschreiben? Die Digitalsignale sollten alle sehr kurz Anstiegszeiten von vielleicht 10-20ns haben und auch sonst keine komischen Dinge tun.
Falk B. schrieb: > @Peter (Gast) > >>Wie sollten die Flanken aussehen? > > Ja wie wohl? Rund und wellig oder eher eckig und knackig? > >>Wann sind mögliche Probleme und >>Lösungen? > > Sollen wir jetzt den großen Katalog aufschreiben? > > Die Digitalsignale sollten alle sehr kurz Anstiegszeiten von vielleicht > 10-20ns haben und auch sonst keine komischen Dinge tun. Schon gut mir ging es nur darum direkt zu wissen wohin zu sehen ist und was ggf. sofort probiert werden kann. Könnte der FT232 ein Problem sein?
Peter schrieb: > Könnte der FT232 ein Problem sein? Kann sein. Oder auch sonstwas. Aber um einen Fehler zu lokalisieren musst du einfach die Signalkette auftrennen und jede Komponente für sich selbst testen...
Dann ist es so, dass wenn ich die SN65 weg lasse und MCU und FT232 direkt verbinde, dass es geht.
Peter schrieb: > Dann ist es so, dass wenn ich die SN65 weg lasse und MCU und FT232 > direkt verbinde, dass es geht. Dann kannst du die SN Pegelwandler ja einfach mal statisch betreiben und die Pegel vorn und hinten und in der Mitte messen. Und dann die gemessenen Werte mit dem Datenblatt vergleichen... Die Masse hast du da aber auch mit den Pegelwandlern verbunden? Vom erstem bis zum letzten Busteilnehmer?
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Peter schrieb: >> Dann ist es so, dass wenn ich die SN65 weg lasse und MCU und FT232 >> direkt verbinde, dass es geht. > Dann kannst du die SN Pegelwandler ja einfach mal statisch betreiben und > die Pegel vorn und hinten und in der Mitte messen. Und dann die > gemessenen Werte mit dem Datenblatt vergleichen... Wird gemacht. Ich hoffe die 3,3V sind nicht zu wenig...
Lothar M. schrieb: > Peter schrieb: >> Ich hoffe die 3,3V sind nicht zu wenig... > Was steht denn dazu im Datenblatt? Minimum 3,15 Volt Minimum. Also i.O.
Peter schrieb: > Auf der A-Seite des SN65 gehen 35K richtig + und von der B-Seite > Richtung GND. Was heißt das? Zeig Deinen Schaltplan.
Können auch Timingprobleme der Software sein. Nach dem Enablen des DE nicht lange genug mit der Übertragung gewartet oder zu früh disabled beispielsweise. Läßt sich aber ausschließen, wenn testweise nur in einer Richtung gesendet und DE permanent aktiviert wird.
Icke ®. schrieb: > Können auch Timingprobleme der Software sein. Nach dem Enablen des > DE > nicht lange genug mit der Übertragung gewartet oder zu früh disabled > beispielsweise. Läßt sich aber ausschließen, wenn testweise nur in einer > Richtung gesendet und DE permanent aktiviert wird. Das war es. Habe die Wartezeiten verlängert und es geht. Danke!
@ Peter (Gast)
>Das war es. Habe die Wartezeiten verlängert und es geht. Danke!
Mit einem Oszi oder wenigstens Logic Analyer hätte man das in Minuten
gesehen. Außerdem kann man für das Abschalten des Senders bzw. dem
Umschalten auf Empfang den TXC (transmission complete) Interrupt
verwenden. Wenn der aktiv wird, ist das letzte Byte SICHER schon
rausgegangen.
Falk B. schrieb: > Die Digitalsignale sollten alle sehr kurz Anstiegszeiten von vielleicht > 10-20ns haben und auch sonst keine komischen Dinge tun. Das möchte man bei RS485 eher nicht haben, wenn es die Datenrate zulässt. Üblicherweise sieht man zu, dass die Flanken nicht zu steil sind, um Störungen zu vermeiden.
Falk B. schrieb: > Außerdem kann man für das Abschalten des Senders bzw. dem > Umschalten auf Empfang den TXC (transmission complete) Interrupt > verwenden. Wenn der aktiv wird, ist das letzte Byte SICHER schon > rausgegangen. So die Theorie. Ich hatte vor Kurzem das gleiche Problem mit einem MAX485 (bei 9600 Baud). Die letzten Zeichen einer Befehlssequenz kamen nicht beim Empfänger an, obwohl ich vor dem Abschalten des Ausgangstreibers explizit auf das TXC-Flag gewartet hatte. Ich mußte ein zusätzliches Delay von 2ms einfügen (1ms reichte nicht), damit die Übertragung sicher vollständig ablief. Aus den Datenblättern läßt sich dies nicht erklären. Möglicherweise verhält sich das verwendete Modul.. https://www.ebay.de/itm/MAX485-TTL-Schnittstelle-Modul-Adapter-RS-485-RS-485-Arduino-Raspberry-Pi-Module/162384175341?hash=item25ced9e0ed:g:~WIAAOSwJ59Z2qTm ..jedoch nicht datenblattkonform, obwohl MAX485 drauf steht. Und ja, ein Digitaloszi wäre hilfreich gewesen.
@ Icke ®. (49636b65) >> Umschalten auf Empfang den TXC (transmission complete) Interrupt >> verwenden. Wenn der aktiv wird, ist das letzte Byte SICHER schon >> rausgegangen. >So die Theorie. Und auch die Praxis, wenn gleich das kniffelig werden kann. Beitrag "Re: Problem mit Micro-SD-Karte" Beitrag "Re: Problem mit Micro-SD-Karte" >..jedoch nicht datenblattkonform, obwohl MAX485 drauf steht. Und ja, ein >Digitaloszi wäre hilfreich gewesen. Ja, aber hier reicht ein einfacher, preiswerter Logic-Analyzer.
Falk B. schrieb: > Und auch die Praxis, wenn gleich das kniffelig werden kann. > > Beitrag "Re: Problem mit Micro-SD-Karte" > > Beitrag "Re: Problem mit Micro-SD-Karte" Danke für den Tip. Muß ich mir mal in Ruhe reinziehen.
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.