Received: by 10.68.238.198 with SMTP id vm6mr160351pbc.3.1327510108721;
        Wed, 25 Jan 2012 08:48:28 -0800 (PST)
Path: lh20ni222988pbb.0!nntp.google.com!news2.google.com!volia.net!news2.volia.net!feed-A.news.volia.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Rainer Weikusat <rweiku...@mssgmbh.com>
Newsgroups: de.comp.os.unix.programming
Subject: Re: COM port control signals
Date: Wed, 25 Jan 2012 16:48:27 +0000
Lines: 44
Message-ID: <87ty3j20f8.fsf@sapphire.mobileactivedefense.com>
References: <4f18a174$0$6639$9b4e6d93@newsspool2.arcor-online.net> <jfedh5$ba4$3@ultimate100.geggus.net> <4f1d9699$0$7611$9b4e6d93@newsspool1.arcor-online.net> <jflre5$qgq$1@ultimate100.geggus.net> <loa2v8-i67.ln1@hergen.dyndns.org> <87d3a9ntvs.fsf@sapphire.mobileactivedefense.com> <hmk3v8-9vq.ln1@hergen.dyndns.org> <87sjj4y9xj.fsf@sapphire.mobileactivedefense.com> <r0v3v8-grv.ln1@hergen.dyndns.org> <87ehuogfp3.fsf@sapphire.mobileactivedefense.com> <4f202178$0$7620$9b4e6d93@newsspool1.arcor-online.net>
Mime-Version: 1.0
X-Trace: individual.net PnUg8uYJ73cXFbnrCTJcRgKirZcvURm0tw0w2/fA9BTbB7+fM=
Cancel-Lock: sha1:BNbnW5iXpTaOTWXb2U0lUVhyKGo= sha1:t5AkQB1GIeh14gv4v9dh3XrHock=
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Detlef Bosau <detlef.bo...@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.