Hallo, ich habe hier einen FTDI FT232R an einem Atmega8 als USB<->RS232 Wandler. Beide Chips arbeiten in einer Batterieschaltung, der FT232 soll nur über USB versorgt werden. Die Leitungen RXD und TXD des FT232 sind mit den enstprechenden Pins des Atmega verbunden. RTS# und CTS# habe ich gemäß Datenblatt auf VCC (high) gelegt, GND des FT und des ATMEGA liegen zusammen. Im Normalbetrieg benötigt meine Schaltung ca. 5mA. Ist jedoch kein USB-Kabel am FT232 angeschlossen und wird die Schaltung eingeschaltet zieht dieser jedoch dauerhaft 35 bis 40mA. Das ganze lässt sich nicht direkt reproduzieren, ist das USB-Kabel einmal eingesteckt und wird wieder abgezogen bleibt der Stromverbrauch normal. Das Verhalten zeigt sich auch bei angeschlossenem Kabel wenn der Rechner neu bootet - muss also auch was mit dem Treiber zu tun haben. Der FT232R sitzt auf einem USB -> RS232_TTL Modul von Ulrich Radig (http://www.ulrichradig.de/home/uploads/File/USB_RS232/USB_TTLRS232.zip). Die Schaltung entspricht in etwa der auf Seite 30 des FT232R-Datenblatts "7.4 USB to MCU UART Interface". Nur das RTS# und CTS# auf VCC (High) liegen, PWREN# nicht verbunden ist (ist ja eh optional) und der Takt nicht genutzt wird. Nach mehrfacher Konsultation des Datenblatts gehe ich mal davon aus, dass man mit dem FTDI-Mprog-Tool irgendeinen Parameter (PullUps) umstellen muss. Aber welchen? Oder gibts für dieses Problem eine andere bekannte Ursache?
>Oder gibts für dieses Problem eine andere >bekannte Ursache? Ja, sowas kommt davon wenn man sich nicht zwischen Buspowered und Selfpowered entscheidet und dann eine Mischung von beidem versucht.
>Ja, sowas kommt davon wenn man sich nicht zwischen Buspowered >und Selfpowered entscheidet und dann eine Mischung >von beidem versucht. Das Radig RS232_TTL Modul führt nur die 5 Anschlüsse TXD, RXD, CTS#, RTS# und GND auf eine Stiftleiste. Dieser "Mischbetrieb" ist quasi von vorneherein so vorgesehen. Buspowered heißt doch nicht zwangsläufig, dass der komplette Rest der Schaltung ebenfalls über USB versorgt werden muss? Solange die TTL Pegel zwischen FT232 und Atmega8 stimmen sollte doch alles ok sein.
>Buspowered heißt doch nicht zwangsläufig, dass der komplette Rest der >Schaltung ebenfalls über USB versorgt werden muss? Stimmt, dafür gibt es ja Selfpowered. Die Beschaltung am FT sieht dafür aber anders aus. >RTS# und CTS# habe ich gemäß Datenblatt auf VCC (high) >gelegt, Da ist eins von deinen Problemen. Der FT hat keinen Saft von USB und du gibst ihm über diese Pins parasitär Strom. Also RTS und CTS offen lassen. Das nächste ist der TX Pin vom Atmega. Den musst du entweder auf Eingang schalten wenn der FT nicht an USB hängt, oder vieleicht einen 10k Widerstand in die Leitung machen.
Dennis Reichenbach schrieb: > RTS# und CTS# habe ich gemäß Datenblatt auf VCC (high) > gelegt RTS# ist doch ein Output des FT232, weshalb legst Du den an VCC?
>RTS# ist doch ein Output des FT232, weshalb legst Du den an VCC? Das steht im folgenden Thread als Lösung: Beitrag "FT232R sendet Mist wenn COM aktiviert" Zusammenfassung: lässt man RTS# und CTS# unbeschaltet erhält man beim Senden/Empfangen nur Datenmüll. Als Lösung wird vorgeschlagen beide Ports auf Vcc zu legen - was dann auch funktioniert. Nachteil ist natürlich die parasitäte Versorgung des FT232R
Dennis Reichenbach schrieb: >>RTS# ist doch ein Output des FT232, weshalb legst Du den an VCC? > > Das steht im folgenden Thread als Lösung: > > Beitrag "FT232R sendet Mist wenn COM aktiviert" > > Zusammenfassung: lässt man RTS# und CTS# unbeschaltet erhält man beim > Senden/Empfangen nur Datenmüll. Als Lösung wird vorgeschlagen beide > Ports auf Vcc zu legen - was dann auch funktioniert. > > Nachteil ist natürlich die parasitäte Versorgung des FT232R Ich glaub, da liegt ein Missverständnis vor. So steht das da nicht dirn, dass beide Ports auf VCC gelegt werden sollen. Diese Aussage aus dem Thread wäre korrekt: > Normalerweise wird dann RTS mit CTS und DTR mit DSR verbunden, wenn man > das HW-Handshake vorgaukeln will. Also Verbindung von RTS und CTS sowie Verbindung von DTR mit DSR, aber nicht an VCC legen. Auf keinen Fall sollte ein Ausgang des FT232R an VCC gelegt werden. Das würde auch Dein Stromproblem erklären.
Das man einen Ausgang des FT232R nicht auf VCC legen sollte leuchtet mir ja ein. Allerdings habe ich jetzt wie vorgeschlagen RTS mit CTS sowie DTR mit DSR verbunden. Das Problem bleibt in diesem Fall jedoch: sobald das USB-Kabel angesteckt wird werden alle Daten die der Mikrocontroller (ATmega88) über TX sendet über RX wieder empfangen. Schließt man das Oszilloskop an RX und TX sieht man, dass auf beiden Kanälen die gleichen Pegel/Signale anliegen. Die RX und TX Leitungen sind jedoch nirgends vertauscht - die Übertragung hat ja bisher funktioniert. Zudem kommen in der Terminalanwendung auch alle Zeichen richtig an, sie werden jedoch scheinbar direkt wieder "gesendet". Ich habe auch schon unterschiedliche PCs mit unterschiedlichen Betriebsysystemen (XP/Vista/7) und verschiedene Terminalanwendungen (Hyperterminal, Putty, Hterm) probiert - bei allen das gleiche Ergebnis. Den verwendeten Bascom-Code hänge ich heute abend mal an, vielleicht fällt ja noch wem was ein. Verzweifelter Gruß, Dennis
Dennis Reichenbach schrieb: > Den verwendeten Bascom-Code hänge ich heute abend mal an, vielleicht > fällt ja noch wem was ein. Wenn du sicher gehen willst, dass alles ok ist, würde ich eine reine self-powered Lösung empfehlen: 1) Löte mal am RESET-Pin des FT232RL zwei Widerstände als Spannungsteiler an die +5V der USB-Schnittstelle ein, so wie es im Datenblatt beschrieben ist. 2) VCC und VCCIO dann an die Versorgungsspannung des ATmegas (aus der Batterie). In unseren Geräten haben wir damit noch keine Probleme im Betrieb gehabt. Die Handshake-Leitungen sind offen und werden nicht benutzt.
> 1) Löte mal am RESET-Pin des FT232RL zwei Widerstände als > Spannungsteiler an die +5V der USB-Schnittstelle ein, so wie es im > Datenblatt beschrieben ist. > > 2) VCC und VCCIO dann an die Versorgungsspannung des ATmegas (aus der > Batterie). Ok, das werde ich heute abend mal probieren, einen Chip habe ich ja noch. Da es sich bei den Modulen um fertige Platinen handelt ist das mit dem umlöten allerdings nicht so einfach. Was eventuell noch eine Rolle spielen könnte: ich nutze den internen Takt des Atmega88 (Standardmäßig 8MHz, runtergeteilt auf 1MHz [Standard-Fuses]). Führt das eventuell zu Problemen mit dem FT232R? Eingestellte/gewünschte Baudrate liegt bei 2400bps.
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.