Re: [DDL-ML] Programmiergleis / ACK-Schaltung

[Michael Peschel <mipe@musoftware.de>]

On Thu, Mar 01, 2001 at 08:36:15AM +0100, Wilhelm B. Kloke wrote:

> In article <ifado.list.ddl/95BBA9CE85BAD211A79C0001FA7EF12502BDEBB1@txruws005.txch.sulzer.ch>,
> Pfiffner, Hanspeter <ddl-mailing-list@der-moba.de> wrote:
> >In der NMRA wird nur festgesetzt, dass das ACK-Signal mindestens 5 ms lang
> >anstehen muss. Nach oben wird keine Zeitbegrenzung angegeben.
> >Mit dem KO habe ich gemessen, dass bei mir das ACK-Signal ca. 120 ms
> >anstehen muss, damit es richtig erkannt wird (Rückgabewert 1). Wenn es nur
> >ca. 110 ms ansteht, erhalte ich Rückgabewert 0. Wenn es ca. 130 ms ansteht,
> >erhalte ich Rückgabewert 2. Es ist relativ schwierig, wenn nicht sogar
> >unmöglich mit einer einfachen Kondensatorladung den Schaltzeitpunkt
> >reproduzierbar so genau einzustellen.
>
> IMHO zutreffend. Ich bin dafür, 1. die Logik des Ack-Signals umzudrehen
> (d.h. positives statt negatives RI bei positivem ACK), 2. die Fähigkeit
> der Hardware, ein Signal dieser Polarität zu latchen, über das Betriebssystem
> auszunutzen. Ob das auch bei Linux eine kleine Änderung des Sio-Treibers
> verlangt, wie bei FreeBSD, weiß ich natürlich nicht. Aber diese Änderung
> wäre auch für jede andere Nutzung des RI-Signals sinnvoll.
> Ich habe das bei meiner FreeBSD-Portierung gemacht und bin mit der
> Stabilität sehr zufrieden.

Der normale serielle Treiber zaehlt bereits die Aenderungen unter anderem
der RI - Leitung (serial_icounter_struct). Wenn der Impuls kurz genug ist,
ist die Polaritaet prinzipiell egal. (Es wird dann halt auf die erste oder
letzte Flanke reagiert)
Zur Auswertung muss vor der Programmierung / Abfrage der RI-Zaehler ausgelesen
werden und danach nochmal. Unterscheiden sich die beiden Werte kann davon
ausgegangen werden dass ein ACK Impuls kam.

> >Ich arbeite mit SuSE Linux 7.0.
> >Meine Fragen an Torsten (und andere, die sich da auskennen):
> >a) Warum wird das ACK von der Software nicht erkannt, wenn es 110 ms ansteht
> >(nach NMRA wäre das ok)?
>
> Alle Unix-Derivate sind nicht uneingeschränkt realtime-fähig. Daher sind
> alle Programmiermethoden, die Timing mit Hilfe von nanosleep u.ä. auf
> Anwenderprogrammebene versuchen, prinzipiell unstabil.

Stimmt!
Linux ist in der "normalen" Ausfuehrung kein Echtzeit-Betriebssystem.

Bei der aktuellen Implementierung wird der RI-Port gepollt. Wann der Prozess
aber gerade pollt und ob er dabei gerade den "richtigen" Zustand erwischt
ist purer Zufall. Je laenger der Impuls umso groesser die Wahrscheinlichkeit.
Durch die weitere Bedingung aber, dass die RI Leitung nach dem erkennen auch
wieder weg sein muss damit auf ACK erkannt wird gehts bei einem zu langen
Impuls halt auch wieder schief. Abhilfe also nur durch die Auswertung
des RI-Zaehlers.


Michael Peschel