Re: [DDL-ML] HaBa-Patch

[Harald Barth <haba@pdc.kth.se>]

> (1) Änderungen in waitUARTempty()
> 
>      Offenbar versuchst Du die Anzahl der Bytes zu ermitteln,
>      die noch im Puffer des UART stehen. 

Ja. Das Ziel ist die Ausgabepuffer (*) bei NMRA Betrieb im Gegensatz
zum Märklinbetrieb nie leerlaufen zu lassen, aber möglichst wenige
Bytes in der Pipeline zu haben, damit einerseits konstant Bytes zur
seriellen Schnittstelle rausrutschen aber wegen det Verzögerung nicht
zuviel alte Bytes in der Bearbeitung sind.

(*)
Linux tty write buffer: PAGE_SIZE, das sind wohl 4096 bytes
Serial Driver Ring buffer: 256 bytes
UART buffer: Je nach Hardware, oft 16 bytes

>      Vor jedem Check wird
>      eine gewisse Zeit gewartet. Erst wenn nichts mehr im Puffer
>      steht wird die Schleife verlassen.

Nee. Im NMRA Fall wird, wenn weniger als NUMBUFFERBYTES im (Tty-)
Puffer sind nicht gar nicht gewartet, und wenn mehr als NUMBUFFERBYTES
im Puffer sind etwas gewartet, daß die Bytes etwas Zeit haben an die
Lok zu kommen. Die Wartezeit hängt von der Anzahl der Bytes ab, eine
recht simple Annäherung, aber wahrscheinlich gut genug.

>      Warum ist die Funktion jetzt "besser"? 

Weil im NMRA Betrieb keine Lücken mehr auftreten. Im Mischbetrieb ist
alles wie vorher.

>      Anderes Problem: nanosleep() macht im Softrealtimemode
>      des Kernels ein busy-waiting. 

Nur unter 2msec. Siehe linux-2.4.12/kernel/timer.c, der Kommentar sagt
(und die Src stimmt sogar damit überein ;-) folgendes:

                 * Short delay requests up to 2 ms will be handled with
                 * high precision by a busy wait for all real-time processes.

Typische Zeiten die ich mit meiner Formel herausbekomme sind > 20msec,
die nicht mit udelay sondern mit schedule_timeout (der ist wohl nicht
"busy") gehandhabt werden.

>      So richtig genau ist es auch dann
>      noch  nicht. Ist nicht zu erwarten, dass die Prozessorlast
>      zu stark steigt? Hast Du das schon mal überprüft?

Bei meinem 300Mhz PII macht das keinen Unterschied, ich habe keinen
486:er zur Hand. Wahrscheinlich ist es schlimmer wenn man einen alten
UART ohne FIFO (UART dann bitte entsorgen) hat.

> (2) RingIndicator-Check, Kurzschlussprüfung

Ist nicht von mir, ACK-Schaltung (nicht Kurzschluß) durch RI ist von

    Date: Wed, 24 Jan 2001 17:02:24 +0100 (MET)
    From: "Wilhelm B. Kloke" <wb@vestein.arb-phys.uni-dortmund.de>
    Subject: Re: [DDL-ML] ACK-Schaltung

War das nicht außerdem ein Port auf (Free)BSD? Ist ja auch nett.

> (3) zusätzliche Kommandozeilenparameter. Ok, kann ich übernehmen.

Die Ordnung der Parameterauswertung habe ich auch etwas geändert, so
daß man für -h (usage) nicht root sein braucht.

Bei mir steht bei der Taufe von Parametern (hier -R -F) immer jemand
auf dem Schlauch, nehm irgend welche Buchstaben, die Dir gefallen.
Wenn das so weitergeht mit a-z und A-Z müssen wir auf lange Parameter
(z. B. --lazy-root --no-fork) umsteigen.

> Ich denke, das waren Deine Änderungen am erddcd. Hab ich was vergessen?

Ich hab' noch ein paar waitUARTempty() im NMRA Exekvierungspfad gezappt.

Harald.