Hallo, ich habe eine kleine Platine mit einem FT232 gemacht und einer Steckerleiste am Ende, damit ich diese zwischen Platinen mit einem Atmega und meinem Rechner schalten kann um zu debuggen (welche Ironie). Dazu habe ich nur RX und TX (und 5V und GND) verwendet, die Handshake-Signale habe ich nicht verbunden. Die Stabilisierung der Spannung mit den Kondensatoren und den LEDs als senden/empfangen-Indikatoren habe ich angeschlossen wie im Datenblatt angegeben und vorgeschlagen (es gibt ein Beispiel für diesen Anwendungsfall). Jetzt ist es so, dass die Chance auf einwandfreie Funktion bei sowas wie 50% liegt. Das heißt, manchmal stecke ich das Kabel an und im Terminal sehe ich nichts oder nur ein paar Zeichen und manchmal sehe ich im Terminal das, was der Atmega sendet. Der Transmit-Pin des Atmega sendet aber immer, also alle Sekunde sende ich da einen Schwung Informationen raus. Folgendes ausprobiert: 1. Adapterchip anstecken, warten, bis er sich am Rechner als serielles Device angemeldet hat (dieser Schritt klappt immer) 2. Terminalprogramm starten, in meinem Fall benutze ich ein Demoprogramm aus dem Python-Paket "pyserial" (das geht auch noch, ist aber keine große Kunst) 3. Atmega an den Adapterchip klemmen, Strom kommt ebenfalls vom Adapter, er läuft also nicht vorher los. Ich habe es eben gerade nochmal getestet, beim ersten Versuch hat alles funktioniert, beim zweiten Versuch kam nichts mehr an. Besonders stutzig macht mich dabei, dass die Chips sich ja bei einem Start vorhersagbar gleich verhalten sollten, also entweder funktionieren oder nicht funktionieren, aber das dann immer. Ich dachte dann, dass es vielleicht an meinem Terminalprogramm liegt und wollte Picocom ausprobieren, das ging aber nicht da es meine Baudrate (250000) nicht "kann". Es kommt ein Fehler "invalid baudrate", auf diese Baudrate komme ich durch den Rechner von gjlay.de und weil bei meiner Frequenz (20MHz) dort bei UBRR=4 kein Fehler angezeigt wird. Die höchste Baudrate, die z.B. minicom anbietet, ist 115200 aber da zeigt mir der Rechner einen Fehler von 1.4% an was wahrscheinlich zu hoch ist. (Ok, neben dem Tippen hab ich jetzt, um ganz sicher zu sein, die 115200 mit picocom ausprobiert: Auch kein Erfolg. Nachdem ein paar Zeilen ankommen, scheint die Kommunikation abzubrechen und auch ein Reset des uC bringt keine neuen Zeichen) Hat jemand einen Tipp für mich? Z.B. dass es ohne Handshake nicht geht oder sowas da bei vollem Puffer der FT232 lustige Sachen macht? Oder dass dieser Aufbau sehr empfindlich gegen elektromagnetische Strahlung ist oder gegen tote Indianer, die unter dem Haus vergraben sind? Grüße Philipp
Wie lang ist die Zeit zwischen zwei Zeichen auf der seriellen Schnittstelle? Baue mal am Ende jedes Datenpaketes (oder wenn Du ein \n sendest) eine Pause von mindestens 20 Bitlängen ein. Eventuell funktioniert sonst die Synchronisation des Empfänger-UARTs auf das Startbit nicht richtig. Andere Idee: Masseschleife (ich weiß nicht, wie der sonstige Aufbau ist). Dem kann man mit zwei Optokopplern leicht und günstig abhelfen. fchk
RTS/CTS müssen verbunden sein bei Betrieb von RX/TX einzeln, ansonsten ist es ein Zufallsspiel ob die Übertragung frei ist oder nicht.
Ehrhardt schrieb: > RTS/CTS müssen verbunden sein bei Betrieb von RX/TX einzeln, ansonsten > ist es ein Zufallsspiel ob die Übertragung frei ist oder nicht. Das ist Nonsense.
Simon K. schrieb: > Ehrhardt schrieb: >> RTS/CTS müssen verbunden sein bei Betrieb von RX/TX einzeln, ansonsten >> ist es ein Zufallsspiel ob die Übertragung frei ist oder nicht. > > Das ist Nonsense. nein
Hallo Philipp, zeig doch mal bitte den Schaltplan, sonst ist das hier ein reines Ratespiel...
http://www.ftdichip.com/Documents/DataSheets/Modules/DS_UM232R.pdf Gibt es zu kaufen, z.b. RSonline ohne Versandkosten auch mit kleinem USB Stecker = UB232R
Simon K. schrieb: > Ehrhardt schrieb: >> RTS/CTS müssen verbunden sein bei Betrieb von RX/TX einzeln, ansonsten >> ist es ein Zufallsspiel ob die Übertragung frei ist oder nicht. > > Das ist Nonsense. Stimmt. Rts/cts wird nur ausgewertet wenn der handshake aktiviert wurde. Bei keinem handshake oder xon/xoff ist rts/cts irrelevant.
Hallo, gestern kam ich nicht zum Mikrocontrollieren, sorry für die verspätete Rückmeldung. Den Schaltplan hab ich angehängt, an der anderen Seite sind VCC, GND und TX / RX angeschlossen, die beiden anderen Leitungen sind NICH angeschlossen oder verwendet. Meine Routinen für die Initialisierung des UART und die Übertragung sehen folgendermassen (entschuldigt, kein sz hier auf der Tastatur) aus (ich hab mir mal erlaubt sie komplett einzufügen, ist nicht besonders lang oder kompliziert):
1 | #ifndef _FT232RL__H
|
2 | #define _FT232RL__H
|
3 | |
4 | #include <avr/io.h> |
5 | |
6 | |
7 | static int USART_transmit(char data, FILE *stream){ |
8 | while ( ! (UCSRA & (1 << UDRE))) { |
9 | ;
|
10 | }
|
11 | UDR = data; |
12 | |
13 | return 0; |
14 | }
|
15 | |
16 | |
17 | void USART_init(unsigned int ubrr){ |
18 | UBRRH = (unsigned char) (ubrr >> 8); |
19 | UBRRL = (unsigned char) ubrr; |
20 | |
21 | // enable receiver and transmitter
|
22 | |
23 | UCSRB = (1 << RXEN) | (1 << TXEN); |
24 | UCSRC = (1 << URSEL) | (1 << UCSZ1) | (1 << UCSZ0); |
25 | }
|
26 | |
27 | |
28 | |
29 | // declaring debug_out
|
30 | static FILE debug_out = FDEV_SETUP_STREAM(USART_transmit, NULL, _FDEV_SETUP_WRITE); |
31 | |
32 | |
33 | #endif
|
Jetzt schreibe ich mit fprintf(stderr, ...) Medlungen raus, in der Datei die das einbindet muss ich also den UART initialisieren (mit 4, 20MHz) und stderr = &debug einfügen. Das Kabel zum uC ist vielleicht 15 cm lang, im Datenblatt zum FT232 ist noch ein Ferrit vorgeschlagen, dies habe ich weggelassen. Grüsse Philipp
So, ich habe jetzt mal Peter Fleurys UART-Library ausprobiert (die ja X-fach bewährt scheint). Am Ergebnis ändert sich nichts. Beim ersten Versuch kam alles an wie erwartet, auch über einen längeren Zeitraum, danach habe ich das Kabel vom Rechner getrennt, erneut angesteckt und den String "foo_hoooooo" an das Gerät gesendet. Zurück kam dann "foo" und dann nichts mehr. Ein Reset des Atmega bringt auch keine Änderung, erst wieder Reset des ganzen Aufbaus durch Trennen der USB-Verbindung. Es scheint immer so ein Glücksspiel zu sein: Manchmal ist die Verbindung zuverlässig und ich kann den Atmega an- und abstöpseln wie ich will, aber manchmal braucht es auch 4 oder 5 Anlüfe bis überhaupt mal 10 Zeichen fehlerfrei übertragen werden. Während einer "guten" Verbindung kann ich übrigens auch an allen Kabeln und Steckern wackeln ohne dass sich etwas tut was nicht sein soll. Hatte jemand schonmal solche Erfahrungen mit dem Baustein?
mach doch an deinem Adapter mal eine Brücke TX-RX rein un sende dir selbst ein paar Daten. Wenn schon so nichts geht kann's schon mal nicht am µC liegen. Sascha
Gibt es eigentlich einen Vorteil einer niedrigen Baudrate? Mir fällt spontan nur ein, dass es bei Bussystemen eben der kleinste Nenner ist und man auch langsame uC einsetzen kann, aber ist auch die Übertragungsqualität besser?
Ok, also ich habe jetzt eine Brücke eingesteckt und RX mit TX direkt verbunden. Es liegt also vermutlich - am Treiber auf Betriebssystemseite - am Chip bzw. meiner Schaltung. Ich habe bei einer funktionierenden Übertragung allerlei mechanische Belastung auf Kabel und Stecker gegeben, kein Problem. Allerdings musste ich das USB-Kabel wieder an- und abstecken, bis ich eine stabile Verbindung hatte. Die Beobachtung ist weiterhin, dass wenn ich das Terminalprogramm öffne und mir einige Zeichen schicke, entweder nichts ankommt, einige Zeichen ankommen oder alles ankommt, allerdings vollkommen ohne Systematik.
Hatte ein ähnliches Problem, bei mir musste ich den Reset Pin ordentlich beschalten, dann hats funktioniert. Vielleicht hilfts... obwohl laut Datenblatt nicht notwendig
Hm, ich habe jetzt das Ferrite-Bead und den Reset mit VCC verbunden. Das Ergebnis ist das gleiche. Ich werde das Gefühl nicht los, dass es sich um ein Treiberproblem handelt -- allerdings ist der Linux-Treiber doch direkt von FTDI beigesteuert, sonst würden sie ihn ja im Datenblatt sicherlich nicht erwähnen und außerdem wäre ich dann ja nicht alleine mit meinem seltsamen Problem. Ich werde vielleicht mal einen "general reset" machen und eine neue Platine ätzen und einen neuen Chip verbauen. "Reboot tut gut", vielleicht ja auch bei Hardware ...
Also das Ferrit-Teil hab ich natürlich zwischen USB und Chip eingebaut, wie im Datenblatt angegeben, nicht mit VCC verbunden ^^
Hm, daran hatte ich auch schon gedacht, das würde dann aber nicht zur Beobachtung passen, dass es manchmal möglich ist, eine einwandfreie Verbindung herzustellen. Ich werde es heute Abend aber nochmal machen, vielleicht habe ich ja wirklich einen Chip erwischt, der einen kleinen Schlag hat oder den ich beim einlöten zu grosser Hitze ausgesetzt habe oder so.
Ich hätte noch n paar Platinen mit falschem Bestückdruck abzugeben. Platine ohne alles drauf denke ich so an 1€. Voll funktionsfähig, eben nur der BD auf der falschen Seite und spiegelverkehrt. Auswahl über Jumper ob VCCIO auf 5V oder 3V3. Bei Interesse PM.
@Philipp kann es sein das du am PC beim öffnen der Schnittstelle Hardware-Handshake aktiviert hast und nun der unbeschaltete Eingang am FT immer mal einen anderen Pegel einliest?
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.