mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik FT232R agiert "zufällig"


Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: mpl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
zeig doch mal nen schaltbild,

wo hängt VCCIO dran?

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ehrhardt (Gast)
Datum:

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

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ehrhardt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
doch.

Autor: Michael St. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Philipp,

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

Autor: termite (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: um232 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://www.ftdichip.com/Documents/DataSheets/Modul...

Gibt es zu kaufen, z.b. RSonline ohne Versandkosten
auch mit kleinem USB Stecker = UB232R

Autor: Christian H. (netzwanze) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Philipp (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Sascha Weber (sascha_w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Philipp (Gast)
Datum:

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

Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tueftler (Gast)
Datum:

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

Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Philipp (Gast)
Datum:

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

Autor: Michael H. (michael_h45)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie schaut das Layout so aus?
IC sauber verlötet?

Autor: Philipp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hannes J. (Firma: eHaJo.de) (joggl) Benutzerseite Flattr this
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sascha Weber (sascha_w)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.