www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik FT232RL 3Mbaud senden und empfangen


Autor: Claudio Hediger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo


Ich versuche mit dem FT232RL und einem Attiny2313 mit 3MBaud's daten 
auszutauschen.

Mein C Programm
void uart_init(void)
{
  UCSRB |= (1<<RXEN);
  UCSRB |= (1<<TXEN);                // UART TX einschalten
  UCSRB |= (1<<RXCIE);
  UCSRC |= (3<<UCSZ0);    // Asynchron 8N1 

  UBRRH = 0;
  UBRRL = 0;
}

ISR(USART_RX_vect)
{

}

void main(void)
{
  uart_init();
  sei();
  
  
  
  while(1)
  {
      while (!(UCSRA & (1<<UDRE)));  /* warten bis Senden moeglich                   */
  UDR = ('o');                    /* schreibt das Zeichen x auf die Schnittstelle */
  }

}

Auf der PC Seite verwende ich ein angepasstes Beispielprogramm von FTDI

Ich stelle in delphi so die Baudrate ein:
FT_Current_Baud := 3000000;
Set_USB_Device_BaudRate;

Doch leider kommt nur "müll" beim PC an...

Ich empfange erst 30000 bytes und zeige diese an.

bei o wie in diesem beispiel kommt

~~~~~~~~

an


Hoffe ihr könnt mir helfen...
Danke schonmal

Autor: Claudio Hediger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab ich noch vergessen....

Der Attiny wird vom 24Mhz Clockout des FT232RL versorgt

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Must den /8 (U2X) Modus der UART einschalten, sonst /16 ergibt 1,5Mbd.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn schon ISR für Rx, dann Daten abholen um Int zu löschen, sonst 
Interrupt im Dauerfeuer.

NB: Dass aus Sicht des AVR die Rx Richtung keine 3Mbps verkraftet, weil 
dessen CPU das nicht packt, jedenfalls nicht per Interrupt, dürfte wohl 
klar sein. D.h. das PC Programm muss da sehr dezent vorgehen und 
ausserdem berücksichtigen, dass der USB-Layer Zeug bündelt was innerhalb 
einer Millisekunde rüberkommt. Also maximal 2 Bytes pro Millisekunde in 
den AVR schieben.

Autor: Claudio Hediger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab nun folgendes hinzugefügt
UCSRA |= (1<<U2X);

Nun kommt

========== an

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mach mal ne Pause zwischen den Bytes.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sende mal 0xFF, dann kommt genau und nur das Startbit auf 0, der Rest 
ist 1. Anderer ähnlicher Test geht mit 0xEF, um eine Bitverschiebung zu 
sehen.

Autor: Claudio Hediger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei 0xFF kommt 127dez an und bei 0xEF 111dez
Ich lese die Werte an einer Beliebigen Stelle im empfangenen Array aus


Somit sollte ja alles gut sein oder?

Autor: holger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Somit sollte ja alles gut sein oder?

Nö, 0xFF ist 255dez. Du hast einen Bitschieber;)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Claudio Hediger schrieb:

> Bei 0xFF kommt 127dez an und bei 0xEF 111dez

Klingt nach Bitratenfehler, wie immer du das geschafft hast. Wenn 
127=0x7F empfangen wird, dann kommt das nächste Startbit zu früh. Oder 
jemand unterwegs maskiert das obere Bit weg, denn bei 111=0x6F statt 
0xEF passt alles ausser dem letzten (obersten) Bit.

> Somit sollte ja alles gut sein oder?

Wieso? 0xFF ist 255, nicht 127.

Autor: Claudio Hediger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Wieso? 0xFF ist 255, nicht 127.

Stimmt...

Ist jalogisch.... war ein langer tag :)


Jetzt ist blos die frage, woo hier der Fehler liegt...

Das wird bestimmt schwierig bis unmöglich den zu finden

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mach das mal wie vorgeschlagen mit deutlich Pause dazwischen, um auch 
definitiv auf das Startbit zu triggern.

Autor: Claudio Hediger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Mach das mal wie vorgeschlagen mit deutlich Pause dazwischen, um auch
> definitiv auf das Startbit zu triggern.

Hab das problem gefunden...

Asche auf mein haupt...

Ich hab doch tatsächlich vergessen dem 232RL bzw meinem Programm 
mitzuteilen das es ein Parity bit gibt...

Nun empfange ich bei 0xFF 255

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Mach das mal wie vorgeschlagen mit deutlich Pause dazwischen, um auch
> definitiv auf das Startbit zu triggern.

Was, falls es am Timing liegt, auch funktionieren kann (je nach 
Controller, Last, etc.pp), ist, statt mit einem, mit zwei Stop-Bits zu 
arbeiten.
Controller war hier ein C8051F585 + FT232RL mit 3 MBit/s

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.