FT232R agiert "zufällig"

[Philipp (Gast)]

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

[mpl (Gast)]

zeig doch mal nen schaltbild,

wo hängt VCCIO dran?

[Frank K. (fchk)]

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

[Ehrhardt (Gast)]

RTS/CTS müssen verbunden sein bei Betrieb von RX/TX einzeln, ansonsten 
ist es ein Zufallsspiel ob die Übertragung frei ist oder nicht.

[Simon K. (simon)]

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.

[Ehrhardt (Gast)]

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

[Michael H. (michael_h45)]

doch.

[Michael St. (Gast)]

Hallo Philipp,

zeig doch mal bitte den Schaltplan, sonst ist das hier ein reines 
Ratespiel...

[termite (Gast)]

http://www.compuphase.com/software_termite.htm

Das kann jede Baudrate.

[um232 (Gast)]

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

[Christian H. (netzwanze)]

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.

[Philipp (Gast)]

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):

#ifndef _FT232RL__H
#define _FT232RL__H

#include <avr/io.h>


static int USART_transmit(char data, FILE *stream){
  while ( ! (UCSRA & (1 << UDRE))) {
    ;
  }
  UDR = data;

  return 0;
}


void USART_init(unsigned int ubrr){
  UBRRH = (unsigned char) (ubrr >> 8);
  UBRRL = (unsigned char) ubrr;

  // enable receiver and transmitter

  UCSRB = (1 << RXEN) | (1 << TXEN);
  UCSRC = (1 << URSEL) | (1 << UCSZ1) | (1 << UCSZ0);
}



// declaring debug_out
static FILE debug_out = FDEV_SETUP_STREAM(USART_transmit, NULL, _FDEV_SETUP_WRITE);


#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

[Philipp (Gast)]

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?

[Sascha W. (sascha_w)]

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

[Philipp (Gast)]

Ah, die Idee ist natürlich gut! Werd ich gleich mal probieren.

[Philipp (Gast)]

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?

[Philipp (Gast)]

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.

[Tueftler (Gast)]

Hatte ein ähnliches Problem, bei mir musste ich den Reset Pin ordentlich 
beschalten, dann hats funktioniert. Vielleicht hilfts... obwohl laut 
Datenblatt nicht notwendig

[Philipp (Gast)]

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 ...

[Philipp (Gast)]

Also das Ferrit-Teil hab ich natürlich zwischen USB und Chip eingebaut, 
wie im Datenblatt angegeben, nicht mit VCC verbunden ^^

[Michael H. (michael_h45)]

Wie schaut das Layout so aus?
IC sauber verlötet?

[Philipp (Gast)]

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.

[Hannes J. (Firma: eHaJo.de) (joggl)]

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.

[Sascha W. (sascha_w)]

@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?