Mit Tachyonen und Gold-Chip gegen Handystrahlen...

Falk Brunner wrote:

USB = Low Cost Consumer Schnittstelle, nix Industriequalität.
Deshalb steht das 'U' ja auch fuer 'unstable'... Zumindest
USB2 ist immer noch instabil.

Gerrit
 
Falk Brunner wrote:
Falk Willberg schrieb:

Wurde im Büro und privat praktisch nicht benötigt. Und wo sie wirklich
benutzt wird, kommt dann eben kein Vista drauf. Ich glaube, daß 2008
deutlich mehr Uarts produziert werden, als vor zehn Jahren. Man sieht
sie nur nicht mehr.

Wo? Intergiert im Chipset? Für Embedded Anwendungen? In uCs?
Jo... die ganzen SoC haben normalerweise einen UART (*), die meisten
Microcontroller auch.

(*) Der ganze Kram, der mit embedded Linux laeuft laesst darueber die
Konsole laufen. Ist meist nicht rausgefuehrt aber auf der Platine
vorhanden. Pegelwandler und tut.

Eine RS232 ist fuer viele Anwendungen deutlich besser geeignet als
USB. Die serielle Konsole (schlaegt jede KVM-Loesung!) ist nur
eine solche Anwendung.

Gerrit
 
On Wed, 06 Feb 2008 11:29:55 +0100, Helmut Wabnig <hwabnig@ .- --- -.
DOT .- t> wrote:

BTW, Microsoft will die Serielle Schnittstelle ohnehin killen,
bei der Parallelen Schnittstelle haben sie schon angefangen,
kein VISTA Support.
<jammermode>
Und dann erklärt mir mal einer dieser Schlipse wie ich ohne tausend
verschiedene Treiber eben genausoviele unterschiedliche Geräte
programmieren soll??
</jammermode>

Aber zum Glück gibts ja USB-seriell-Adapter. (Mit denen ältere
Software meist zu 0% kompatibel ist) :-s

Heinz
 
Heinz Liebhart schrieb:
On Wed, 06 Feb 2008 11:29:55 +0100, Helmut Wabnig <hwabnig@ .- --- -.
DOT .- t> wrote:

BTW, Microsoft will die Serielle Schnittstelle ohnehin killen,
bei der Parallelen Schnittstelle haben sie schon angefangen,
kein VISTA Support.

jammermode
Und dann erklärt mir mal einer dieser Schlipse wie ich ohne tausend
verschiedene Treiber eben genausoviele unterschiedliche Geräte
programmieren soll??
/jammermode

Aber zum Glück gibts ja USB-seriell-Adapter. (Mit denen ältere
Software meist zu 0% kompatibel ist) :-s
Nach meiner Erfahrung ist USB-seriell ein vollkompatibler Ersatz für
ISA-seriell. (Es sei denn, man mißbraucht die Steuerleitungen...)

Parallel ist ganz anders, außer bei PCMCIA.

Falk
 
"Falk Willberg" <Faweglassenlk@falk-willberg.de> schrieb im Newsbeitrag
news:60u8saF1rqeraU1@mid.individual.net...
Nach meiner Erfahrung ist USB-seriell ein vollkompatibler Ersatz für
ISA-seriell. (Es sei denn, man mißbraucht die Steuerleitungen...)

Parallel ist ganz anders, außer bei PCMCIA.

Noe. Parallel ist genau so.

So lange du einen Drucker anschliesst und nicht die Steuerleitungen
missbrauchst (wie mein GalBlast).

Seriell, bei der die Stuerleitungen nicht zeitgenau bedient werden,
ist unbrauchbar, z.B. kein LiRC, kein PonyProg.

Allerdings ist auch parallel nicht mehr das, was parallel eigentlich
mal sein sollte, mein Epson MX80 geht am 2.8GHz PC nicht mehr, obwohl
beim XP Treiber beiliegen. Offenkuudig ist irgendwas zu schnell.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
 
Falk Willberg <Faweglassenlk@falk-willberg.de> wrote:

Nach meiner Erfahrung ist USB-seriell ein vollkompatibler Ersatz für
ISA-seriell. (Es sei denn, man mißbraucht die Steuerleitungen...)
Nein, haengt vom Protokoll ab. Es ist z.B problematisch wenn du 1Byte
uebertraegst und darauf 1Byte als Antwort erwartest und sich das immer
so wiederholt.

Olaf
 
MaWin fragte :

Allerdings ist auch parallel nicht mehr das, was parallel eigentlich
mal sein sollte, mein Epson MX80 geht am 2.8GHz PC nicht mehr, obwohl
beim XP Treiber beiliegen. Offenkuudig ist irgendwas zu schnell.
Schon mal im BIOS einen anderen Mode probiert? ECP/EPP/SDP...
Hat bei mir bei einem alten Scanner funktioniert.

LG
Andy
 
MaWin schrieb:
"Falk Willberg" <Faweglassenlk@falk-willberg.de> schrieb im Newsbeitrag
news:60u8saF1rqeraU1@mid.individual.net...
Nach meiner Erfahrung ist USB-seriell ein vollkompatibler Ersatz für
^^^^^^^ ^^^^^^^^^^^^^^^
ISA-seriell. (Es sei denn, man mißbraucht die Steuerleitungen...)

Parallel ist ganz anders, außer bei PCMCIA.


Noe. Parallel ist genau so.
Nein, seriell funktioniert (mit o.e. Einschränkungen) genauso, wie immer
schon.

So lange du einen Drucker anschliesst und nicht die Steuerleitungen
missbrauchst (wie mein GalBlast).

Seriell, bei der die Stuerleitungen nicht zeitgenau bedient werden,
ist unbrauchbar, z.B. kein LiRC, kein PonyProg.
Ich bilde mir ein, genau das geschrieben zu haben.

Allerdings ist auch parallel nicht mehr das, was parallel eigentlich
mal sein sollte, mein Epson MX80 geht am 2.8GHz PC nicht mehr, obwohl
beim XP Treiber beiliegen. Offenkuudig ist irgendwas zu schnell.
Seltsam, ein Samsung Multifunktionsgerät tut hier an 2x2,2GHz prima.

Falk
 
In article <60tnkqF1sf2r0U2@mid.individual.net>,
Falk Brunner <Falk.Brunner@gmx.de> writes:
|> >> Hasstriaden
|>
|> Hasstriaden

Was hat die chinesische Mafia da eigentlich mit zu tun? :p

Rainer
 
In article <4qqjq3dnqn9u4bhcjof42f32dm66i0v9p8@4ax.com>,
Heinz Liebhart writes:
|>
|> Aber zum Glück gibts ja USB-seriell-Adapter. (Mit denen ältere
|> Software meist zu 0% kompatibel ist) :-s

Jaaaa, aber nicht unbedingt für timing-kritische Geschichten, bei denen
die Portleitungen für irgendwelche Sonderfunktionen vergewaltigt werden.

Da ist dann mit USB-to-irgendwas recht schnell essig.

Rainer
 
Olaf Kaluza schrieb:
Falk Willberg <Faweglassenlk@falk-willberg.de> wrote:

Nach meiner Erfahrung ist USB-seriell ein vollkompatibler Ersatz für
ISA-seriell. (Es sei denn, man mißbraucht die Steuerleitungen...)

Nein, haengt vom Protokoll ab. Es ist z.B problematisch wenn du 1Byte
uebertraegst und darauf 1Byte als Antwort erwartest und sich das immer
so wiederholt.
Habe ich noch nicht beobachtet. Welches Problem tritt dabei auf?

Falk
 
Falk Willberg <Faweglassenlk@falk-willberg.de> wrote:

Nein, haengt vom Protokoll ab. Es ist z.B problematisch wenn du 1Byte
uebertraegst und darauf 1Byte als Antwort erwartest und sich das immer
so wiederholt.

Habe ich noch nicht beobachtet. Welches Problem tritt dabei auf?
Timingprobleme. Es kann dann sein das Wartezeiten ablaufen. Da muss
man dann schonmal etwas grosszuegiger einstellen. Soweit ich das
beobachten konnte ist das kein Problem wenn man den Source hat, aber
kann kritisch sein wenn du den nicht hast, z.B irgendwelche alte
Diagnosesoftware fuer Sachen die zwar laengst veraltet sind, die man
aber trotzdem noch dreimal im Jahr braucht.

Olaf
 
Olaf Kaluza schrieb:
Falk Willberg <Faweglassenlk@falk-willberg.de> wrote:

Nein, haengt vom Protokoll ab. Es ist z.B problematisch wenn du 1Byte
uebertraegst und darauf 1Byte als Antwort erwartest und sich das immer
so wiederholt.

Habe ich noch nicht beobachtet. Welches Problem tritt dabei auf?

Timingprobleme. Es kann dann sein das Wartezeiten ablaufen.
Ah ja. Das kann aber bei jedem Multitasking-System mit klassischem UART
passieren. Bei USB ist es natürlich kritischer.

Falk
 
Falk Willberg wrote:
Olaf Kaluza schrieb:
Falk Willberg <Faweglassenlk@falk-willberg.de> wrote:

Nein, haengt vom Protokoll ab. Es ist z.B problematisch wenn du 1Byte
uebertraegst und darauf 1Byte als Antwort erwartest und sich das immer
so wiederholt.

Habe ich noch nicht beobachtet. Welches Problem tritt dabei auf?

Timingprobleme. Es kann dann sein das Wartezeiten ablaufen.

Ah ja. Das kann aber bei jedem Multitasking-System mit klassischem UART
passieren. Bei USB ist es natürlich kritischer.
Vor allem weil ein USB-Device nicht melden kann, dass Daten
anliegen, es muss warten bis es vom Host gepollt wird.

Gerrit
 
Gerrit Heitsch schrieb:

Vor allem weil ein USB-Device nicht melden kann, dass Daten
anliegen, es muss warten bis es vom Host gepollt wird.
Was aber jede Millisekunde passieren kann. Bei 256 Byte Rx buffer sollte
das reichen, auch bei 115k2.

Mfg
Falk
 
Falk Brunner wrote:
Gerrit Heitsch schrieb:

Vor allem weil ein USB-Device nicht melden kann, dass Daten
anliegen, es muss warten bis es vom Host gepollt wird.

Was aber jede Millisekunde passieren kann. Bei 256 Byte Rx buffer sollte
das reichen, auch bei 115k2.
Aber nicht wenn das Timing eng ist. Ein echter UART liefert bei
115k2 ca. alle 86 Mikrosekunden ein Byte. Mit einem USB-Dongle ist das
nicht zu machen.

Gerrit
 
Gerrit Heitsch schrieb:
Falk Brunner wrote:
Gerrit Heitsch schrieb:

Vor allem weil ein USB-Device nicht melden kann, dass Daten
anliegen, es muss warten bis es vom Host gepollt wird.
Ich war _sehr_ verwundert, als ich erfuhr, daß USB keine Interrupts kennt.

Was aber jede Millisekunde passieren kann. Bei 256 Byte Rx buffer
sollte das reichen, auch bei 115k2.
Pollen[0] ist trotzdem Mist. So fängt man sich u.U. ein paar Millionen
sinnlose Operationen ein.

Aber nicht wenn das Timing eng ist. Ein echter UART liefert bei
115k2 ca. alle 86 Mikrosekunden ein Byte. Mit einem USB-Dongle ist das
nicht zu machen.
Ich glaube ja an das Gute und nehme deswegen an, daß USB-Dongles ein
passend dimensioniertes FIFO haben.

Falk
[0]Pollen: Du erwartest Besuch und die Klingel ist kaputt. Also schaust
Du öfter mal nach, ob jemand vor der Tür steht.
Interrupt: Die Klingel funktioniert.
DMA: Ein Brief wird eingeworfen.
DMA+Interrupt: Ein Brief wird eingeworfen und der Zusteller klingelt.
 
Falk Willberg schrieb:

ist trotzdem Mist. So fängt man sich u.U. ein paar Millionen
sinnlose Operationen ein.
Grundsätzliche Meinungen sind Mist. Pollen hat seine Daseinsberechtigung
und ist in einigen Szenarien (speziell Embedded Systems mit
Echtzeit-Constraints) sogar besser geeignet als Interruptsteuerung.

Viele Grüße,
Johannes

--
"PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen." -- Markus Gronotte aka Makus /
Kosst Amojan / maqqusz / Mr. G / Ferdinand Simpson / Quartillia
Rosenberg in dse <45608268$0$5719$9b4e6d93@newsspool3.arcor-online.net>
 
Falk Willberg wrote:
Gerrit Heitsch schrieb:
Falk Brunner wrote:
Gerrit Heitsch schrieb:

Vor allem weil ein USB-Device nicht melden kann, dass Daten
anliegen, es muss warten bis es vom Host gepollt wird.

Ich war _sehr_ verwundert, als ich erfuhr, daß USB keine Interrupts kennt.
Der USB-Controller selber meldet sich schon per IRQ bei der
CPU, aber ein USB-Device kann das eben nicht sondern muss
warten bis der Controller nachfragt.


Aber nicht wenn das Timing eng ist. Ein echter UART liefert bei
115k2 ca. alle 86 Mikrosekunden ein Byte. Mit einem USB-Dongle ist das
nicht zu machen.

Ich glaube ja an das Gute und nehme deswegen an, daß USB-Dongles ein
passend dimensioniertes FIFO haben.
Der FIFO ist schon passend, hilft dir aber nicht, wenn dein
Protokoll ein engeres Timing voraussetzt. Beim erwaehnten
Beispiel mit einem Byte welches mit einem Byte beantwortet
werden muss schaffst du mit USB einen maximalen Durchsatz von
500 Bytes/sec pro Richtung. Bei einem echten UART und 115k2
sind es hingegen in der Gegend von 5700 Bytes/sec.

Gerrit
 
Johannes Bauer schrieb:
Falk Willberg schrieb:

Pollen[0] ist trotzdem Mist. So fängt man sich u.U. ein paar Millionen
sinnlose Operationen ein.

Grundsätzliche Meinungen sind Mist. Pollen hat seine Daseinsberechtigung
Kein Widerspruch. Ich formuliere neu: "Pollen ist grundsätzlich, im
juristischen Sinne[0], Mist" ;-)

und ist in einigen Szenarien (speziell Embedded Systems mit
Echtzeit-Constraints) sogar besser geeignet als Interruptsteuerung.
Ack. Es kann auch bei uCs sinnvoll sein. Unter Betriebssystemen und GUIs
hat es IMO aber "grundsätzlich[0]" nichts zu suchen.

Falk
[0]Grundsätzlich := Eigentlich, meistens, im Wortlaut der reinen Lehre...
 

Welcome to EDABoard.com

Sponsor

Back
Top