Empfangspuffer serielle

malt Gast #605103
Lesenswert?
• ▲
▼ 
Hi,

auf einem sehr lahmen System (Geode 300, Debian) lese ich ständig Daten 
von der seriellen Schnittstelle mit Baudrate 38400 ein, ohne 
Flußkontrolle. Die Datenrate beträgt etwa 600 Byte/sec. Wenn die 
Prozessorlast durch andere Prozesse für längere Zeit sehr hoch wird, 
gehen Teile der seriellen Daten verloren. Ich habe das überprüft mit 
"cat /dev/ttyS0 > test.dat". In test.dat sieht man dann bei hoher 
Prozessorlast die Lücken.

Wenn ich die gleichen Daten über einen Ethernet Port einlese, gibts 
keine Lücken.

Ich habe gelesen, dass die UART Bausteine einen Empfangspuffer von nur 
16Byte besitzen. Habe aber nichts drüber gefunden, wie man diesen Puffer 
irgendwie vergößern kann. In setserial oder stty gibts dafür keine 
Optionen.

Hat jemand eine Idee zur Lösung des Problems?

Gruß
Malte
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Bobby Gast #605143
Lesenswert?
• ▲
▼ 
Linux-Systeme haben einen zusätzlichen Datenpuffer,
der aber nur dann gefüllt wird, wenn von der
seriellen Schnittstelle Interrupts durchkommen.

Festplatteninterrupts haben eine höhere Priorität
als die der seriellen Schnittstellen.
Das verhindert oft das Durchkommen der seriellen INTs.

Eine Lösung kann darin bestehen, die Platten in den
DMA-Modus zu versetzen. "man hdparm", Option -d.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Bobby Gast #605360
Lesenswert?
• ▲
▼ 
Du kannst noch versuchen, deinem Leseprogramm
eine höhere Priorität zu verschaffen.
Dazu dient das Programm nice.

Aufrufbeispiel:  nice -n -10 deinprog

Der Wert muss negativ sein! Gelingt aber nur als root.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Karl H. #605382
Lesenswert?
• ▲
▼ 
malt wrote:
> Hi,
>
> auf einem sehr lahmen System (Geode 300, Debian) lese ich ständig Daten
> von der seriellen Schnittstelle mit Baudrate 38400 ein, ohne
> Flußkontrolle.

Im 'schlimmsten' Fall könnte man eine Flusskontrolle
aktivieren bzw. implementieren.
Den die gibt es genau aus dem Grund der jetzt deinen
Fehlerfall darstellt.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
malt Gast #605534
Lesenswert?
• ▲
▼ 
Hallo,

nice hat kaum Wirkung gezeigt, leider. Kann es sein, dass nice nur die 
Prozessorzeit anders aufteilt, und dies keine Auswirkung auf die 
Reaktion auf Interrupts hat?

Ja, eine Flusskontrolle waere gut in diesem Fall. Mir graut aber vor der 
Implementierung, von den Aenderungen in der Hardware ganz zu 
schweigen...

Es wundert mich, dass die eth-Ports so gaenzlich anders behandelt werden 
als die seriellen. Haben die einfach mehr Speicher im Chip?

Gruss
Malte
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Simon K. Persönliche Seite #605554
Lesenswert?
• ▲
▼ 
malt wrote:
> Hallo,
>
> nice hat kaum Wirkung gezeigt, leider. Kann es sein, dass nice nur die
> Prozessorzeit anders aufteilt, und dies keine Auswirkung auf die
> Reaktion auf Interrupts hat?
>
> Ja, eine Flusskontrolle waere gut in diesem Fall. Mir graut aber vor der
> Implementierung, von den Aenderungen in der Hardware ganz zu
> schweigen...
>
> Es wundert mich, dass die eth-Ports so gaenzlich anders behandelt werden
> als die seriellen. Haben die einfach mehr Speicher im Chip?
>
> Gruss
> Malte

Soweit ich weiß werden die Daten von der Netzwerkschnittstelle per DMA 
direkt in den Hauptspeicher kopiert, ohne dass der Prozessor was machen 
muss.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
nop(); Gast #605681
Lesenswert?
• ▲
▼ 
Beim 16byte FIFO kann man den triggerlevel setzen. Auf 4,7,10,14, soweit 
ich mich erinnere. Diese Zahl sollte man kleiner waehlen. ZB von 10 auf 
7 erniedrigen. Wenn die Festplatte, alllerdings das system zu macht, 
hilft das nicht viel. In dem Falle eine externe Schnittstellenkarte, zB 
ISA oder PCI, die haben beliebig viel Buffer drauf.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren