Serieller Datenempfang und Interrupts: Timingproblem?

[mcKalle (Gast)]

Hi,

ich habe eine eine serielle Datenübertragung (unidirektional) über 
Infrarot realisiert. Auf der Sendeseite wird mein rs232-Signal direkt 
auf 38kHz aufmoduliert und am µC (atmega88-20PU) hängt an Pin2 ein 
TSOP31238.
Dazu habe ich mir ein Programm in c# geschrieben, mit dem ich beliebige 
Daten senden kann. Solange ich nur 1 Byte mit kurzer Pause sende, 
funktioniert es wunderbar:

for( int i = 0; i<3; i++)
{
    serialPort.Write(new byte[] { Convert.ToByte(i) }, 0, 1);
    Thread.Sleep(5); //5ms nix tun
}

Wenn ich aber mehrere Bytes auf einmal senden möchte, werden maximal 3 
Bytes richtig verarbeitet.

serialPort.Write(new byte[] { 0x00, 0x01, 0x02 }, 0, 3);

Wenn ich mehr sende, kann ich nicht sagen, was davon tatsächlich 
verarbeitet wird.
Das sieht für mich so aus, als ob der µC mit der Verarbeitung nicht 
schnell genug hinterherkommt.
Ich benutze einen Quarz mit 7,3728MHz, die Fuse-Bits für die Taktrate 
sind deaktiviert bis auf CKSEL3 (CHKDIV8 ist auch deaktiviert). Somit 
sollte der µC auch mit 7,3728 MHz getaktet sein. Als Baudrate verwende 
ich 2400 Baud, 1 Startbit, 8 Datenbits, 1 Paritätsbit, 2 Stopbit.

Wenn ich richtig rechne, komme ich somit auf eine Übertragungszeit für 1 
Byte von 0,0045s. In dieser Zeit hat der µC etwa 3000 Zyklen. Das 
AVR-Studio zeigt mir an, dass es für die komplette Ausführung der 
Interrupt-routine etwa 200 Zyklen braucht.
Kann mir jemand vielleicht weiterhelfen?
Den Quellcode von der Interrupt-Routine habe ich im Moment leider nicht 
zur Verfügung. Ich werde ihn, wenn gewünscht, heute Abend einstellen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

mcKalle schrieb:
> Kann mir jemand vielleicht weiterhelfen?
Ist da noch ein anderer Interrupt aktiv, der länger brauchen könnte?

[Peter D. (peda)]

Warscheinlich verschluckt sich die AGC des TSOP.
Der TSOP stellt bestimmte Bedingungen an die Signalform.
Z.B. Manchestercode ist geeignet, den versteht aber die UART wiederum 
nicht.


Peter

[mcKalle (Gast)]

Lothar Miller schrieb:
> mcKalle schrieb:
>> Kann mir jemand vielleicht weiterhelfen?
> Ist da noch ein anderer Interrupt aktiv, der länger brauchen könnte?
Es ist sonst kein Interrupt aktiv.

Peter Dannegger schrieb:
> Warscheinlich verschluckt sich die AGC des TSOP.
> Der TSOP stellt bestimmte Bedingungen an die Signalform.
> Z.B. Manchestercode ist geeignet, den versteht aber die UART wiederum
> nicht.
Wenn ich das aus dem Datenblatt richtig entnommen habe, braucht der TSOP 
eine bestimmte Anzahl an Impulsen (10 Stück), bis er ein Signal ausgibt. 
Bei 2400 Baud ist diese Anzahl aber auf jeden Fall gegeben.
http://www.farnell.com/datasheets/529935.pdf

[Peter D. (peda)]

mcKalle schrieb:
> Wenn ich das aus dem Datenblatt richtig entnommen habe, braucht der TSOP
> eine bestimmte Anzahl an Impulsen (10 Stück), bis er ein Signal ausgibt.
> Bei 2400 Baud ist diese Anzahl aber auf jeden Fall gegeben.

Da sind aber noch mehr Bedingungen:

• Burst length should be 10 cycles/burst or longer.
• After each burst which is between 10 cycles and 70
cycles a gap time of at least 14 cycles is necessary.
• For each burst which is longer than 1.8 ms a corresponding
gap time is necessary at some time in the
data stream. This gap time should be at least 4 times
longer than the burst.
• Up to 800 short bursts per second can be received
continuously.


Peter

[Kei N. (mckalle)]

Scheinbar funktioniert es ganz gut, wenn ich den Serialport mit 4800 
Baud ansteuere, jedoch nur 6 Datenbits (knapp über die Beschränkung 
"nach jedem Burst zwischen 10 und 70 Zyklen müssen 14 Zyklen Pause sein" 
hinaus :S ) + Parität Even + 1,5 Stopbits. Die Daten teile ich nun in 
jeweils zwei "Pakete" auf.
Leider treten aber noch relativ häufig Fehler auf. Ich werde das nochmal 
mit 5 Bits + 1 Stopbit ohne Parität probieren. Hoffentlich gibt es da 
nicht all zu große Probleme, wenn keine Parität vorhanden ist.

[Kei N. (mckalle)]

Für diejenigen, die ähnliche Probleme haben: Ich habe den seriellen Port 
auf 5 Datenbits und 1 Stoppbit eingestellt. Um die Datenkorrektheit zu 
gewährleisten, sende ich innerhalb der 5 bit, die ich zur Verfügung habe 
nur 4 Datenbits und ein Paritätsbit. Außerdem kommt danach noch einmal 5 
bit, die nochmal die Parität zu den ersten beiden Pakete bilden. Diese 3 
Pakete müssen innerhalb einer bestimmten Zeit eintreffen, sonst werden 
alle verworfen. Wenn die Pakete zueinander passen, setze ich die Daten 
wieder zu einem Byte zusammen. Mit dieser Übertragung steuere ich 
RGB-LEDs mit ca. 60 Hz ohne Probleme.
Nochmal danke für den Tipp mit den Strobes, das hab ich wohl irgendwie 
übersehen.