Hallo, ich habe mit dem ft232rl folgendes Problem: Ich habe die Schaltung als USB-rs485-Converter laut Datenblatt (Abschnitt 7.2) aufgebaut, habe aber als Wandler einen max 4810 verwendet. Send-Enable des MAX4810 liegt an TXDEN und Receive-Enable an PWRON#. Ich kann von anderen Busteilnehmern etwas empfangen und kann auch was raus senden. Ok so weit. Aber folgendes Problem: Alles was ich sende wird auf dem Empfang zurückgelesen. Genau das sollte doch der ft232rl verhindern, oder nicht !?! Und was noch schlimmer ist, er empfängt nach jedem Senden ein zusätzliches Null-Byte, das niemand gesendet hat. Woher kommt das Null-Byte? Software-Problem kann ich ausschließen. Muss ich da noch etwas konfigurieren (mit FT_Prog?) ? Wer hat damit Erfahrung und kann mir einen Tipp geben? Danke!
Ma S, schrieb: > Alles was ich sende wird auf dem Empfang zurückgelesen. Genau das sollte > doch der ft232rl verhindern, oder nicht !?! Nein, das kann sogar sinnvoll sein, um Kollisionen zu erkennen. Du kannst das aber auch abklemmen, indem Du Receive-Enable des RS485-Treibers nicht an PWRON# hängst, sondern mit Send-Enable verbindest. Bei üblichen RS485-Treibern verwenden die unterschiedliche Polarität, so daß das dergestalt möglich ist. Wenn nicht, dann musst Du halt einen Inverter (74xx04) dazwischenklemmen. Der MAX4810 ist aber was ganz anderes, bist Du Dir da sicher?
Ich meinte ich hab den MAX 481 verwendet. Hatte das falsch in Erinnerung... Ich hatte zuerst so wie Du beschrieben hast, send-Enable und receive-Enable verbunden. Da der eine ja wie Du schreibst invertiert ist. Da hab ich dann auch nichts zurückbekommen, aber ich hatte auch Probleme mit dem Empfang dass verschiedene Zeichen nicht korrekt empfangen wurden. Hab es deswegen umgebaut so wie im Datenblatt des FTDI beschrieben, aber der ft232rl filtert also dann quasi nicht. Was ich trotzdem nicht verstehe, woher kommen die Null-Bytes? Die habe ich in beiden Schaltungsvariationen. Und es scheint immer so, dass die Null-Bytes immer dann auftreten, wenn der ftdi von senden nach empfangen umschaltet. Seltsam. Irgend eine Idee?
Mein "Bus" ist wie folgt aufgebaut: PC -> ft232rl -> max481 mit 120 Ohm Widerstand -> 30cm Leitung -> max481 mit 120 Ohm Widerstand -> PIC µC Scheinbar empfängt der Konverter immer ein Nullbyte, wenn einer der beiden Busteilnehmer (der PIC oder der ft232rl selbst) von Senden auf Empfangen umschaltet. Ich kann mit dem PIC den max481 von Senden auf Empfangen schalten und zurück. Ohne dass ich ein Datenbyte schicke empfängt der PC bei jedem Toggeln ein Null-Byte. Ist das Normal? Bei Watterott gibt's einen auf dem ft232rl basierenden RS485 Konverter. der hat sehr ähnliche Hardware zu meinem Aufbau. Hat den jemand, oder hat schon jemand einen ähnlichen selbst gebaut? Kennt kann das Verhalten mit den Null-Bytes jemand? Oder kann das an meinem Terminal Programm auf dem PC liegen (Terminal v1.9b by Bray unter Win7 home)?
An jedem Ende, oder? Hab ja derzeit nur zwei Partner also 2x 120 Ohm. Hab es auch schon mit anderen Konfigurationen probiert, immer das gleich Problem mit den Null-Bytes.
Das Terminal kann ich auch ausschließen. Ein kleines C# Programm das Daten vom PIC empfängt liefert die NULL-Bytes auch.
Wie's sich's anhört, ist der Ruhepegel Deines Busses nicht definiert. Daher werden Umschaltstörungen von den UARTS als Startbit interpretiert und Du empfängst Nullbytes. Lies Dir mal ein paar Application Notes zum Thema RS485 durch: http://www.national.com/apnotes/RS-485.html (hier speziell: http://www.national.com/an/AN/AN-1057.pdf)
Glaube nicht dass es daran liegt. Hatte es sowohl mit 120 Ohm abschluss, als auch zusätzlich mit jeweils 10 k gegen vcc und gnd probiert. Problem ist das gleiche....
Ma S, schrieb: > Was ich trotzdem nicht verstehe, woher kommen die Null-Bytes? Die habe > ich in beiden Schaltungsvariationen. Und es scheint immer so, dass die > Null-Bytes immer dann auftreten, wenn der ftdi von senden nach empfangen > umschaltet. > > Seltsam. Irgend eine Idee? Hast du ein Oszi? Wenn ja mal die Spannungspegel an den TX unbd RX Pins anschauen.
Ich habe jetzt mal ein paar Versuche und ein paar Aufzeichnungen mit dem Oszi gemacht. Also Versuchsaufbau wie oben beschrieben: PC -> ft232rl ->max 481 -> ca. 30cm Leitung ->max481 -> PIC µC Ich schicke mit dem Terminal vom PC aus einen Buchstaben "a". (0x61) Der µC empfängt das Zeichen, gibt es binär auf LEDs aus und sendet es zurück. Die Oszibilder zeigen die beiden Zeichen. Kanal 1: A Kanal 2: B Math: A-B image0001.jpg: Konfiguration mit Beschaltung an beiden Enden: VCC -10k- A- 120 - B -10k- GND Ergebnis LEDs geben 0x61 korrekt aus, Terminal empfängt Unsinn und mehrere Null-Bytes image0004.jpg: Konfiguration mit Beschaltung an beiden Enden: A- 120 - B Ergebnis LEDs geben 0x61 korrekt aus, Terminal empfängt Unsinn und mehrere Null-Bytes image0006.jpg: Konfiguration ohne Beschaltung an beiden Enden: A- -B Ergebnis Achtung: Mathkanal anders skaliert! Pegel sind mehr als doppelt so groß. LEDs geben 0x61 korrekt aus, Terminal empfängt Zeichen korrekt zurück. Dazu jetzt folgende Fragen: - Warum geht es nur, wenn ich keine Terminierung verwende? In der Doku des max481 wird jeweils ein 120 Ohm Widerstand verwendet. - Müsste es nicht bei den beiden Konfigurationen mit Terminierung genauso gehen? - Zu Bild 1: warum ist die Antwort von den Signalpegeln geringer? der Busaufbau verwendet auf beiden Seiten ein max481 und ist symmetrisch. Es ist übrigens egal auf welcher Seite ich messe, gleiches Ergebnis - Wie notwendig ist ein Twisted-Pair-Kabel? Ich habe hier nur 30cm Zweidrahtleitung (2x 1mm² parallel, ungeschirmt ) verwendet. Bei so kurzer LEitung und Hobby-Keller-Umfeld dürfte das doch egal sein - Warum geht es in die eine Richtung immer, in die andere nur ohne Terminierung? - Darf ich die Terminierung erst bei größeren Leitungslängen verwenden? - Ist einer der Transceiver kaputt? Bin ein bischen ratlos, wer kann mir dazu ein paar Antworten geben?
Seltsam, das Problem, dass ich Nullen empfange die keiner gesendet hat tritt jetzt auch im Fall 3 (ohne Terminatoren) auf. Alllerdings nicht immer und eher sporadisch. Wirklich seltsam.
Altes Problem. Du braucht Pull-Ups und Pull Down. Schalte je 1K von A nach VCC und 1K von B nach GND, dann passt das. Wenn du bei langen Leitungen mit Termnierung arbeiten muss (siehe Wellenwiderstand), dann nimmt man 120 Ohm für die Terminierung und je 390 ohm für Pull-Up Down. Macht in Summe 100 Ohm. MFG Falk P S Muss man mal ins Wiki eintragen.
Falk Brunner schrieb: > Altes Problem. Du braucht Pull-Ups und Pull Down. Schalte je 1K von A > nach VCC und 1K von B nach GND, dann passt das. > Wenn du bei langen Leitungen mit Termnierung arbeiten muss (siehe > Wellenwiderstand), dann nimmt man 120 Ohm für die Terminierung und > je 390 ohm für Pull-Up Down. Macht in Summe 100 Ohm. > > MFG > Falk > > P S Muss man mal ins Wiki eintragen. Kleine Ergänzung: Wen die Berechnung interessiert, kann diese z.B. hier finden http://focus.ti.com/lit/an/slyt324/slyt324.pdf oder mit Fail-Safe-Transceivern wie dem dort verlinkten http://focus.ti.com/lit/ds/symlink/sn65hvd3080e.pdf arbeiten. Die unterschiedlichen Terminierungsarten findet man z.B. hier http://www.maxim-ic.com/app-notes/index.mvp/id/1090
@ Arc Net (arc)
>Kleine Ergänzung:
Pack sie das nächste Mal diekt in den Wikiartikel, dort sind solche
links besser aufgehoben.
done
MFG
Falk
Ok werde das mal versuchen, scheinbar waren meine Pull-Ups/Downs zu hochomig. Noch zwei Fragen: -Die Terminierung mit den Pull-Ups/Downs mache ich nur auf einer Seite, auf der anderen dann nur den einen zwischen A und B, wenn ich das richtig sehe? - Führe ich im Kabel jetzt eine Masse mit oder nicht? Vielen Dank für all Eure Tipps!
@Ma S, (ms99) >-Die Terminierung mit den Pull-Ups/Downs mache ich nur auf einer Seite, >auf der anderen dann nur den einen zwischen A und B, wenn ich das >richtig sehe? Ja. >- Führe ich im Kabel jetzt eine Masse mit oder nicht? Mitführen! MfG Falk
Bitte 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.