probleme mit Mega32-opto-fdti-Pc @ 912.6kbaud

[Tobi A. (Gast)]

Hi

ich hab ein Problem

Meine Hardware sieht wie folgt aus

Mega32 sendet daten via UART and Opto-Link Modul TOTX173.
Dann kommen 5 m plastikfaser.
Signal wird von TORX173 aufgesammelt und an einen FTDI232BM chip 
geleited.
Das ganze wird dann an den PC übertragen

Datenrate is 921,6 kbaud bei einer MEGA32 freuqenz von 14,7456 MHz.

Problem ist das folgende:

Ich sende ca 2,686 MB daten

%codeschnipsel

%bisschen code davor

itoa(daten, mystring);  %string ist ein oben def array
putchar(mystring[0]);
putchar(mystring[1]);
putchar(mystring[2]);
putchar(mystring[3]);
putchar(' ');
% ende codeschniplsel

Das ganze 100 x 500 mal (2 for loops).

WEnn ich das mache bekomme ich ca 300 kb datenverlust.

benutzte ich aber

%codeschnipsel

itoa(daten, mystring);  %string ist ein oben def array
putchar(mystring[0]);
delay_us(20);
putchar(mystring[1]);
delay_us(20);
putchar(mystring[2]);
delay_us(20);
putchar(mystring[3]);
delay_us(20);
putchar(' ');

%ende codeschnipsel

funktioniert es dauert aber dementsprechend länger - Zeit die ich 
eignetlich nicht habe.

Manchmal funktioniert es fehlerfrei manchmal nicht - ich weiss 
allerdings nicht mit was ich das beeinflussen kann.

Irgenwer irgendwelche Vorschläge?

Tobi

[Tobi A. (Gast)]

Nachtrag

die Masseleitung am TEST pin des FTDI chips ist recht lang - mögliche 
Fehlerquelle?

[Knut B. (Firma: TravelRec.) (travelrec)]

Fakt ist, daß Du keine längeren Gleichspannungsanteile über die 
TOTX/TORX Bauteile senden darfst. Wenn Du also eine 0 oder 255 sendest, 
kann der Modulator / Demodulator eventuell nicht mehr richtig arbeiten. 
Deshalb verwendet man bei der digitalen Audioübertragung (wofür die 
Dinger eigentlich bestimmt sind) ein bi-phasencodiertes Signal (SPDIF). 
Manchester-Codierung wäre da auch ein Kandidat.

[Obelix (Gast)]

Kann es evtl zum Pufferüberlauf im FTDI kommen?

[Knut B. (Firma: TravelRec.) (travelrec)]

Kann der PC eventuell die Daten nicht schnell genug abholen? Bei knapp 
1MBit/s über UART kann das schon knapp werden, wenn rechenintensive 
Programme nebenher laufen oder Netzwerktreiber aktiv sind. Ohne 
Handshaking ist das auf Dauer zu unsicher. Probiere doch vorerst mal mit 
niedrigeren Baudraten, ob die Fehlerquote dann sinkt.

[Dieter W. (dds5)]

Es wäre sicher auch von Interesse, auf welchem Teil der Strecke (optisch 
oder USB) die Daten verschütt gehen.

[Sven (Gast)]

1Mbit dürfte wohl noch ohne Probleme funktionieren
(also TOTX173 / TORX173)

Wie sieht die Ansteuerung genau aus ? (Schaltplan)
Sind noch Treiber vorgeschaltet ?

Als 2. würde ich auch auf die PC Seite tippen, das die
ankommenden Daten nicht schnell genug verarbeitet werden.
Was wird da auf der PC Seite benutzt ?

Gruß Sven

[Tobi A. (Gast)]

HI

also der Fehler passiert auch wenn ich auf 115kbaud runtergehe 
allerdings dann nicht so ausgeprägt.

Das mit ankommenden seite am PC hatte ich auch im verdacht - weiss aber 
nocht genau wie ich es brüfen soll.

Ich hab immer noch die vermutung das die PLL vom FTDI Chip ab und wann 
spinnt weil die masseleitung recht lang ist (ca 30 mm)

Tobi

[Tobi A. (Gast)]

@travel rec

"Fakt ist, daß Du keine längeren Gleichspannungsanteile über die
TOTX/TORX Bauteile senden darfst"

wo hast du das her? Im datenblatt seh ich nur bei NRZ ueber 3 MBaud 
beschraenkngen - bin aber gerne gewillt mich belehren zu lassen.

Tobi

[BenTu (Gast)]

@travel rec

> "Fakt ist, daß Du keine längeren Gleichspannungsanteile über die
> TOTX/TORX Bauteile senden darfst"

Die "alten" 5V Typen ( z.B. Serie 173 ) können noch statische Zustände 
darstellen ( DC für Stop Zustand der RS-232 ). Die neuen 3,3V Typen 
können es ALLE nicht mehr. Statische Zustände werden auf der 
Empfängerseite durch den TOTX nicht ausgegeben. Im Datenblatt des 
Nachbaus vom Sharp ist dies im Text explitit erwähnt und mit einen 
Blockschaltbild untermauert ( siehe Anhang ). Im Orig. von Toshiba nur 
an der min. Übertragungsrate zu erkennen.

MfG