COM port control signals

[Jakob Hirsch]

Hallo zusammen,

für ein privates Projekt brauche ich ein paar digitale Eingänge, wofür
ich einfach die Kontroll-Leitungen des COM-Ports nutzen wollte (CTS,
DSR, DCD, RI). Allerdings kann ich offenbar nur den aktuellen Status mit
ioctl() pollen, Mechanismen wie select() gibt es dafür wohl nicht(*).
Hab ich da was übersehen oder ist das tatsächlich so?


Grüße
Jakob


(*) Evt. ist das auch einfach eine Hardware-Beschränkung, die sich in
der Software fortsetzt: Wenn bei Änderungen von DTR etc. kein Interrupt
erzeugt wird, bekommt der Kernel das garnicht mit und kann
dementsprechend auch niemand darüber benachrichtigen.

[Detlef Bosau]

On 01/20/2012 12:04 AM, Jakob Hirsch wrote:
> Hallo zusammen,
>
> für ein privates Projekt brauche ich ein paar digitale Eingänge, wofür
> ich einfach die Kontroll-Leitungen des COM-Ports nutzen wollte (CTS,
> DSR, DCD, RI). Allerdings kann ich offenbar nur den aktuellen Status mit
> ioctl() pollen, Mechanismen wie select() gibt es dafür wohl nicht(*).
> Hab ich da was übersehen oder ist das tatsächlich so?
>

Ich frage mich gerade, wieso man für die genannten Steuerleitungen so
etwas wie select() anbieten sollte.

Sofern ich das richtig sehe, reden wir hier von den Flußkontrollsignalen
einer seriellen Schnittstelle. Diese werden, sofern überhaupt, von den
Schnittstellenbausteinen verarbeitet und sind dem Betriebssystem und
aufliegenden Schichten völligegal. Ich finde es schon bemerkenswert, daß
man darauf überhaupt mit ioctl() zugreifen kann, abgesehen vielleicht
noch von RI. Aber der Rest? Das möchte man doch eigentlich der Hardware
überlassen.

[Stefan Reuther]

Detlef Bosau wrote:
> On 01/20/2012 12:04 AM, Jakob Hirsch wrote:
>> für ein privates Projekt brauche ich ein paar digitale Eingänge, wofür
>> ich einfach die Kontroll-Leitungen des COM-Ports nutzen wollte (CTS,
>> DSR, DCD, RI). Allerdings kann ich offenbar nur den aktuellen Status mit
>> ioctl() pollen, Mechanismen wie select() gibt es dafür wohl nicht(*).
>> Hab ich da was übersehen oder ist das tatsächlich so?
>
> Ich frage mich gerade, wieso man für die genannten Steuerleitungen so
> etwas wie select() anbieten sollte.

Wenn's die Hardware erstmal kann (vorausgesetzt, sie kann es), stellt
sich für mich die Frage: warum nicht?

Vielleicht bin ich ja von einem gewissen Embedded-Betriebssystem aus
Santa Barbara verwöhnt, aber ich find es ganz ausgezeichnet, dass man
mit einem Systemaufruf auf Semaphoren, Timer, Interrupts, und eben Daten
warten kann. *ix ist da furchtbar eingeschränkt. Gleichzeitig auf
Semaphoren und Daten warten? Geht nicht. Mehrere Semaphoren? Geht nicht.

Linux hat da in neueren Kernels immerhin etwas nachgelegt (timerfd,
eventfd, signalfd).


Stefan

[Sven Geggus]

Jakob Hirsch <jh.expire...@plonk.de> wrote:

> für ein privates Projekt brauche ich ein paar digitale Eingänge, wofür
> ich einfach die Kontroll-Leitungen des COM-Ports nutzen wollte (CTS,
> DSR, DCD, RI). Allerdings kann ich offenbar nur den aktuellen Status mit
> ioctl() pollen, Mechanismen wie select() gibt es dafür wohl nicht(*).
> Hab ich da was übersehen oder ist das tatsächlich so?

Ich vermute mal, dass das tatsächlich nicht geht. Defacto ist das ja
eigentlich auch abuse bzgl. des COM-Ports.

Sagt der "Serial Programming Guide for POSIX Operating Systems" etwas
dazu?

http://www.easysw.com/~mike/serial/

Gruss

Sven

--
"Der wichtigste Aspekt, den Sie vor der Entscheidung für ein Open
Source-Betriebssystem bedenken sollten, ist, dass Sie kein
Windows-Betriebssystem erhalten." (von http://www.dell.de/ubuntu)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

[Jakob Hirsch]

Detlef Bosau, 2012-01-20 10:36:

>> für ein privates Projekt brauche ich ein paar digitale Eingänge, wofür
>> ich einfach die Kontroll-Leitungen des COM-Ports nutzen wollte (CTS,
>> DSR, DCD, RI). Allerdings kann ich offenbar nur den aktuellen Status mit
>> ioctl() pollen, Mechanismen wie select() gibt es dafür wohl nicht(*).
>> Hab ich da was übersehen oder ist das tatsächlich so?
> Ich frage mich gerade, wieso man für die genannten Steuerleitungen so
> etwas wie select() anbieten sollte.

Hab ich doch geschrieben: Weil ich nicht dauernd darauf pollen möchte.

> Sofern ich das richtig sehe, reden wir hier von den Flußkontrollsignalen
> einer seriellen Schnittstelle. Diese werden, sofern überhaupt, von den
> Schnittstellenbausteinen verarbeitet und sind dem Betriebssystem und
> aufliegenden Schichten völligegal. Ich finde es schon bemerkenswert, daß

Für einfache Anwendungen mag das ja sein. Da COM aber als unverselle
Schnittstelle ausgelegt ist, sollte man die Software-Schnittstelle nicht
unnötig begrenzen.

> man darauf überhaupt mit ioctl() zugreifen kann, abgesehen vielleicht noch von RI.

Mindestens noch DCD, zumindest bei Modems.

[Jakob Hirsch]

Sven Geggus, 2012-01-21 14:11:

>> ioctl() pollen, Mechanismen wie select() gibt es dafür wohl nicht(*).

> Ich vermute mal, dass das tatsächlich nicht geht. Defacto ist das ja
> eigentlich auch abuse bzgl. des COM-Ports.

Hachja, wenn man immer alles so benutzen würde, wie sich das jemand mal
gedacht :)

> Sagt der "Serial Programming Guide for POSIX Operating Systems" etwas
> dazu?

Leider nicht, da ist auch nur von ioctl() die Rede. Aber ein select()
wäre ja eigentlich auch nur sinnvoll, wenn es eine event queue dafür
gäbe. Es ist ja nicht garantiert, daß sich zwischen der Rückkehr von
select() und dem Aufruf von ioctl() der Zustand der Steuerleitung nicht
schon wieder ändert...

Naja, da das ganze ja nur für ein mehr oder weniger privates Projekt
ist, werd ich wohl auf was anderes ausweichen. Gibt ja einige Geräte mti
USB und digital I/O, allerdings meist nicht ganz billig. Für's erste
könnte ich mich auch einfach mal an Tasten einer billigen USB-Maus
hängen, das sollte klappen...

[Sieghard Schicktanz]

Hallo Jakob,

Du schriebst am Mon, 23 Jan 2012 10:47:57 +0100:

> > Sofern ich das richtig sehe, reden wir hier von den Flußkontrollsignalen

...

> Für einfache Anwendungen mag das ja sein. Da COM aber als unverselle

^^^ttyS?

> Schnittstelle ausgelegt ist, sollte man die Software-Schnittstelle nicht
> unnötig begrenzen.

_Nein_, die seriellen Schnittstellen sind _nicht_ auf universelle
Verwendung aller Hilfssignale ausgelegt - die sind darauf ausgelegt, Daten
seriell über wenige Leitungen zu übertragen. Die Hilfssignale sind _genau
das_, nämlich Hilfssignale zur _Übertragungssteuerung_, nicht für alles
mögliche andere, und im Prinzip _nur_ für interne Verwendung vorgesehen.
Nur für spezielle Anwendungen geben ein paar Zusatzfunktionen noch weitere
Steuerungsmöglichkeiten im _Umfeld_ der eigentlichen Übertragung - während
die Daten "laufen", sollte da keiner mehr dran 'rumfummeln.

--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

[Detlef Bosau]

On 01/23/2012 10:47 AM, Jakob Hirsch wrote:
> Detlef Bosau, 2012-01-20 10:36:
>>> für ein privates Projekt brauche ich ein paar digitale Eingänge, wofür
>>> ich einfach die Kontroll-Leitungen des COM-Ports nutzen wollte (CTS,
>>> DSR, DCD, RI). Allerdings kann ich offenbar nur den aktuellen Status mit
>>> ioctl() pollen, Mechanismen wie select() gibt es dafür wohl nicht(*).
>>> Hab ich da was übersehen oder ist das tatsächlich so?
>> Ich frage mich gerade, wieso man für die genannten Steuerleitungen so
>> etwas wie select() anbieten sollte.
>
> Hab ich doch geschrieben: Weil ich nicht dauernd darauf pollen möchte.
>

Hm. Ich habe jetzt nicht in den Linux-Kern geschaut. Aber wenn ich es
richtig sehe, macht select() polling, es gibt ja sogar einen Aufruf poll().

Select macht möglicherweise kein ausschließliches polling, aber
letztlich prüft select ab, ob bei Filedeskriptoren, von denen man lesen
will, Daten verfügbar sind, und ob bei Fildeskriptoren, auf die man
schreiben will, Platz gibt. Für beides muß select() in die betreffenden
Pufferstrukturen schauen. Nur tust Du das nicht auf Anwendungsebene.

>> Sofern ich das richtig sehe, reden wir hier von den Flußkontrollsignalen
>> einer seriellen Schnittstelle. Diese werden, sofern überhaupt, von den
>> Schnittstellenbausteinen verarbeitet und sind dem Betriebssystem und
>> aufliegenden Schichten völligegal. Ich finde es schon bemerkenswert, daß
>
> Für einfache Anwendungen mag das ja sein. Da COM aber als unverselle
> Schnittstelle ausgelegt ist, sollte man die Software-Schnittstelle nicht
> unnötig begrenzen.

Nun, eine COM Schnittstelle ist kein Userport vom C64. Und ein Sinn von
I/O Bausteinen ist doch, die CPU zu entlasten und vor allem I/O Vorgänge
zeitlich von der CPU zu entkoppeln.

[Rainer Weikusat]

Detlef Bosau <detlef...@web.de> writes:
> On 01/23/2012 10:47 AM, Jakob Hirsch wrote:
>> Detlef Bosau, 2012-01-20 10:36:
>>>> für ein privates Projekt brauche ich ein paar digitale Eingänge, wofür
>>>> ich einfach die Kontroll-Leitungen des COM-Ports nutzen wollte (CTS,
>>>> DSR, DCD, RI). Allerdings kann ich offenbar nur den aktuellen Status mit
>>>> ioctl() pollen, Mechanismen wie select() gibt es dafür wohl nicht(*).
>>>> Hab ich da was übersehen oder ist das tatsächlich so?
>>> Ich frage mich gerade, wieso man für die genannten Steuerleitungen so
>>> etwas wie select() anbieten sollte.
>>
>> Hab ich doch geschrieben: Weil ich nicht dauernd darauf pollen möchte.
>>
>
> Hm. Ich habe jetzt nicht in den Linux-Kern geschaut. Aber wenn ich es
> richtig sehe, macht select() polling, es gibt ja sogar einen Aufruf
> poll().
>
> Select macht möglicherweise kein ausschließliches polling, aber
> letztlich prüft select ab, ob bei Filedeskriptoren, von denen man
> lesen will, Daten verfügbar sind, und ob bei Fildeskriptoren, auf die
> man schreiben will, Platz gibt. Für beides muß select() in die
> betreffenden Pufferstrukturen schauen. Nur tust Du das nicht auf
> Anwendungsebene.

Der Unterschied ist der das poll-Mechanimus (der diese
Funktionalitaet zur Verfuegung stellt) nicht dauernd oder mit eine
festen Frequenz alle Deskriptoren abklappert, um eine Statusaenderung
festzustellen, sondern dass der ausfuehrende Prozess normalerweise
schlaeft und im Falle einer solchen Statusaenderung aufgeweckt
wird. 'poll' ist der traditionelle Name des synchronen
I/O-Multiplexing-Aufrufes der zusammen mit STREAMS in System, V
eingefuehrt wurde. Da Linux STREAMS ohnehin nicht unterstuetzt, ist er
funktional gleichwertig zu select mit einem etwas weniger hirntoten
Interface.

[Detlef Bosau]

On 01/23/2012 08:44 PM, Rainer Weikusat wrote:

>
> Der Unterschied ist der das poll-Mechanimus (der diese
> Funktionalitaet zur Verfuegung stellt) nicht dauernd oder mit eine
> festen Frequenz alle Deskriptoren abklappert,

Na, die normale Timerroutine wird mehr oder weniger genau das machen,
oder nicht?

> um eine Statusaenderung
> festzustellen, sondern dass der ausfuehrende Prozess normalerweise
> schlaeft und im Falle einer solchen Statusaenderung aufgeweckt
> wird.

Richtig. "Oben" wird geschlafen. "Unten" läuft das Doing ;-)

[Rainer Weikusat]

Da 'laeuft' aber nichts: Bei Eintritt in poll laeuft der Prozess
ueber alle Dateibeschreiber, die der Systemaufruf handhaben sollte
wobei er jeweils an eine Warteschlange angefuegt wird und danach der
momentane Zustand des Filedescriptors ermittelt wird. Ist zur Zeit
keine I/O moeglich, aendert der Prozess seinen Zustand auf
TASK_INTERRUPTIBLE und ruft den scheduler auf, damit der jemand
anderen findet, der Rechenzeit moechte. Dann passiert weiter nichts
bis 'irgendwo' Daten ankommen (oder wieder Speicher zum Puffern von zu
sendenden Daten zur Verfuegung steht). Das entsprechende Ereignis
ergibt sich als Steiteneffekt einer Interrupt-Routine oder von
Datenverarbeitung, die von einer Interrupt-Routine angestossen wurde
(zB der Netztwerk-SoftIRQ) und diese Interrupt-Routine (oder von einer
Interrupt-Routine ...) ist dafuer verwantwortlich, einen
wake_up-Aufruf fuer 'ihre' Warteschlange zu machen, was bewirkt, dass
der Zustand des schlafenden Prozesses sich zu TASK_RUNNABLE aendert
weswegen der scheduler ihn 'demnaechst' wieder ausfuehren wird (in der
Form das der schedule-Aufruf, der den Schlaf einleitete,
zurueckkehrt). Danach erfolgt (meines Wissens nach) eine erneute
Ueberpruefung aller relevanten Dateisbeschreiber sowie eine Rueckkehr
in den userspace falls jetzt etwas zu tun ist. Andernfalls beginnt der
naechste Wartezyklus. Zumindestens gilt das fuer alle Datenquellen und
-senken, die interruptgetriebene Ein- und Ausgabe unterstuetzen
(wenigstens eine Sorte SCSI-Adapter, von der ich ca 1998 mal ein
Exemplar fuer einen Scanner benutzt habe, konnte das nicht und wurde
deswegen in konfigurierbaren Abstaenden vom Treiber abgefragt).

NB: Das hier ist verschiedentlich vereinfacht.

[Sven Geggus]

Jakob Hirsch <jh.expire...@plonk.de> wrote:

> Leider nicht, da ist auch nur von ioctl() die Rede. Aber ein select()
> wäre ja eigentlich auch nur sinnvoll, wenn es eine event queue dafür
> gäbe.

Ich glaube ehrlich gesagt nicht einmal, dass es einen hardwaremäßigen
Interrupt dafür gibt, der ja Voraussetzung für den select im Userland ist,
wenn man nicht im Kernel ebenfalls pollen möchte. Allenfalls für den "Ring
Indicator" könnte es einen geben.

> Naja, da das ganze ja nur für ein mehr oder weniger privates Projekt
> ist, werd ich wohl auf was anderes ausweichen. Gibt ja einige Geräte mti
> USB und digital I/O, allerdings meist nicht ganz billig.

Für langsame Sachen ist 1-wire ganz net. Allerdings geht das prinzipbedingt
auch nur mit Polling.

Gruss

Sven

--
Microsoft ist offenbar die einzige Firma, die in der Lage ist, ein mit
Office nicht kompatibles Bürosoftwarepaket einzuführen.
(Florian Weimer in de.alt.sysadmin.recovery)

[Sven Geggus]

Detlef Bosau <detlef...@web.de> wrote:

> Hm. Ich habe jetzt nicht in den Linux-Kern geschaut. Aber wenn ich es
> richtig sehe, macht select() polling, es gibt ja sogar einen Aufruf poll().

Poll und select sind auf Kernel API Ebene das selbe. Ob das nun intern mit
polling oder über Interrupts gelöst ist hängt von der Hardware und vom
Treiber ab. Bides gibt es. Bei der seriellen Schnittstelle über die wir
gerade diskutieren werden schon Interrupts verwendet, allerdings eben nur
beim eigentlichen Einsatzzweck also dem Lesen und schreiben von Daten über
/dev/ttySX und nicht wenn man die Steuerleitungen als GPIO mißbraucht.

Gruss

Sven

--
"We just typed make"
(Stephen Lambrigh, Director of Server Product Marketing at Informix
about porting their Database to Linux)

[Hergen Lehmann]

On 24.01.2012 09:51, Sven Geggus wrote:

>> Leider nicht, da ist auch nur von ioctl() die Rede. Aber ein select()
>> wäre ja eigentlich auch nur sinnvoll, wenn es eine event queue dafür
>> gäbe.
>
> Ich glaube ehrlich gesagt nicht einmal, dass es einen hardwaremäßigen
> Interrupt dafür gibt, der ja Voraussetzung für den select im Userland ist,

Doch, den gibt es. Die 8250-Chips des IBM-Designs und ihre Nachfolger
beherrschen kein RTS/CTS-Handshake in Hardware, das muss(te) in Software
auf Grundlage eben jenes Interrupt implementiert werden.

Was fehlt, ist die event queue. Wenn es denn unbedingt sein muss, könnte
man hier mit einem gepatchten Kernel-Treiber nachrüsten.

> wenn man nicht im Kernel ebenfalls pollen möchte. Allenfalls für den "Ring
> Indicator" könnte es einen geben.

Der Interrupt triggert bei jeder Änderung der Statusleitungen.

>> Naja, da das ganze ja nur für ein mehr oder weniger privates Projekt
>> ist, werd ich wohl auf was anderes ausweichen. Gibt ja einige Geräte mti
>> USB und digital I/O, allerdings meist nicht ganz billig.
>
> Für langsame Sachen ist 1-wire ganz net. Allerdings geht das prinzipbedingt
> auch nur mit Polling.

Nunja... es gibt mittlerweile eine breite Auswahl an Microcontrollern
mit USB. Und es gibt für langsame Dinge sogar USB "low speed"
Implementierungen in Software, die auch kleine Controller der Preislage
<1Eur erschliessen.

Das ist dann sicher die elegantere Lösung, weil man auf PC-Seite keine
Polling-Schweinerei und keine Legacy-Schnittstellen mehr braucht.

Hergen

[Detlef Bosau]

On 01/23/2012 09:47 PM, Rainer Weikusat wrote:

> Das entsprechende Ereignis
> ergibt sich als Steiteneffekt einer Interrupt-Routine oder von
> Datenverarbeitung, die von einer Interrupt-Routine angestossen wurde
> (zB der Netztwerk-SoftIRQ) und diese Interrupt-Routine (oder von einer
> Interrupt-Routine ...) ist dafuer verwantwortlich, einen
> wake_up-Aufruf fuer 'ihre' Warteschlange zu machen,

O.k., das war das entscheidende, was ich nicht gesehen habe.

Dann werden die polls nicht regelmäßig gemacht sondern "irgend" ein
Socket/File/was auch immer, bzw. der von dort ausgelöste Interrupt löst
dann das Abprüfen aus. Verstanden.

> was bewirkt, dass
> der Zustand des schlafenden Prozesses sich zu TASK_RUNNABLE aendert
> weswegen der scheduler ihn 'demnaechst' wieder ausfuehren wird (in der
> Form das der schedule-Aufruf, der den Schlaf einleitete,
> zurueckkehrt). Danach erfolgt (meines Wissens nach) eine erneute
> Ueberpruefung aller relevanten Dateisbeschreiber sowie eine Rueckkehr
> in den userspace falls jetzt etwas zu tun ist.

Aber dann erfolgt das nicht regelmäßig per Timer sondern es braucht ein
Initialereignis.

[Rainer Weikusat]

Hergen Lehmann <hlehmann.e...@snafu.de> writes:

[...]

>> Für langsame Sachen ist 1-wire ganz net. Allerdings geht das prinzipbedingt
>> auch nur mit Polling.
>
> Nunja... es gibt mittlerweile eine breite Auswahl an Microcontrollern
> mit USB. Und es gibt für langsame Dinge sogar USB "low speed"
> Implementierungen in Software, die auch kleine Controller der
> Preislage <1Eur erschliessen.
>
> Das ist dann sicher die elegantere Lösung, weil man auf PC-Seite keine
> Polling-Schweinerei und keine Legacy-Schnittstellen mehr braucht.

USB ist technisch gesehen ein LAN bei dem die
'Kommunikationsberechtigung' von einem Chip im Host verwaltet wird,
der mit einer festen Frequenz allen Geraeten, die verbunden sind, der
Reihe nach ein 'Token' zuteilt, worauf sie den Bus benutzen duerfen,
insofern sie das gerade wollen sollten (vereinfacht), dh das ist genau
und nichts anderes als 'Polling-Schweinerei', allerdings in Form
dafuer spezialisierter Hardware die (vermutlich zum ausgesprochen
Widerwillen der Entwickler) host-seitig mit Interrupts arbeitet weil
diese 'Software-Leute' - Gott weiss warum - das eben wollen.

Das einzige elegante an USB ist, wie man mittels geballter Marktmacht
der Proponenten mal eben 20 Jahre technichen Fortschritt im Bereich
lokale Netzwerke erfolgreich eliminieren kann, weil man ohnehin von
Anfang an der Ansicht war, sie haetten eigentlich nie stattfinden
duerfen.

[Detlef Bosau]

On 01/24/2012 10:37 AM, Hergen Lehmann wrote:
> On 24.01.2012 09:51, Sven Geggus wrote:
>
>
> Doch, den gibt es. Die 8250-Chips des IBM-Designs und ihre Nachfolger
> beherrschen kein RTS/CTS-Handshake in Hardware, das muss(te) in Software
> auf Grundlage eben jenes Interrupt implementiert werden.
>

Mit entsprechenden Folgen. Interrupts können durchaus mit Verzögerung
abgearbeitet werden. Wir hatten das vor Wochen in der ISDN Gruppe, was
eine ISDN Karte eigentlich soll, wozu die nötig ist.

Der generelle Zweck aller I/O Karten ist und bleibt store & forward. Da
ist (wie auch immer bezeichnet) ein gemeinsamer Speicher, auf den
Außenweld und CPU asynchron zugreifen können.

> Was fehlt, ist die event queue. Wenn es denn unbedingt sein muss, könnte
> man hier mit einem gepatchten Kernel-Treiber nachrüsten.

Aber damit meinst Du bitte keine Queue für ankommende Bytes oder sowas?

[Rainer Weikusat]

Rainer Weikusat <rwei...@mssgmbh.com> writes:

[...]

> Da 'laeuft' aber nichts: Bei Eintritt in poll laeuft der Prozess
> ueber alle Dateibeschreiber, die der Systemaufruf handhaben sollte
> wobei er jeweils an eine Warteschlange angefuegt wird und danach der
> momentane Zustand des Filedescriptors ermittelt wird. Ist zur Zeit
> keine I/O moeglich, aendert der Prozess seinen Zustand auf
> TASK_INTERRUPTIBLE und ruft den scheduler auf, damit der jemand
> anderen findet, der Rechenzeit moechte.

Diese Darstellung ist in einem wesentlichen Punkt falsch: Wenn das so
implementiert waere, wie ich es beschrieben habe, wuerde ein wake_up
fuer eine Warteschlange, der stattfaende, nachdem dieser Deskriptor
'gepollt' wurde aber bevor der Scheduler aufgerufen wuerde,
verlorengehen (Konjunktiv ohne Gewaehr :-). Tatsaechlich aendert der
Prozess seinen Zustand auf TASK_INTERRUPTIBLE bevor er sich die
Dateibeschreiber ansieht. Ein zwischenzeitlicher wake_up wuerde dann
den Zustand zurueck auf TASK_RUNNABLE setzten, was den scheduler
veranlassen wuerde, direkt zum aufrufenden Prozess zurueckzukehren.

[Hergen Lehmann]

On 24.01.2012 13:54, Rainer Weikusat wrote:

> USB ist technisch gesehen ein LAN bei dem die
> 'Kommunikationsberechtigung' von einem Chip im Host verwaltet wird,
> der mit einer festen Frequenz allen Geraeten, die verbunden sind, der
> Reihe nach ein 'Token' zuteilt, worauf sie den Bus benutzen duerfen,

Token-basierte Netzwerke sind ein durchaus legitimes Konzept, das gerade
in Echtzeitanwendungen Vorteile gegenüber opportunistischen Konzepten
(wie z.B. Ethernet) hat.

> insofern sie das gerade wollen sollten (vereinfacht), dh das ist genau
> und nichts anderes als 'Polling-Schweinerei', allerdings in Form
> dafuer spezialisierter Hardware die

Dir ist aber schon klar, wo der entscheidende Vorteil einer
standardisierten Hardwarelösung gegenüber softwaregesteuertem Polling liegt?

> Das einzige elegante an USB ist, wie man mittels geballter Marktmacht
> der Proponenten mal eben 20 Jahre technichen Fortschritt im Bereich
> lokale Netzwerke erfolgreich eliminieren kann,

USB war ursprünglich als flexibler Ersatz für die Legacy-Schnittstellen
(RS232, Centronics, PS/2) konzipiert, insofern geht dieser Vorwurf recht
weit am Ziel vorbei. Dies insbesondere im Kontext dieses Thread, in dem
es *nicht* um lokale Netzwerke, sondern um eine einfache IO-Aufgabe geht.

Ich stimme dir aber zu, daß man es bei solchen einfachen IO-Aufgaben
hätte belassen sollen. Für breitbandige Anwendungen wie Massenspeicher
oder LAN gibt es geeignetere Schnittstellen. Aber um solche Anwendungen
geht es hier nicht.

> weil man ohnehin von
> Anfang an der Ansicht war, sie haetten eigentlich nie stattfinden
> duerfen.

Pauschalisierte Feindbilder sind was Schönes, gelle?

Hergen

[Rainer Weikusat]

Hergen Lehmann <hlehmann.e...@snafu.de> writes:
> On 24.01.2012 13:54, Rainer Weikusat wrote:
>
>> USB ist technisch gesehen ein LAN bei dem die
>> 'Kommunikationsberechtigung' von einem Chip im Host verwaltet wird,
>> der mit einer festen Frequenz allen Geraeten, die verbunden sind, der
>> Reihe nach ein 'Token' zuteilt, worauf sie den Bus benutzen duerfen,
>
> Token-basierte Netzwerke sind ein durchaus legitimes Konzept, das
> gerade in Echtzeitanwendungen Vorteile gegenüber opportunistischen
> Konzepten (wie z.B. Ethernet) hat.

Wie ich unten bereits geschrieben hatte: "weil man ohnehin von Anfang

an der Ansicht war, sie haetten eigentlich nie stattfinden

duerfen". Fuer ausreichend abstruse Einssatzszenarien mag Deine
Aussage zutreffen, darueber masse ich mir kein Urteil an, aber zum
Transport von Audiodaten, die unter Benutzung eines 'opportunistischen
Konzepts' wie zB PCI ('wer zuerst kommt, mahlt zuerst'), Ethernet (NAS)
oder gar via Internet-Streaming bei einem PC ankommen zu einem
'Ausgabegeraet' (das waere 'die USB Echtzeitanwendung') ist das
jedenfalls nicht noetig.

>> insofern sie das gerade wollen sollten (vereinfacht), dh das ist genau
>> und nichts anderes als 'Polling-Schweinerei', allerdings in Form
>> dafuer spezialisierter Hardware die
>
> Dir ist aber schon klar, wo der entscheidende Vorteil einer
> standardisierten Hardwarelösung gegenüber softwaregesteuertem Polling
> liegt?

Fuer die Charakteristik des 'Datenkommunikationsmodells' (dh
"Polling-Schweinere" oder "keine Polling-Schweinerei") ist es egal ob
die 'Schweinerei' von Hardware oder Software durchgefuehrt
wird. Obiges waere ein anderer Aspekt. Uebrigens hattest Du
ausdruecklich 'USB-Softwareimplementierungen' erwaehnt.

>> Das einzige elegante an USB ist, wie man mittels geballter Marktmacht
>> der Proponenten mal eben 20 Jahre technichen Fortschritt im Bereich
>> lokale Netzwerke erfolgreich eliminieren kann,
>
> USB war ursprünglich als flexibler Ersatz für die
> Legacy-Schnittstellen (RS232, Centronics, PS/2) konzipiert, insofern
> geht dieser Vorwurf recht weit am Ziel vorbei. Dies insbesondere im
> Kontext dieses Thread, in dem es *nicht* um lokale Netzwerke, sondern
> um eine einfache IO-Aufgabe geht.

Das aendert nichts daran, das 'der USB' ein LAN ist, mit dessen Hilfe
unabhaengige Computer Daten austauschen.

[Hergen Lehmann]

On 25.01.2012 00:09, Rainer Weikusat wrote:

> [viel wirres Zeug]

Ich halte es für müssig, über die Eignung von USB für LAN, NAS und
Streaming zu philosophieren, wenn die Frage darin bestand, ein paar
einfache digitale IOs an einen PC anzubinden.

*Dafür* wurde USB einst geschaffen und ist dafür ist es (durch die
Verfügbarkeit billiger, steckerfertiger Singlechip-Lösungen) heute mehr
denn je optimal.

EOD.

Hergen

[Detlef Bosau]

On 01/25/2012 12:09 AM, Rainer Weikusat wrote:
> Hergen Lehmann<hlehmann.e...@snafu.de> writes:
>> On 24.01.2012 13:54, Rainer Weikusat wrote:
>>
>>> USB ist technisch gesehen ein LAN bei dem die
>>> 'Kommunikationsberechtigung' von einem Chip im Host verwaltet wird,
>>> der mit einer festen Frequenz allen Geraeten, die verbunden sind, der
>>> Reihe nach ein 'Token' zuteilt, worauf sie den Bus benutzen duerfen,
>>
>> Token-basierte Netzwerke sind ein durchaus legitimes Konzept, das
>> gerade in Echtzeitanwendungen Vorteile gegenüber opportunistischen
>> Konzepten (wie z.B. Ethernet) hat.
>
> Wie ich unten bereits geschrieben hatte: "weil man ohnehin von Anfang
> an der Ansicht war, sie haetten eigentlich nie stattfinden
> duerfen".

Wer war da welcher Ansicht und was hätte nie stattfinden dürfen?
Entschuldige bitte, aber das klingt mir nach einer reichlich abstrusen
Verschwörungstheorie.

> Fuer ausreichend abstruse Einssatzszenarien mag Deine
> Aussage zutreffen, darueber masse ich mir kein Urteil an, aber zum
> Transport von Audiodaten, die unter Benutzung eines 'opportunistischen
> Konzepts' wie zB PCI ('wer zuerst kommt, mahlt zuerst'), Ethernet (NAS)
> oder gar via Internet-Streaming bei einem PC ankommen zu einem
> 'Ausgabegeraet' (das waere 'die USB Echtzeitanwendung') ist das
> jedenfalls nicht noetig.
>

Opportunistische Netze sind nicht echtzeitfähig. So einfach ist das.

>>
>> USB war ursprünglich als flexibler Ersatz für die
>> Legacy-Schnittstellen (RS232, Centronics, PS/2) konzipiert, insofern
>> geht dieser Vorwurf recht weit am Ziel vorbei. Dies insbesondere im
>> Kontext dieses Thread, in dem es *nicht* um lokale Netzwerke, sondern
>> um eine einfache IO-Aufgabe geht.
>
> Das aendert nichts daran, das 'der USB' ein LAN ist, mit dessen Hilfe
> unabhaengige Computer Daten austauschen.

USB ist kein LAN.

In LAN sind alle Stationen gleichberechtigt. Entweder ist das rein peer
to peer oder ich habe eine zentrale Steuerung.

USB verbindet keine Rechner, USB verbindet einen Rechner mit Endgeräten.
Die im übrigen, anders als im LAN, auch nicht ohne weiteres
untereinander kommunizieren können. Es ist eben nur eine
Rechner/Peripherie-Kommunikatin angedacht.

Was Du dann mit Handständen drüberstellst, ist eine andere Frage.

[Rainer Weikusat]

Hergen Lehmann <hlehmann.e...@snafu.de> writes:
> On 25.01.2012 00:09, Rainer Weikusat wrote:
>> [viel wirres Zeug]
>
> Ich halte es für müssig, über die Eignung von USB für LAN, NAS und
> Streaming zu philosophieren, wenn die Frage darin bestand, ein paar
> einfache digitale IOs an einen PC anzubinden.

In diesem Zusammenhang hattest Du 'USB' als 'besonders elegante
Loesung' vorgeschlagen. Und das ist 'USB' nun mal nicht. Es ist eine
ausgesprochen komplizierte und (auf Software-Ebene) kompliziert zu
benutzende Technologie (jemals Code fuer einen HCD-Treiber gesehen
oder gar damit gearbeitet?) die zudem noch auf konzeptuell
simpler 'Brutaltechnologie' basiert: Der Host-Kontroller wandert
staendig ueber den kompletten Bus um festzustellen ob eines der
angeschlossenen Geraete ihn gerade benutzten moechte und 'alle paar
Jahre' wird die Geschwindigkeit, mit der das geschieht, erhoeht, um
trotz der in diesem Entwurf inherenten Defizite 'mehr Bandbreite'
anbieten zu koennen.

> *Dafür* wurde USB einst geschaffen und ist dafür ist es (durch die
> Verfügbarkeit billiger, steckerfertiger Singlechip-Lösungen) heute
> mehr denn je optimal.

Das geht schlecht, denn 'optimal' ist bereits ein Superlative und als
solcher nicht steigerbar.

[Detlef Bosau]

On 01/25/2012 12:54 PM, Rainer Weikusat wrote:
>
> In diesem Zusammenhang hattest Du 'USB' als 'besonders elegante
> Loesung' vorgeschlagen. Und das ist 'USB' nun mal nicht. Es ist eine
> ausgesprochen komplizierte und (auf Software-Ebene) kompliziert zu
> benutzende Technologie (jemals Code fuer einen HCD-Treiber gesehen
> oder gar damit gearbeitet?) die zudem noch auf konzeptuell

Das würde mich mal interessieren, was daran so schlimm sein soll.

> simpler 'Brutaltechnologie' basiert: Der Host-Kontroller wandert
> staendig ueber den kompletten Bus um festzustellen ob eines der
> angeschlossenen Geraete ihn gerade benutzten moechte und 'alle paar

Nun, wenn ich Geräte mit harten QoS Anforderungen, wie etwa eine WebCam,
an dem Zeug betreiben möchte, werde ich um eine zentrale
Zugriffssteuerung nicht herum kommen. Das ist z.B. im WLAN auch nicht
anders.

> Jahre' wird die Geschwindigkeit, mit der das geschieht, erhoeht, um
> trotz der in diesem Entwurf inherenten Defizite 'mehr Bandbreite'
> anbieten zu koennen.

Welche Defizite sind das? Und vor allem: Wie sehen die Alternativen aus?

[Rainer Weikusat]

Detlef Bosau <detlef...@web.de> writes:
> On 01/25/2012 12:54 PM, Rainer Weikusat wrote:
>>
>> In diesem Zusammenhang hattest Du 'USB' als 'besonders elegante
>> Loesung' vorgeschlagen. Und das ist 'USB' nun mal nicht. Es ist eine
>> ausgesprochen komplizierte und (auf Software-Ebene) kompliziert zu
>> benutzende Technologie (jemals Code fuer einen HCD-Treiber gesehen
>> oder gar damit gearbeitet?) die zudem noch auf konzeptuell
>
> Das würde mich mal interessieren, was daran so schlimm sein soll.

Darueber sollte eigentlich schon eine geeignete
Programmierdokumentation Aufschluss geben, andernfalls bliebe da noch
der Code fuer eine solchen: Der 'core'-Teil des USB-Supports in dem
Linux-kernel, den mein Arbeitgeber zur Zeit benutzt, umfasst 12,438
Zeilen Code. Das ist fuer einen Teil eines Geraetetreibers 'mehr als
ordentlich' viel.

>> simpler 'Brutaltechnologie' basiert: Der Host-Kontroller wandert
>> staendig ueber den kompletten Bus um festzustellen ob eines der
>> angeschlossenen Geraete ihn gerade benutzten moechte und 'alle paar
>
> Nun, wenn ich Geräte mit harten QoS Anforderungen, wie etwa eine
> WebCam, an dem Zeug betreiben möchte, werde ich um eine zentrale
> Zugriffssteuerung nicht herum kommen. Das ist z.B. im WLAN auch nicht
> anders.

Falls diese Geraete mit anderen Geraeten an einem Bus haengen,
theoretisch wohl schon. Praktisch geht es auch ohne: Ein ziemlich
populaeres Beispiel waere 'Voice over IP' (und es gibt natuerlich auch
'Echtzeit' Video- und Audiostreaming 'ueber das Internet').

>> Jahre' wird die Geschwindigkeit, mit der das geschieht, erhoeht, um
>> trotz der in diesem Entwurf inherenten Defizite 'mehr Bandbreite'
>> anbieten zu koennen.
>
> Welche Defizite sind das?

ZB muss ein Geraet das sogenannte 'bulk'-Datenuebertragungen macht
(lustigerweise tun das dem Hoerensagen nach zB viele
USB<->Serial-Konverter) warten, bis der Hostkontroller das naechste
Mal 'vorbeikommt'. Die Dauer dieser Wartezeit haengt von der Anzahl der
angeschlossenen anderen Geraete ab und es muss auch dann gewartet
werden, wenn keines dieser anderen Geraete den Bus benutzen moechte.

[Detlef Bosau]

On 01/25/2012 05:48 PM, Rainer Weikusat wrote:

> Falls diese Geraete mit anderen Geraeten an einem Bus haengen,
> theoretisch wohl schon. Praktisch geht es auch ohne: Ein ziemlich
> populaeres Beispiel waere 'Voice over IP' (und es gibt natuerlich auch
> 'Echtzeit' Video- und Audiostreaming 'ueber das Internet').
>

Was hat Voice over IP damit zu tun? Sorry, aber Du verwechselst hier
gerade die Schichten. Für QoS sind erstmal Schicht 1 und 2 zuständig.
Der Rest sollte es nur nicht verschlimmern.

>
> ZB muss ein Geraet das sogenannte 'bulk'-Datenuebertragungen macht
> (lustigerweise tun das dem Hoerensagen nach zB viele
> USB<->Serial-Konverter) warten, bis der Hostkontroller das naechste
> Mal 'vorbeikommt'.

Ja und?

> Die Dauer dieser Wartezeit haengt von der Anzahl der
> angeschlossenen anderen Geraete ab und es muss auch dann gewartet
> werden, wenn keines dieser anderen Geraete den Bus benutzen moechte.

O.k., ich fragte ja nach Alternativen. Was könnte man nun konkret besser
machen?

[Rainer Weikusat]

Detlef Bosau <detlef...@web.de> writes:
> On 01/25/2012 05:48 PM, Rainer Weikusat wrote:
>> Falls diese Geraete mit anderen Geraeten an einem Bus haengen,
>> theoretisch wohl schon. Praktisch geht es auch ohne: Ein ziemlich
>> populaeres Beispiel waere 'Voice over IP' (und es gibt natuerlich auch
>> 'Echtzeit' Video- und Audiostreaming 'ueber das Internet').
>
> Was hat Voice over IP damit zu tun?

Es demonstriert, das gerade die 'Echtzeitanwendung', die Du genannt
hattest, auch ohne 'zentrale Kontrolle' auskommt ...

> Sorry, aber Du verwechselst hier gerade die Schichten. Für QoS sind
> erstmal Schicht 1 und 2 zuständig. Der Rest sollte es nur nicht
> verschlimmern.

... denn soetwas wie auch nur annaehernd durchgehende
'Qualitaetskontrolle' auf irgendeiner 'Schicht' gibt es 'im Internet',
das bekanntlich ein Verbund unabhaengiger Netze ist, nun mal
nicht. Ich hatte angenommen, diese Eigenschaft sei allgemein bekannt
('zufaelligerweise' habe ich auch schon mal einen RTP-Empfaenger fuer
'Echtzeitstreaming' von Fernsehdaten ueber $internet geschrieben und
ausgiebig zu Testzwecken benutzt und auch der funktionierte ueber ein
'universitaetsuebliches' Ethernetgewirr und auch fuer Uebertragungen
aus den USA leidlich gut --- 2002 und ohne jegliche Form von 'QoS auf
Schicht bla').

>> ZB muss ein Geraet das sogenannte 'bulk'-Datenuebertragungen macht
>> (lustigerweise tun das dem Hoerensagen nach zB viele
>> USB<->Serial-Konverter) warten, bis der Hostkontroller das naechste
>> Mal 'vorbeikommt'.
>
> Ja und?

Wenn Du das Problem dabei ernsthaft nicht verstehst (was ich um
uebrigen keine Sekunde lang glaube) darfst Du auch gerne meinem Wort
vertrauen.

>> Die Dauer dieser Wartezeit haengt von der Anzahl der
>> angeschlossenen anderen Geraete ab und es muss auch dann gewartet
>> werden, wenn keines dieser anderen Geraete den Bus benutzen moechte.
>
> O.k., ich fragte ja nach Alternativen.

Bin ich irgendjemandes Wikipedia-Vorleser?

[Detlef Bosau]

On 01/25/2012 07:27 PM, Rainer Weikusat wrote:
> Detlef Bosau<detlef...@web.de> writes:
>> On 01/25/2012 05:48 PM, Rainer Weikusat wrote:
>>> Falls diese Geraete mit anderen Geraeten an einem Bus haengen,
>>> theoretisch wohl schon. Praktisch geht es auch ohne: Ein ziemlich
>>> populaeres Beispiel waere 'Voice over IP' (und es gibt natuerlich auch
>>> 'Echtzeit' Video- und Audiostreaming 'ueber das Internet').
>>
>> Was hat Voice over IP damit zu tun?
>
> Es demonstriert, das gerade die 'Echtzeitanwendung', die Du genannt
> hattest, auch ohne 'zentrale Kontrolle' auskommt ...
>

Nein, das tut es gerade nicht.

Es demonstriert vielmehr, daß bei Gesprächen, wo kein vernünftiger QoS
sichergestellt ist, reichlich Störungen und Aussetzer auftreten.

>> Sorry, aber Du verwechselst hier gerade die Schichten. Für QoS sind
>> erstmal Schicht 1 und 2 zuständig. Der Rest sollte es nur nicht
>> verschlimmern.
>
> ... denn soetwas wie auch nur annaehernd durchgehende
> 'Qualitaetskontrolle' auf irgendeiner 'Schicht' gibt es 'im Internet',

Definitiv _nein_.

Grundsätzlich kannst Du QoS, der in den unteren Schichten verloren geht,
in den aufliegenden Schichten selbst mit dem größten Aufwand nicht
zurückholen. Redundanz und Robustheit muß von unten kommen, sowohl
"horizontal", i.e. von Hop zu Hop, als auch "vertikal" durch die
Schichten zehrst Du ausschließlich von vorhandener Substanz.

> das bekanntlich ein Verbund unabhaengiger Netze ist, nun mal
> nicht. Ich hatte angenommen, diese Eigenschaft sei allgemein bekannt

Nein. Sie ist auch falsch.

Du verwechselst gerade "das Internet" mit "einem Internet", und ich kann
sehr wohl Verbundnetze aufbauen, in denen eine QoS Sicherung vorliegt.

Das kann man tun - und man tut es auch.

> ('zufaelligerweise' habe ich auch schon mal einen RTP-Empfaenger fuer
> 'Echtzeitstreaming' von Fernsehdaten ueber $internet geschrieben und
> ausgiebig zu Testzwecken benutzt und auch der funktionierte ueber ein
> 'universitaetsuebliches' Ethernetgewirr und auch fuer Uebertragungen
> aus den USA leidlich gut --- 2002 und ohne jegliche Form von 'QoS auf
> Schicht bla').
>

Wenn Du mal einen RTP Empfänger geschrieben hast, dann weißt Du, daß RTP
mit QoS Sicherung definitiv nichts zu tun hat.

Mit RTP kannst Du vorhandene und fristgerecht zugestellte Pakete
zeitkonsistent zusammenbauen. Fehlende, beschädigte Pakete kannst Du
aber nicht ergänzen bzw. reparieren, verspätete Pakete kannst Du wegwerfen.

>>> ZB muss ein Geraet das sogenannte 'bulk'-Datenuebertragungen macht
>>> (lustigerweise tun das dem Hoerensagen nach zB viele
>>> USB<->Serial-Konverter) warten, bis der Hostkontroller das naechste
>>> Mal 'vorbeikommt'.
>>
>> Ja und?
>
> Wenn Du das Problem dabei ernsthaft nicht verstehst (was ich um
> uebrigen keine Sekunde lang glaube) darfst Du auch gerne meinem Wort
> vertrauen.
>

Ich weiß nicht, warum Du mich jetzt ad hominem angreifst.

Ich sehe kein Problem mut Bulk-Übertragungen. Sofern diese in
zugebilligte Sendezeiten passen, werden sie übertragen, wenn nicht, dann
nicht. Und man kann selbstverständlich Datenbüschel entweder in kleinere
Pakete aufteilen (bei seriellen Datenströmen ist das kein problem) -
oder, wenn es gar nicht anders geht, Daten, die man nicht übertragen
kann, verwerfen. Letzteres ist die Standardmethode.

Wenn ein Medium im Wettbewerb genutzt wird, und das ist bei USB der
Fall, muß man halt Konflikte lösen und Entscheidungen treffen.

>>> Die Dauer dieser Wartezeit haengt von der Anzahl der
>>> angeschlossenen anderen Geraete ab und es muss auch dann gewartet
>>> werden, wenn keines dieser anderen Geraete den Bus benutzen moechte.
>>
>> O.k., ich fragte ja nach Alternativen.
>
> Bin ich irgendjemandes Wikipedia-Vorleser?

Nein. Und ich denke auch nicht, daß Rumklicken in Wikipedia uns hier
sonderlich weiterführt.

[Stefan Reuther]

Hergen Lehmann wrote:
> On 24.01.2012 13:54, Rainer Weikusat wrote:
>> Das einzige elegante an USB ist, wie man mittels geballter Marktmacht
>> der Proponenten mal eben 20 Jahre technichen Fortschritt im Bereich
>> lokale Netzwerke erfolgreich eliminieren kann,
>
> USB war ursprünglich als flexibler Ersatz für die Legacy-Schnittstellen
> (RS232, Centronics, PS/2) konzipiert, insofern geht dieser Vorwurf recht
> weit am Ziel vorbei.

Wobei USB eben gerade *nicht* RS232 und Centronics ersetzt, sondern die
Anwendungen "Maus anschließen" und "Drucker anschließen". Das sieht man
ja gerade an den "COM port control signals". Mal eben zeitnah einen
Interrupt bekommen, wenn sich da was tut, ist mit USB nun endgültig
hardwareseitig nicht mehr möglich.


Stefan

[Stefan Reuther]

Detlef Bosau wrote:
> On 01/25/2012 05:48 PM, Rainer Weikusat wrote:
>> Falls diese Geraete mit anderen Geraeten an einem Bus haengen,
>> theoretisch wohl schon. Praktisch geht es auch ohne: Ein ziemlich
>> populaeres Beispiel waere 'Voice over IP' (und es gibt natuerlich auch
>> 'Echtzeit' Video- und Audiostreaming 'ueber das Internet').
>
> Was hat Voice over IP damit zu tun? Sorry, aber Du verwechselst hier
> gerade die Schichten. Für QoS sind erstmal Schicht 1 und 2 zuständig.
> Der Rest sollte es nur nicht verschlimmern.

Eben. Und in der Praxis funktioniert "Voice over IP" aka "Skype" und
"Videostreaming" aka "Youtube" auch einfach so, ohne QoS. Jedenfalls
solange, wie das Netz noch Reserven hat.

Solange das Netz Reserven hat, funktioniert auch USB. Aber ein PC mit 6
Hubs á 6 USB-Serial-Konvertern überlebt keine Nacht. Auch wenn Protokoll
und Bandbreite das prinzipiell hergeben.

>> ZB muss ein Geraet das sogenannte 'bulk'-Datenuebertragungen macht
>> (lustigerweise tun das dem Hoerensagen nach zB viele
>> USB<->Serial-Konverter) warten, bis der Hostkontroller das naechste
>> Mal 'vorbeikommt'.
>
> Ja und?

Der Implementierer fragt dann natürlich sofort: wie lange kann das
dauern? Wie groß muss mein Puffer sein? Was mache ich, wenn es wider
Erwarten länger dauert?

Und der Nutzer fragt sich dann: wie lange muss ich auf mein gesendetes
Byte warten?

>> Die Dauer dieser Wartezeit haengt von der Anzahl der
>> angeschlossenen anderen Geraete ab und es muss auch dann gewartet
>> werden, wenn keines dieser anderen Geraete den Bus benutzen moechte.
>
> O.k., ich fragte ja nach Alternativen. Was könnte man nun konkret besser
> machen?

Zum Beispiel statt den Hostcontroller im Kreis laufen zu lassen
Interrupts hochmelden.


Stefan

[Detlef Bosau]

On 01/25/2012 06:59 PM, Stefan Reuther wrote:
> Detlef Bosau wrote:
>> On 01/25/2012 05:48 PM, Rainer Weikusat wrote:
>>> Falls diese Geraete mit anderen Geraeten an einem Bus haengen,
>>> theoretisch wohl schon. Praktisch geht es auch ohne: Ein ziemlich
>>> populaeres Beispiel waere 'Voice over IP' (und es gibt natuerlich auch
>>> 'Echtzeit' Video- und Audiostreaming 'ueber das Internet').
>>
>> Was hat Voice over IP damit zu tun? Sorry, aber Du verwechselst hier
>> gerade die Schichten. Für QoS sind erstmal Schicht 1 und 2 zuständig.
>> Der Rest sollte es nur nicht verschlimmern.
>
> Eben. Und in der Praxis funktioniert "Voice over IP" aka "Skype" und
> "Videostreaming" aka "Youtube" auch einfach so, ohne QoS. Jedenfalls
> solange, wie das Netz noch Reserven hat.

QoS durch Unterlastung. Du beschreibst das im Parallelposting mit RS232
und Centronics sehr treffend und anschaulich, wo das Problem liegt.

>
> Solange das Netz Reserven hat, funktioniert auch USB. Aber ein PC mit 6
> Hubs á 6 USB-Serial-Konvertern überlebt keine Nacht. Auch wenn Protokoll
> und Bandbreite das prinzipiell hergeben.

Will heißen: Wenn mein Notebook keine serielle Schnittstelle mehr hat
und ich die mal brauche, um einen Router zu konfigurieren, tut dafür
ggf. auch mal ein Converter.

Aber das ganze stößt schnell an Grenzen.

>
>>> ZB muss ein Geraet das sogenannte 'bulk'-Datenuebertragungen macht
>>> (lustigerweise tun das dem Hoerensagen nach zB viele
>>> USB<->Serial-Konverter) warten, bis der Hostkontroller das naechste
>>> Mal 'vorbeikommt'.
>>
>> Ja und?
>
> Der Implementierer fragt dann natürlich sofort: wie lange kann das
> dauern? Wie groß muss mein Puffer sein? Was mache ich, wenn es wider
> Erwarten länger dauert?

Das ist ein norddeutsches Problem. Ich wohne in Stuttgart. Da dauert
sowas "gschwind". Und alles ist gesagt.

Und man lernt es, damit zu leben, daß gewisse Dinge gschwind dauern.

>
> Und der Nutzer fragt sich dann: wie lange muss ich auf mein gesendetes
> Byte warten?

Gschwind.

Er wartet halt gschwind.

>
>>> Die Dauer dieser Wartezeit haengt von der Anzahl der
>>> angeschlossenen anderen Geraete ab und es muss auch dann gewartet
>>> werden, wenn keines dieser anderen Geraete den Bus benutzen moechte.
>>
>> O.k., ich fragte ja nach Alternativen. Was könnte man nun konkret besser
>> machen?
>
> Zum Beispiel statt den Hostcontroller im Kreis laufen zu lassen
> Interrupts hochmelden.

Wobei man hier halt überlegen muß, ob sich das mit Echtzeitanforderungen
anderer Kanäle beißt.

Man muß halt eben ganz klar sagen, wozu sich eine Technologie eignet
(Maus, Drucker, WebCam, halt die handelsübliche ONU Peripherie geht gut)
und wozu nicht. (Eine serielle Punkt zu Punkt Verbindung zwischen zwei
Rechnern mit genau definierten QoS Eigenschaften wird man mit USB
vielleicht nicht ersetzen können.)

>
>
> Stefan
>

[Hergen Lehmann]

On 25.01.2012 18:52, Stefan Reuther wrote:

> Wobei USB eben gerade *nicht* RS232 und Centronics ersetzt, sondern die
> Anwendungen "Maus anschließen" und "Drucker anschließen".

Ja. Oder Modem oder Tastatur oder allerhand andere Schreibtisch-Gadgets...

> Das sieht man
> ja gerade an den "COM port control signals". Mal eben zeitnah einen
> Interrupt bekommen, wenn sich da was tut, ist mit USB nun endgültig
> hardwareseitig nicht mehr möglich.

Nunja... der Missbrauch von RS232-Steuerleitungen für zeitkritische IO
war ohnehin schon immer übelste Frickelei. Diese scheitert nicht nur bei
USB, sondern auch an diverser anderer Hardware jenseits des IBM-PC
kompatiblen Lagers und nicht zuletzt auch an den meisten modernen
Betriebssystemen.

Aber diese Frickelei hat man doch auch gar nicht mehr nötig!
Dank billiger, kleiner uC's und komfortabler Entwicklungstools für
dieselben geht heute viel mehr als nur ein einfacher Interrupt "wenn
sich was tut". Und im Fall von USB gibt es die Hostanbindung nebst
Kerneltreiber gleich gratis dazu.

Hergen

[Christian Weisgerber]

Stefan Reuther <stefa...@arcor.de> wrote:

> Solange das Netz Reserven hat, funktioniert auch USB. Aber ein PC mit 6
> Hubs á 6 USB-Serial-Konvertern überlebt keine Nacht.

??

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Jan Seiffert]

Hergen Lehmann schrieb:

> On 25.01.2012 18:52, Stefan Reuther wrote:
>
>> Wobei USB eben gerade *nicht* RS232 und Centronics ersetzt, sondern die
>> Anwendungen "Maus anschließen" und "Drucker anschließen".
>
> Ja. Oder Modem oder Tastatur oder allerhand andere Schreibtisch-Gadgets...
>
>> Das sieht man
>> ja gerade an den "COM port control signals". Mal eben zeitnah einen
>> Interrupt bekommen, wenn sich da was tut, ist mit USB nun endgültig
>> hardwareseitig nicht mehr möglich.
>
> Nunja... der Missbrauch von RS232-Steuerleitungen für zeitkritische IO war
> ohnehin schon immer übelste Frickelei. Diese scheitert nicht nur bei USB,
> sondern auch an diverser anderer Hardware jenseits des IBM-PC kompatiblen Lagers
> und nicht zuletzt auch an den meisten modernen Betriebssystemen.
>

Du kennst Puls-Per-Second Timesources?
Die geben einmal pro Sekunde eine Flanke, z.B von GPS oder dem DCF77, darauf
kann man dann den Servo-Loop des NTPD jagen.
In 2.6.3x sind die Patches für das PPS subsystem in den Linux Kernel
eingeflossen, unter anderem das er an interrupten von RS232 oder LPT eine
timestamp nimmt ;)
Mit einem DCF77 empfänger am RI oder DCD eines RS232 oder an einer der
Steureleitungen vom LPT bekommt man dann einen sync im Microsekundenbereich.

> Aber diese Frickelei hat man doch auch gar nicht mehr nötig!
> Dank billiger, kleiner uC's und komfortabler Entwicklungstools für dieselben
> geht heute viel mehr als nur ein einfacher Interrupt "wenn sich was tut".

Und wie bekommst du den interrupt in den PC?

> Und im Fall von USB gibt es die Hostanbindung nebst Kerneltreiber gleich gratis dazu.
>

Man kann obiges auch mit USB<->RS232 wandlern machen, der sync ist dann aber
nicht besser als 10-20 Millisekunden, eher noch schlechter.

> Hergen

Gruss
Jan

[Hergen Lehmann]

On 26.01.2012 01:38, Jan Seiffert wrote:

>> Aber diese Frickelei hat man doch auch gar nicht mehr nötig!
>> Dank billiger, kleiner uC's und komfortabler Entwicklungstools für dieselben
>> geht heute viel mehr als nur ein einfacher Interrupt "wenn sich was tut".
>
> Und wie bekommst du den interrupt in den PC?

Im Idealfall gar nicht, weil der zeitkritische Teil bereits im uC
abläuft, und nach oben nur noch ein zeitunkritisches Datenpaket (ggf.
mit Zeitstempel) 'rausfällt.

Ansonsten erlaubt selbst das "böse" USB eine garantierte
Interrupt-Latenz bis herunter zu 125 Mikrosekunden.
Das ist nicht gerade rekordverdächtig, aber besser bekommt das auch
keine andere serienmäßige, externe Schnittstelle eines PC hin. Wer es
schneller braucht, muss schon direkt auf den (PCI-)Bus gehen und braucht
zudem speziell auf die Anwendung zugeschnittene Kernel-Treiber.

Hergen

[Stefan Reuther]

Christian Weisgerber wrote:
> Stefan Reuther <stefa...@arcor.de> wrote:
>>Solange das Netz Reserven hat, funktioniert auch USB. Aber ein PC mit 6
>>Hubs á 6 USB-Serial-Konvertern überlebt keine Nacht.
>
> ??

Das bedeutet genau das was da steht. Wir brauchen hier 48x RS232 an
einem PC. Obiger Versuch hat zuverlässig recht schnell abgelebt. Was
letztlich funktionierte waren Mehrfach-USB-Serial-Konverter, die mehrere
RS232 auf ein USB-Device bringen, weil da der Host nicht mehr gar soviel
zu tun hat.


Stefan

[Jakob Hirsch]

Jakob Hirsch, 20.01.2012 00:04:
> für ein privates Projekt brauche ich ein paar digitale Eingänge, wofür
> ich einfach die Kontroll-Leitungen des COM-Ports nutzen wollte (CTS,
> DSR, DCD, RI). Allerdings kann ich offenbar nur den aktuellen Status mit
> ioctl() pollen, Mechanismen wie select() gibt es dafür wohl nicht(*).

Achja, lange ist's her :)

LinuxPPS hört sich interessant an, unterstützt aber wohl nur DCD, soweit
ich das verstanden habe, die Doku ist da etwas unklar (wie sonst auch).

Letztendlich hab ich einfach eine billige USB-Maus geschlachtet und
benutze die Mausbuttons. Das event interface von Linux' input subsystem
ist dafür ideal, aus /dev/input/eventX fällt jeweils ein event mit
zugehörigen timestamp raus, das ist genau das was ich brauche.

[Sven Geggus]

Jakob Hirsch <jh.expire...@plonk.de> wrote:

> Letztendlich hab ich einfach eine billige USB-Maus geschlachtet und
> benutze die Mausbuttons.

Jepp. Gamecontroller sind fast noch praktischer, weil die gleich eine
ganze Reihe von Tasten haben.

Gruss

Sven

--
"Ich fürchte mich nicht vor der Rückkehr der Faschisten in der Maske der
Faschisten, sondern vor der Rückkehr der Faschisten in der Maske der
Demokraten" (Theodor W. Adorno)