FT232R agiert "zufällig"

zeig doch mal nen schaltbild,

wo hängt VCCIO dran?

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. 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.compuphase.com/software_termite.htm

Das kann jede Baudrate.

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

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?

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

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.