Forum: Mikrocontroller und Digitale Elektronik Ungültige Kombinationen bei RS232


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Henrik L. (henrik_l)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich beschäftige mir zurzeit mit serieller Übertragung speziell RS232. 
Für die Kommunikation müssen ja die Parameter (Stopbits, Parität, ...) 
auf Sender- und Empfängerseite gleich eingestellt werden usw. Gewisse 
Kombinationen sind nicht zulässig, wie beispielsweise die Kombination 
aus 5 Datenbits und 2 Stopbits. Gibt es dafür eine allgemeine Regel für 
die unzulässigen Kombinationen? Ich würde diese gerne in meinem Programm 
im Voraus abfangen. Im Internet finde ich nichts passendes.

Vielen Dank schonmal für eure Hilfe!

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
Henrik L. schrieb:
> Gewisse Kombinationen sind nicht zulässig
Warum nicht?

> wie beispielsweise die Kombination aus 5 Datenbits und 2 Stopbits.
Bestenfalls kann dein Controller mit dieser unüblichen Konfiguration 
nichts anfangen. Aber keiner verbietet es dir, diese Kombination zu 
verwenden.

> Ich würde diese gerne in meinem Programm im Voraus abfangen.
Was für ein Programm ist das, dass man da Baudraten und Stopbits selber 
umbiegen kann?

: Bearbeitet durch Moderator
von Peter D. (peda)


Bewertung
2 lesenswert
nicht lesenswert
Henrik L. schrieb:
> wie beispielsweise die Kombination
> aus 5 Datenbits und 2 Stopbits.

Z.B. der ATmega48 kann das:
"Supports Serial Frames with 5, 6, 7, 8, or 9 Data Bits and 1 or 2 Stop 
Bits"

von Henrik L. (henrik_l)


Bewertung
0 lesenswert
nicht lesenswert
Ich lese die Konfigurationsparameter aus einer INI-Datei aus und würde 
gerne eine Fehlermeldung generieren, wenn die Kombination nicht zulässig 
ist. Die Info, dass es unzulässige Kombinationen gibt, habe ich aus 
folgenden Dokument (Seite 4):

https://tu-dresden.de/ing/elektrotechnik/ife/ressourcen/dateien/lehre/praktikum_computertechnik/Praktikumsanleitung.pdf?lang=de

: Bearbeitet durch User
von Percy N. (vox_bovi)


Bewertung
0 lesenswert
nicht lesenswert
Könnte diese Einschränkung obsolet sein, weil im Gegensatz zu 
Fernschreibern moderne Geräte nahezu beliebig getaktet werden können?

von Dussel (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mir ist bei RS-232 auch noch nie eine Einschränkung in der Richtung 
untergekommen (ich habe aber auch nicht viel damit gemacht), aber auch 
auf Wikipedia (was ja keine sichere Quelle ist), steht:
"The standard does not define such elements as the character encoding 
(i.e. ASCII, EBCDIC, or others), the framing of characters (start or 
stop bits, etc.), transmission order of bits, or error detection 
protocols."
https://en.wikipedia.org/wiki/RS-232

Sicherheit wird der Standard geben.

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
Nur eben nicht der Standard, der beschäftigt sich ja nur mit 
Signalpegeln und Pins. Witzigerweise ist das Datenformat anscheinend nur 
Tradition. Normal würde doch Wikipedia im UART- oder NRZ-Artikel einen 
Standard erwähnen? Die diversen Normen für Smart Meter, Modbus, Profibus 
usw. müssten alle auf die diese Norm verweisen. Zumindest in den 
Modbus-Specs steht nichts davon.

https://en.wikipedia.org/wiki/Universal_asynchronous_receiver-transmitter
https://en.wikipedia.org/wiki/Non-return-to-zero
https://en.wikipedia.org/wiki/Line_code
https://en.wikipedia.org/wiki/Serial_port

Es gibt bestimmt ein UART mit nur einem Control-Bit für die Anzahl der 
Stoppbits. Dadurch kann der Chip eben nur 5+1, 5+1.5, 6+1, 6+2 ... 8+1, 
8+2.

von Gret (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Ich wuerd mich mal mit der Standardeinstellung von 8,n,1 befassen. Der 
Rest hat sich nicht halten koennen

von Percy N. (vox_bovi)


Bewertung
1 lesenswert
nicht lesenswert
Solange mindestens so viele Stoppbits gesendet werden, wie der Empfänger 
erwartet, dürfte eigentlich nichts schief gehen.

von Philip S. (Firma: ueberblick industries) (ueberblick)


Bewertung
5 lesenswert
nicht lesenswert
https://tu-dresden.de/ing/elektrotechnik/ife/ressourcen/dateien/lehre/praktikum_computertechnik/Praktikumsanleitung.pdf?lang=de

> serielle Schnittstellen sind sehr weit verbreitet. Viele Sensoren mit digitalem 
Ausgang und eine Vielzahl von Messgeräten verwenden serielle Schnittstellen. Die 
am weitesten verbreitete serielle Schnittstelle ist die sogenannte RS232 oder 
V.24. Jeder Personalcomputer hat in der Regel zwei RS232-Schnittstellen. Die 
Bezeichnung _RS steht für Receive/Send_.

Allein dieser Absatz lässt mich schaudern. Da bekommt man gleich Lust 
den restlichen Text des Dokumentes zu ignorieren.

von Hubert Hansen (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Henrik L. schrieb:
> Gewisse Kombinationen sind nicht zulässig,

Warum? Ein Protokoll ist ein Vereinbarung, hier zwischen 2 Uarts. Da 
kannst du alles machen was beide Seiten können.

von Hmmm (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Henrik L. schrieb:
> Gewisse
> Kombinationen sind nicht zulässig, wie beispielsweise die Kombination
> aus 5 Datenbits und 2 Stopbits.

Du kannst auch 100 Stopbits senden, aus Sicht des Empfängers sind mehr 
als die erwarteten Stopbits einfach nur Pausen zwischen den Zeichen. Je 
nach Protokoll können die natürlich Auswirkungen haben, z.B. bei Modbus 
RTU.

Henrik L. schrieb:
> Gibt es dafür eine allgemeine Regel für
> die unzulässigen Kombinationen?

Das hängt vom verwendeten System (UART, ggf. Betriebssystem und Treiber) 
ab.

von Thomas S. (thschl)


Bewertung
0 lesenswert
nicht lesenswert
Henrik L. schrieb:
> ich beschäftige mir zurzeit mit serieller Übertragung speziell RS232.
> Ich würde diese gerne in meinem Programm
> im Voraus abfangen.

Ich mache sehr viel mir RS232 und RS485, aber wenn man nicht mal weiss 
was dein Programm machen soll, was willst du dann vrbieten? Bei meinem 
Terminal-Programm stellst du Parameter ein, wie du willst, wenn die 
Gegenseite das verträgt ist es gut. Da weiss ich nicht mit was du dich 
beschäftigst?

von Hannes J. (Firma: _⌨_) (pnuebergang)


Bewertung
3 lesenswert
nicht lesenswert
He, das kommt von einer Elite-Uni. Was kann man von denen schon 
erwarten?

Das dumme Statement kommt vermutlich von einer unzulässigen 
Verallgemeinerung. Der Held der diese Anleitung geschrieben hat hat 
vermutlich in das Datenblatt eines der erwähnten 16C450 oder 16C550 
gesehen und elitemäßig-messerscharf daraus geschlossen, dass kein UART 
das kann weil diese schimmeligen UARTS das nicht können (Beispiel 
TL16C450 https://www.ti.com/lit/gpn/tl16c450 Seite 19, Tabelle 6.).

von A. S. (achs)


Bewertung
2 lesenswert
nicht lesenswert
Percy N. schrieb:
> Solange mindestens so viele Stoppbits gesendet werden, wie der Empfänger
> erwartet, dürfte eigentlich nichts schief gehen.

Das ist entweder ziemlich sarkastisch ... Oder entlarvend.

Jedenfalls sind stoppbits nur für den Sender. Der Empfänger decodiert 
immer nur grob ein halbes.

 Das wird klar, wenn man einmal das asynchrone Timing durchspielt.

von PittyJ (Gast)


Bewertung
-5 lesenswert
nicht lesenswert
Ich habe die letzten 20 Jahre immer nur 8N1 erlebt.
Welche aktuelle Hardware macht irgendwas mit 5 oder 6 Bits? Da schiesst 
sich dessen Programmierer doch selbst ins Knie. Denn der will ja auch 
einfach an die Informationen kommen.

Vielleicht sollte man die Programm-Spezifikation an die Realität 
anpassen, und exotisches einfach mal ignorieren.

von Toby P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> Jedenfalls sind stoppbits nur für den Sender. Der Empfänger decodiert
> immer nur grob ein halbes.

Der Empfänger decodiert in der Regel gar keines. Nach dem letzten Bit 
wartet er auf das nächste Start Bit. Mehr als ein Stopbit braucht es um 
dem Empfänger Zeit zu geben die Daten zu verarbeiten (heute meist 
unnötig).

Ein halbes Bit ist auch nicht immer der Fall. Gute Empfänger oversampeln 
jedes Bit, messen z.B. 3 x den Pegel, was die Störfestigkeit erhöht.

>
>  Das wird klar, wenn man einmal das asynchrone Timing durchspielt.

Eben.

von Baku M. (baku)


Bewertung
0 lesenswert
nicht lesenswert
PittyJ schrieb:
> Ich habe die letzten 20 Jahre immer nur 8N1 erlebt.

Naja, 8E1 habe ich auch schon gesehen, manchmal ist es schön eine Parity 
zur Fehlererkennung zu haben.

5 Bits hingegen kenne ich nur vom alten Fernschreiber, der will dann 
aber auch 1,5 Stopbits sehen. Und setzt die Verwendung eines 
entsprechenden Codes (Baudot...) voraus. Habe ich seit mehr als 20 
Jahren nicht mehr gesehen, und wenn dann über eine Stromschleife und 
niemals mit RS232.

6 Bits ist mir im ganzen Leben (und das ist lang...) noch nicht 
untergekommen.
7 Bits nur bei wirklich steinaltem Zeug, das nur reines ASCII kann.

Sinnvolle Einstellungen sind mMn nur Even/Odd(exotisch)/No Parity, 1/2 
Stopbits (2 Stopbits erleichtern das einsysnchronisieren auf dauernde 
Datenströme) und 8 Datenbits (7, wenn man historische Dinge betreiben 
will).

IdS,
Baku

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
3 lesenswert
nicht lesenswert
Baku M. schrieb:
> (2 Stopbits erleichtern das einsysnchronisieren auf dauernde Datenströme)
2 Datenbits erhöhen die Wahrscheinlichkeit, dass man in einen dauernd 
laufenden Datenstrom "einfädeln" kann.
Aber erst nach einer Inaktivität mit einer Dauer aller Datenbits kann 
man in einen laufenden Datenstrom sicher aufsynchronisieren.

Hier sendet der Sender z.B. laufend 0xAA mit 8n1 und der Empfänger, der 
mitten im laufenden Datenstrom aktiv geschaltet (oder eingesteckt) 
wurde, empfängt mit einer Wahrscheinlichkeit von 75% laufend Blödsinn:
1
S = Startbit
2
0..7 = datenbits
3
s = stopbit
4
1001010101100101010110010101011001010101100101010110010101011001010....
5
 S01234567sS01234567sS01234567sS01234567sS01... => 0xAA, 0xAA, 0xAA....
6
    S01234567sS01234567sS01234567sS01234567s... => 0x35, 0x35, 0x35....
7
      S01234567sS01234567sS01234567sS0123456... => 0x4D, 0x4D, 0x4D....
8
        S01234567sS01234567sS01234567sS01234... => 0x53, 0x53, 0x53...
9
           S01234567sS01234567sS01234567sS01... => 0xAA, 0xAA, 0xAA....

Hier legt der laufend 0xAA sendende Sender eine längere Pause mit 8 Bits 
ein, sodass der "einfädelnde" Empfänger nach dem möglicherweise ersten 
falsch empfangenen Byte das nächste zuverlässig richtig synchronisieren 
kann:
1
S = Startbit
2
0..7 = datenbits
3
s = stopbit
4
1110010101011111111100101010111111111001010101111111111100101010111....
5
   S01234567s       S01234567s       S01234567s... => 0xAA, 0xAA, 0xAA....
6
      S01234567s    S01234567s       S01234567s... => 0x35, 0xAA, 0xAA....
7
        S01234567s  S01234567s       S01234567s... => 0x4D, 0xAA, 0xAA....
8
          S01234567sS01234567s       S01234567s... => 0x53, 0xAA, 0xAA...
9
                    S01234567s       S01234567s... => 0xAA, 0xAA, 0xAA....

von Olaf (Gast)


Bewertung
1 lesenswert
nicht lesenswert
> Ich habe die letzten 20 Jahre immer nur 8N1 erlebt.

Also ich hab auch schon 7E1 und 9N1 gesehen.

Interessanter finde ich heute aber was ganz anders. Was ist denn die 
maximal standardisierte Baudratenabweichung die man haben darf damit es 
garantiert nach Standard klappt. Also nicht gefuehlte praxistaugliche 
Werte, sondern echt garantierte. DA gibt es IMHO auch keine Werte. Dabei 
wird das in Seiten von fraktionalen Teilen und immer mehr Hardware wo 
RS232 nur noch ein kleines Anhaengsel in einem dicken System ist IMHO 
immer wichtiger.

Olaf

von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
Hannes J. schrieb:
> (Beispiel
> TL16C450 https://www.ti.com/lit/gpn/tl16c450 Seite 19, Tabelle 6.).

Wenn sich die Fragestellung auf einen konkreten Chip bezieht, dann muß 
man das aber auch dazu sagen.

Henrik L. schrieb:
> Gibt es dafür eine allgemeine Regel für
> die unzulässigen Kombinationen?

Darauf kann man also nur antworten: "Nein".

von Chris D. (myfairtux) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
PittyJ schrieb:
> Ich habe die letzten 20 Jahre immer nur 8N1 erlebt.
> Welche aktuelle Hardware macht irgendwas mit 5 oder 6 Bits? Da schiesst
> sich dessen Programmierer doch selbst ins Knie. Denn der will ja auch
> einfach an die Informationen kommen.
>
> Vielleicht sollte man die Programm-Spezifikation an die Realität
> anpassen, und exotisches einfach mal ignorieren.

Das kann je nach Anwendungsgebiet der Software sehr problematisch 
werden.

In vielen Industrieanlagen werkelt teilweise uralte Hardware 
(Servoumrichter, CNC-Steuerungen etc.) - und die wird sehr oft über 
RS-232 angesprochen.

Meine CNC hier lässt sich bspw. auch noch ausschließlich über RS-232 
füttern (man könnte sogar mit Lochstreifenleser arbeiten :-) und 
natürlich mache ich das inkl. Parity, einfach weil es richtig knallen 
kann, wenn ein Zeichen falsch übertragen wird. Natürlich wird das heute 
über Prüfsummen gemacht, damals gab's das aber noch nicht.

(Immerhin wird bei meiner Maschine bei erneuter Übertragung das neue mit 
dem alten Programm verglichen und bei Abweichung gemeckert - das erhöht 
die Sicherheit dann doch deutlich).

Wie schon andere schrieben, gibt es da keine Festlegung: alles ist als 
Protokoll möglich, so dass eine vernünftige Implementierung da auch alle 
Freiheiten geben sollte.

Nichts wäre blöder, als wenn er mit Aufwand vermeintlich nicht 
spezifizierte Einstellungen verbietet und dann ältere Hardware genau 
diese erwartet.

: Bearbeitet durch Moderator
von Erwin D. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Henrik L. schrieb:
> Gibt es dafür eine allgemeine Regel für
> die unzulässigen Kombinationen?

Ich würde das mal ganz kurz und bündig beantworten:
Weil es keine unzulässigen Kombinationen gibt, kann es auch keine 
allgemeingültigen Regeln dafür geben.
Den Grund dafür haben bereits mehrere Leute genannt.

von Peter D. (peda)


Bewertung
-1 lesenswert
nicht lesenswert
Ich hab auch schon viele Geräte gesehen, die einen USB-Anschluß haben. 
Wenn man den aber mit dem PC verbindet, taucht im Gerätemanager eine 
weitere COM auf. Der USB-Anschluß ist also nur eine Mogelpackung, d.h. 
ein fest eingebauter USB-COM Umsetzer (Silabs, FTDI, Prolific usw.).

von Cyblord -. (cyblord)


Bewertung
-2 lesenswert
nicht lesenswert
Peter D. schrieb:
> Der USB-Anschluß ist also nur eine Mogelpackung, d.h.
> ein fest eingebauter USB-COM Umsetzer (Silabs, FTDI, Prolific usw.).

Interessante Definition. Ein µC der USB-CDC macht, wäre also keine 
Mogelpackung? Ein fertiger ASIC mit der gleichen Funktionalität ist aber 
eine? Oder ist für dich das ganze USB-CDC gar kein echtes USB sondern 
eine Mogelpackung? Was ist für dich echtes USB? Bulk? HID? Welches 
Profil genügt dem?

: Bearbeitet durch User
von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Interessante Definition. Ein µC der USB-CDC macht, wäre also keine
> Mogelpackung?
Doch, im Grunde schon. Denn der µC hat eben keine serielle "COM" 
Schnittstelle (an der man mit dem Oszi was messen könnte) sondern 
gauckelt nur eine vor.

Warum meldet sich z.B. eine Maus nicht auch wie früher(tm) als 
"RS232-COM-Gerät" an? Warum wurde für Mäuse u.ä. eine spezielle 
"Eingabegeräteklasse" deklariert?

: Bearbeitet durch Moderator
von Cyblord -. (cyblord)


Bewertung
-1 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Doch, im Grunde schon. Denn der µC hat eben keine serielle "COM"
> Schnittstelle, sondern gauckelt nur eine vor.

PEDA sprach aber von einer Mogelpackung bezüglich USB, nicht bezüglich 
COM Schnittstelle.
Von Geräten die zwar ein USB Kabel haben, aber USB nur "vorgaukeln", 
weil da ein FT232 ö.ä. verbaut ist.

Beitrag #6464051 wurde vom Autor gelöscht.
von M. K. (sylaina)


Bewertung
2 lesenswert
nicht lesenswert
Olaf schrieb:
> Was ist denn die
> maximal standardisierte Baudratenabweichung die man haben darf damit es
> garantiert nach Standard klappt. Also nicht gefuehlte praxistaugliche
> Werte, sondern echt garantierte. DA gibt es IMHO auch keine Werte.

Naja, das liegt daran, weil die Abweichung vom Frame-Format abhängt und 
da gibts dann einige Kombinationen. Ich verwende stets die 1%-Regel da 
die eigentlich immer mehr als ausreichend ist. Aber man kann es sich ja 
auch mal ausrechnen. Nehmen wir mal 8N1 an. Dann haben wir 1 Startbit, 8 
Datenbits und ein Stoppbit. Jetzt muss man hier nur aufpassen, dass man 
nicht aus versehen in ein Nachbar-Bit rein tastet und Ziel sei es immer 
in der Mitte eines Bits "abzutasten". Man könnte also die Gleichung 
aufstellen:

Bei 8N1 käme da dann ~4% raus und diesen Fehler darf man auf Sender und 
Empfänger verteilen. In der Regel sind die gleichberechtigt und daher 
bekommt dann jeder ~2% (der eine könnte ja noch oben abweichen, der 
andere nach unten).
Beim größten Datenframe, dem 9E(O)2 käme da 1.92% raus, also etwa 0.96% 
für jede Seite. (daher sind meine immer verwendeten 1%)

Man muss es halt abhängig vom verwendeten Frame ausrechnen welche 
Abweichung zulässig ist.

von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Jetzt muss man hier nur aufpassen, dass man nicht aus versehen in ein
> Nachbar-Bit rein tastet und Ziel sei es immer in der Mitte eines Bits
> "abzutasten".

Du vergisst noch das viele UART 3 oder 5x abtasten und dann wohl eine 
Mehrheitsentscheidung bilden. Es geht also einiges.
Andererseits kenne ich auch MCU mit fraktionalem Teiler in der 
Biterzeugung. Da sind dann die einzelnen Bits unterschiedlich breit, 
aber der Mittelwert stimmt dann wieder.

Der entscheidende Punkt ist aber nicht was geht, sondern das es halt 
keinen Standard gibt. Es gibt nichts gegen das man testen kann um dann 
zu sagen so wird es immer funktionieren. Es gibt nur so allgemeine 
Erfahrungswerte die in der Praxis keine Probleme machen.
Auch mit den nicht ganz unueblichen 9 Datenbit kannst du schon auf MCUs 
treffen die das nicht mehr koennen.

Olaf

von Peter D. (peda)


Angehängte Dateien:

Bewertung
2 lesenswert
nicht lesenswert
Der kritische Fall ist, wenn der Sender zu schnell bzw. der Empfänger zu 
langsam ist. Dann kann das nächste Startbit verloren gehen. Daher ist 
mit 2 Stopbits eine größere Fehlersicherheit gegeben.
Anbei mal das Timing aus dem Datenblatt des ATtiny48.

von A. S. (achs)


Bewertung
1 lesenswert
nicht lesenswert
Toby P. schrieb:
> Der Empfänger decodiert in der Regel gar keines. Nach dem letzten Bit
> wartet er auf das nächste Start Bit. Mehr als ein Stopbit braucht es um
> dem Empfänger Zeit zu geben die Daten zu verarbeiten (heute meist
> unnötig).
>
> Ein halbes Bit ist auch nicht immer der Fall. Gute Empfänger oversampeln
> jedes Bit, messen z.B. 3 x den Pegel, was die Störfestigkeit erhöht.

Peter hat es schon allgemein geschrieben, ich gehe mal hier konkret 
drauf ein:

Der Empfänger braucht ungefähr "ein halbes" Stoppbit, da er es zwecks 
Framing-Kontrolle wirklich sampelt und das natürlich etwa in der Mitte 
des Stoppbits.

Danach schaltet er den StartBit-Detektorr wieder frei, da er sonst bei 
kleinen Baudratenunterschieden nach wenigen Bits rauslaufen würde.

Die Stoppbits sind NICHT für mehr Zeit zur Verarbeitung, sondern
- erhöhen die Wahrscheinlichkeit zum Einfädeln (wie Lothar schon 
schrieb)
- Geben eine kleine Taktreserve. Auf die will ich hier eingehen:

Wenn es z.b. 3 Abtastungen (Oversampling) gibt, mit 8 Takten pro Bit, 
dann erfolgen die bei etwa 3/8, 4/8 und 5/8. Wenn die ersten beiden gut 
sind, wird das dritte zwar nicht mehr gebraucht, blockiert aber meist 
noch die Startbit-Erkennung.

Wenn also der Sender ein paar Prozent schneller ist, Und das zweite 
Sample gerade schon das Startbit sehen würde, dann
- ist das Framing trotzdem OK
- summiert sich der Verzug nicht auf.

von Axel S. (a-za-z0-9)


Bewertung
2 lesenswert
nicht lesenswert
Peter D. schrieb:
> Ich hab auch schon viele Geräte gesehen, die einen USB-Anschluß haben.
> Wenn man den aber mit dem PC verbindet, taucht im Gerätemanager eine
> weitere COM auf. Der USB-Anschluß ist also nur eine Mogelpackung

Das erschließt sich mir nicht. CDC ist eine der standardisierten 
USB-Geräteklassen. Ein Gerät, das diese (und egal ob weitere oder nicht) 
Geräteklasse implementiert ist ein USB-Gerät.


Lothar M. schrieb:
> Warum meldet sich z.B. eine Maus nicht auch wie früher(tm) als
> "RS232-COM-Gerät" an? Warum wurde für Mäuse u.ä. eine spezielle
> "Eingabegeräteklasse" deklariert?

Das mußt du die Leute fragen, die den USB Standard gemacht haben. Aber 
nachdem es eine separate HID Geräteklasse gibt und eine Maus ein 
klassisches HID ist, war es nur folgerichtig, daß reine USB-Mäuse sich 
am USB als HID präsentieren.

von Peter D. (peda)


Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Das erschließt sich mir nicht. CDC ist eine der standardisierten
> USB-Geräteklassen.

Nun man erkauft sich damit alle Nachteile einer COM, ohne daß der 
Benutzer es erkennt. Das meine ich mit Mogelpackung.
Das USB-Kabel muß gesteckt werden, bevor man die Nutzersoftware startet, 
es darf nicht abgezogen werden, bevor diese beendet wurde und sie kann 
nicht erkennen, welche COM dem Gerät zugewiesen wurde.

von H.Joachim S. (crazyhorse)


Bewertung
0 lesenswert
nicht lesenswert
Baku M. schrieb:
> Odd(exotisch)

HART?

von Erwin D. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
H.Joachim S. schrieb:
> HART?

???

von Hannes J. (Firma: _⌨_) (pnuebergang)


Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Peter D. schrieb:
>> Ich hab auch schon viele Geräte gesehen, die einen USB-Anschluß haben.
>> Wenn man den aber mit dem PC verbindet, taucht im Gerätemanager eine
>> weitere COM auf. Der USB-Anschluß ist also nur eine Mogelpackung
>
> Das erschließt sich mir nicht. CDC ist eine der standardisierten
> USB-Geräteklassen. Ein Gerät, das diese (und egal ob weitere oder nicht)
> Geräteklasse implementiert ist ein USB-Gerät.

Na ja, sie philosophieren im Prinzip darüber warum man es bei USB 
"gewagt" hat eine Klasse zu definieren die sich dazu eignet (es gibt 
Einschränkungen) RS232 auf USB abzubilden.

Dazu muss man sagen dass CDC weit über eine Abbildung von RS232 auf USB 
hinaus geht. Das ist fast schon ein Nebenprodukt. CDC ist die 
Communications Device Class. Gedacht war die für Telefonie- und 
Netzwerk-Gerätschaften. Vom Telefon, Modem, X.25 (Datex-P), CAPI, 
Ethernet bis ATM kann man da alles drüber machen. Na ja, und da zum 
Beispiel viele klassische Modems RS232 hatten, hat man dafür gesorgt das 
man RS232-Verhalten über USB CDC abbilden kann. Man muss nur so tun als 
ob man das dümmste Modem aller Zeiten hat, dann hat man fast reines 
RS232.

> Lothar M. schrieb:
>> Warum meldet sich z.B. eine Maus nicht auch wie früher(tm) als
>> "RS232-COM-Gerät" an? Warum wurde für Mäuse u.ä. eine spezielle
>> "Eingabegeräteklasse" deklariert?
>
> Das mußt du die Leute fragen, die den USB Standard gemacht haben. Aber
> nachdem es eine separate HID Geräteklasse gibt und eine Maus ein
> klassisches HID ist, war es nur folgerichtig, daß reine USB-Mäuse sich
> am USB als HID präsentieren.

Es geht um das Verhalten der Klassen. Schnelle Reaktionszeit (HID) gegen 
hohen Datendurchsatz (CDC).

: Bearbeitet durch User
von Hannes J. (Firma: _⌨_) (pnuebergang)


Bewertung
3 lesenswert
nicht lesenswert
Peter D. schrieb:
> Nun man erkauft sich damit alle Nachteile einer COM, ohne daß der
> Benutzer es erkennt. Das meine ich mit Mogelpackung.
> Das USB-Kabel muß gesteckt werden, bevor man die Nutzersoftware startet,
> es darf nicht abgezogen werden, bevor diese beendet wurde und sie kann
> nicht erkennen, welche COM dem Gerät zugewiesen wurde.

Tschuldingung das ich das so deutlich sage, aber nur weil die 
Microsoft-Programmierer mal wieder zu blöd zum Scheißen waren und die 
Einbindung in Windows so mies ist heißt das nicht das das Probleme von 
CDC sind.

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
Hannes J. schrieb:
> Peter D. schrieb:
>> Nun man erkauft sich damit alle Nachteile einer COM, ohne daß der
>> Benutzer es erkennt. Das meine ich mit Mogelpackung.
>> Das USB-Kabel muß gesteckt werden, bevor man die Nutzersoftware startet,
>> es darf nicht abgezogen werden, bevor diese beendet wurde und sie kann
>> nicht erkennen, welche COM dem Gerät zugewiesen wurde.
>
> Tschuldingung das ich das so deutlich sage, aber nur weil die
> Microsoft-Programmierer mal wieder zu blöd zum Scheißen waren und die
> Einbindung in Windows so mies ist heißt das nicht das das Probleme von
> CDC sind.

Das ist nun Unsinn. Alle aufgeführten Nachteile resultieren direkt aus 
der COM emulation. COM kennt nun mal keine Serienummern von Geräten und 
kennt auch keine festen Portzuordnungen. Somit ist es legitim dass man 
den COM Port vor dem Einstecken nicht weiß.

von Hannes J. (Firma: _⌨_) (pnuebergang)


Bewertung
0 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Das ist nun Unsinn. Alle aufgeführten Nachteile resultieren direkt aus
> der COM emulation. COM kennt nun mal keine Serienummern von Geräten und
> kennt auch keine festen Portzuordnungen. Somit ist es legitim dass man
> den COM Port vor dem Einstecken nicht weiß.

Warum ist das jetzt die Schuld von USB-CDC? Das COM-Port Zeug ist eine 
Microsoft-Erfindung. Die haben sich für eine idiotische, sich immer 
wieder ändernde, dynamische COM-Portzuordnung entschieden.

Man hätte genauso gut allen USB-Ports an einem Windows-Rechner 
prophylaktisch einen COM-Port zuordnen können. Von mir aus im 
Uhrzeigersinn. Jede USB-Buchse prophylaktisch eine COM-Port Nummer. Wenn 
dann ein Gerät mit CDC-Klasse eingesteckt wird bekommt es den Port. Wird 
ein Gerät einer anderen Klasse eingesteckt, dann verbindet sich der 
festgelegte COM-Port nicht mit dem Gerät und verhält sich gegenüber 
einer Anwendung so als ob eben kein Kabel eingesteckt ist.

Man hätte die Anbindung an COM-Ports auch ganz lassen können und eine 
eigene Schnittstelle für USB-CDC schaffen können. Es ist kein 
Naturgesetz und steht nicht im Standard dass man das auf COM-Ports 
mappen muss.

Also hör auf zu Versuchen mit Microsoft-Scheiße als Schokolade zu 
verkaufen.

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
Hannes J. schrieb:

> Warum ist das jetzt die Schuld von USB-CDC?

ich rede nicht von Schuld und ich stimme PEDA nicht zu, der CDC als 
Mogelpackung bezeichnet. Aber MS ist auch nicht Schuld.

> Das COM-Port Zeug ist eine
> Microsoft-Erfindung. Die haben sich für eine idiotische, sich immer
> wieder ändernde, dynamische COM-Portzuordnung entschieden.

COM selbst definiert eben keine festen Zuordnungen über USB.

> Man hätte genauso gut allen USB-Ports an einem Windows-Rechner
> prophylaktisch einen COM-Port zuordnen können.

Also erstmal 128 virtuelle COM Ports anlegen, falls jemand 128 CDC 
ansteckt?
Das wäre ja toll.

> Jede USB-Buchse prophylaktisch eine COM-Port Nummer.

USB IST EIN BUS MIT bis zu 128 TEILNEHMERN! Egal wie viele Buchsen am PC 
sind.


> Man hätte die Anbindung an COM-Ports auch ganz lassen können und eine
> eigene Schnittstelle für USB-CDC schaffen können. Es ist kein
> Naturgesetz und steht nicht im Standard dass man das auf COM-Ports
> mappen muss.

DAS macht dann aber für alle Applikationen Probleme die COM nutzen 
wollen. COM ist ein toller gemeinsamer Nenner für viele einfache 
Applikationen. DAS nicht zu unterstützen ist typische Linuxer Grütze. 
Hauptsache die Ideologie stimmt. Praxis egal.

> Also hör auf zu Versuchen mit Microsoft-Scheiße als Schokolade zu
> verkaufen.

Kannst du deine MS Tiraden nicht für einen Linux vs. MS Thread 
aufsparen? Hier nervst du damit.

von Peter D. (peda)


Bewertung
2 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> ich stimme PEDA nicht zu, der CDC als
> Mogelpackung bezeichnet.

Hab ich auch nicht. Sondern, daß am Gerät ein USB rausschaut, drinne 
aber auf UART umgesetzt wird, mit den damit verbundenen Einschänkungen. 
Das ist die Mogelpackung.
Daß sowas CDC heißen soll, hat ein anderer gesagt.

von Toby P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Axel S. schrieb:

>
> Nun man erkauft sich damit alle Nachteile einer COM, ohne daß der
> Benutzer es erkennt. Das meine ich mit Mogelpackung.
> Das USB-Kabel muß gesteckt werden, bevor man die Nutzersoftware startet,
> es darf nicht abgezogen werden, bevor diese beendet wurde

Die Software die ich kenne macht rescans und neue COM Ports tauchen in 
der Liste auf. Das finde ich auch selbstverständlich da der USB Standard 
nun mal Hot Plug vorsieht. Man kann den wohl schlecht anklagen wenn die 
Software nix taugt.


> und sie kann
> nicht erkennen, welche COM dem Gerät zugewiesen wurde.

Wie denn auch? Das geht auch mit klassischen COM Ports nicht, nur eben 
auf einer anderen Ebene. Woher soll Software wissen wo welches Kabel 
angesteckt wird.

FTDI Com Ports z.B. haben nach erneutem einstecken wieder den alten COM 
Port. Ist auch nicht alzu schwer das per VID/PID zu identifizieren.

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
Toby P. schrieb:
> FTDI Com Ports z.B. haben nach erneutem einstecken wieder den alten COM
> Port. Ist auch nicht alzu schwer das per VID/PID zu identifizieren.

Das Funktioniert bei mir mit CP2102 und PLxxx genau so. Windows versucht 
COM Ports gemäß vorher gespeicherter Zuordnung wieder erneut so 
zuzuordnen.

von Toby P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Das Funktioniert bei mir mit CP2102 und PLxxx genau so. Windows versucht
> COM Ports gemäß vorher gespeicherter Zuordnung wieder erneut so
> zuzuordnen.

Danke für die Info

Peter D. schrieb:
> Hab ich auch nicht. Sondern, daß am Gerät ein USB rausschaut, drinne
> aber auf UART umgesetzt wird, mit den damit verbundenen Einschänkungen.
> Das ist die Mogelpackung.

Naja, beim USB COM Adapter schaut ein 9 pol D Stecker am anderen Ende 
raus. Ist das auch ne Mogelpackung? Oder COM Server, die übertragen 
RS232 per Ethernet in den PC. Mogelpackung?

von Peter D. (peda)


Bewertung
1 lesenswert
nicht lesenswert
Toby P. schrieb:
> Naja, beim USB COM Adapter schaut ein 9 pol D Stecker am anderen Ende
> raus. Ist das auch ne Mogelpackung?

Mein Gott, ist das denn so schwer zu kapieren?
Da schaut eben nichts raus. Der USB-UART Chip sitzt intern auf der 
Platine, ist also nicht zu sehen. Erst wenn man das Gerät gekauft hat 
und an den PC anschließt, sieht man das Mal­heur.
Und im Werbeprospekt steht natürlich groß und breit "USB".

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
Toby P. schrieb:
> Naja, beim USB COM Adapter schaut ein 9 pol D Stecker am anderen Ende
> raus. Ist das auch ne Mogelpackung? Oder COM Server, die übertragen
> RS232 per Ethernet in den PC. Mogelpackung?

Genau.
Grundsätzlich muss man eben sagen, ein USB-Kabel an einem Gerät sagt 
nichts über die verwendete Klasse aus. Man weiß also nicht wie es sich 
genau verhalten wird, ob und welchen Treiber man braucht usw.
Das halte ich aber für offensichtlich. Dafür ist USB eben universell 
ausgelegt.

PEDA unkte:

> Mein Gott, ist das denn so schwer zu kapieren?

Wir kapieren es. Wir stimmen dir nur nicht zu.

> Und im Werbeprospekt steht natürlich groß und breit "USB".

Es IST USB. Nochmal: Ein USB-Kabel sagt halt nichts aus über die Klasse. 
Keine Ahnung was du da alles voraussetzt weil es USB hat. Daher meine 
Frage: Welche USB Klassen gehen bei dir als echtes, PEDA zertifizertes, 
USB durch und welche sind nur Mogelpackung?

: Bearbeitet durch User
von Toby P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Mein Gott, ist das denn so schwer zu kapieren?

Ne

> Da schaut eben nichts raus. Der USB-UART Chip sitzt intern auf der
> Platine, ist also nicht zu sehen. Erst wenn man das Gerät gekauft hat
> und an den PC anschließt, sieht man das Mal­heur.

Wie schrecklich

> Und im Werbeprospekt steht natürlich groß und breit "USB".

Ist auch USB, nur eben CDC class. Die emuliert da eben einen COM port.

Die Maus class emuliert ne Maus (da kann auch was anderes hinterhängen) 
und Mass Storage grob gesagt ne SCSI Platte.

Man kann sich natürlich auch nativ mit Endpoints rumschlagen, dann kommt 
echtes USB feeling ;-) .

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
Toby P. schrieb:
> Man kann sich natürlich auch nativ mit Endpoints rumschlagen, dann kommt
> echtes USB feeling ;-) .

Dann braucht man allerdings wieder einen speziellen Treiber für jedes 
Gerät. Ob das allerdings dem PEDA ausreicht, um richtig echtes USB zu 
sein, ist fraglich.

von Toby P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Der USB-UART Chip sitzt intern auf der Platine

Bei meinen Geräten ist da nicht mal mehr der Chip sondern der/die COM 
port(s) gleich in der Software.


> ist also nicht zu sehen.

so noch weniger

> Erst wenn man das Gerät gekauft hat
> und an den PC anschließt, sieht man das Mal­heur.

Warum? CDC kann Mbaud, wo ist da der Nachteil?

> Und im Werbeprospekt steht natürlich groß und breit "USB".
Haben Sie dir ne Festplatte mit COM Port Emu angedreht ? ;-)

von Toby P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Dann braucht man allerdings wieder einen speziellen Treiber für jedes
> Gerät. Ob das allerdings dem PEDA ausreicht, um richtig echtes USB zu
> sein, ist fraglich.

Och das geht auch ohne Treiber, man muss sich nur den PC wegdenken. Da 
reitest du dann direkt auf den Daten, yippeeihyeahhh  ;-).

von M. K. (sylaina)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Mein Gott, ist das denn so schwer zu kapieren?

Ich kanns auch nicht fassen aber anscheinend raffen es hier einige 
wirklich nicht.

von Uwe K. (ukhl)


Bewertung
1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Henrik L. schrieb:
>> Gibt es dafür eine allgemeine Regel für die unzulässigen Kombinationen?
> Darauf kann man also nur antworten: "Nein".

Das ist die einzige richtige Antwort.
Alle Kombinationen sind erlaubt.
Wichtig ist nur, dass beide Seiten die Einstellung beherrschen, da diese 
gleich sein müssen.

Eine Prüfung ist nur dann sinnvoll, wenn die Gegenseite bekannt ist, und 
nicht alle Einstellungen beherrscht.

Ob eine exotische Einstellung Sinn macht, ist dann ein anderes 
Kapitel...

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Erst wenn man das Gerät gekauft hat und an den PC anschließt, sieht man
> das Mal­heur.
Dann ist das Gerät nämlich eines von etwa 8 COM-Devices, die man ums 
Verrecken nicht unterschieden kann. Ein "automatischer Scan" versucht 
dann alle Ports aufzumachen und schickt überall was raus und lauscht, 
was zurückkommt. Oft geht das gut.

Kurz: ein anständiges USB-Device meldet sich als "Anständigesusbdevice" 
statt als "COM13:"
Und es bringt natürlich auch einen Treiber für ein 
"Anständigesusbdevice" mit.

: Bearbeitet durch Moderator
von Percy N. (vox_bovi)


Bewertung
-1 lesenswert
nicht lesenswert
Uwe K. schrieb:
> Wichtig ist nur, dass beide Seiten die Einstellung beherrschen, da diese
> gleich sein müssen.

Warum sollten sie gleich sein? Woran soll der Empfänger merken, ob der 
Sender gerade nichts mitzuteilen hat oder doch noch dabei ist, die 
letzten seiner 800 Stoppbits zu übertragen (man hat ja Zeit .. )?

von A. S. (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Percy N. schrieb:
> Warum sollten sie gleich sein? Woran soll der Empfänger merken, ob der
> Sender gerade nichts mitzuteilen hat oder doch noch dabei ist, die
> letzten seiner 800 Stoppbits zu übertragen (man hat ja Zeit .. )?

Percy, Du warst das mit den stoppbits beim Empfänger!

Uwe ging es nicht um Deine stoppbits, sondern um den Rest: baudrate, 
Party etc.

Ich hoffe aber, dass Du das mit den stoppbits inzwischen verstanden hast 
(der Empfänger wartet NICHT ein ganzes Stoppbitt ab)

von Axel S. (a-za-z0-9)


Bewertung
1 lesenswert
nicht lesenswert
Peter D. schrieb:
> Toby P. schrieb:
>> Naja, beim USB COM Adapter schaut ein 9 pol D Stecker am anderen Ende
>> raus. Ist das auch ne Mogelpackung?
>
> Mein Gott, ist das denn so schwer zu kapieren?
> Da schaut eben nichts raus. Der USB-UART Chip sitzt intern auf der
> Platine, ist also nicht zu sehen.

Evtl. sitzt da gar kein Chip, sondern der µC implementiert auf dem USB 
einfach "nur" einen CDC Endpunkt. Und weil das Software ist, ist es 
natürlich nicht zu sehen.

"Hardware ist das, was weh tut, wenn es auf die Zehen fällt. Der Rest 
ist Software."

> Erst wenn man das Gerät gekauft hat
> und an den PC anschließt, sieht man das Mal­heur.

Nochmal: welches Malheur?

> Und im Werbeprospekt steht natürlich groß und breit "USB".

Was ist es denn, wenn kein USB? Wenn es einen USB-Anschluß hat, das 
USB-Signaling verwendet und sich am USB-Stack mittels USB-Protokoll 
anmeldet ... könnte es dann eventuell vielleicht doch ein USB-Gerät 
sein?

Oder mal anders gefragt: was wären denn deine Kriterien, die ein Gerät 
erfüllen müßte, damit du es als USB-Gerät anerkennst?


Lothar M. schrieb:
> Peter D. schrieb:
>> Erst wenn man das Gerät gekauft hat und an den PC anschließt, sieht man
>> das Mal­heur.
> Dann ist das Gerät nämlich eines von etwa 8 COM-Devices, die man ums
> Verrecken nicht unterschieden kann.

Naja. Das ist dann aber schon eine Windows-Marotte. Daß sie ein CDC 
ausschließlich in Form eines COM Gerätes sichtbar machen. Bei Linux 
z.B. ist das character device mit kanonischem Namen (etwa: ttyUSBxx) 
nur eine direkte Verbindung zu dem CDC Endpoint auf dem jeweiligen USB 
Gerät. Zusätzlich gibt es das "eigentliche" USB Gerät durchaus noch 
unter z.B. /dev/bus/usb/XX/YY zu sehen. Und per udev-Regel kann man ein 
namentlich (VID, PID, Serial Number) USB Gerät auch noch unter einem 
beliebigen Namen, etwa /dev/papa_schlumpf verfügbar machen.

> Kurz: ein anständiges USB-Device meldet sich als "Anständigesusbdevice"
> statt als "COM13:"

Das geht mit Windows? Wenn das Gerät nur die CDC Fähigkeiten hat (und 
braucht)? Linux kann das. Ich nehme an, alle ernsthaften Betriebssysteme 
(nicht: Betrübssysteme) können das.

> Und es bringt natürlich auch einen Treiber für ein
> "Anständigesusbdevice" mit.

Ja, toll. Treiberinstallation lieben die Anwender. Vor allem, wenn es 
um so etwas popeliges wie eine Maus geht.

von M. K. (sylaina)


Bewertung
0 lesenswert
nicht lesenswert
Axel S. schrieb:
> Oder mal anders gefragt: was wären denn deine Kriterien, die ein Gerät
> erfüllen müßte, damit du es als USB-Gerät anerkennst?

Na lass mal überlegen. Vielleicht, dass ein Gerät sich im System 
anmeldet als das, was es ist? Schaun wir uns mal so ein Korad 3005P an, 
da gabs ja letzt so ein netten Thread zu. Das Dingen hat auch einen 
USB-Anschluss was im Grund wieder nur ein UART-USB-Wandler ist, in einem 
Windows-System meldet sich der Spass als COM-Port an. Man hätte 
natürlich das Ganze auch ordentlich als USB-Device der Klasse 
Test&Measurement Device aufbauen können, das wäre aber natürlich mehr 
aufwand gewesen.

PEDA meint mit seiner Aussage eigentlich nur: Man erwartet man bekommt 
ein Gerät mit, ich sag mal, eigener Schnittstelle, dabei bekommt man so 
ein Teil mit integrierten USB2UART Converter geliefert. Also ich finde 
auch, schick ist anders. Für den Anwender kann das natürlich ziemlich 
egal sein. Zumindest mich interessiert es herzlich wenig als was sich 
ein USB-Gerät am System anmeldet solange alles klappt.

von Percy N. (vox_bovi)


Bewertung
-1 lesenswert
nicht lesenswert
A. S. schrieb:
> Ich hoffe aber, dass Du das mit den stoppbits inzwischen verstanden hast
> (der Empfänger wartet NICHT ein ganzes Stoppbitt ab)

Das war mir von Anfang an völlig klar, nur scheint hier einigermaßen 
unterzugehen,  dass man sich nicht darauf verlassen kann, Stoppbits von 
Übertragungspausen zu unterscheiden. Btw hatte auch Hmmm darauf 
hingewiesen:

Hmmm schrieb:
> Du kannst auch 100 Stopbits senden, aus Sicht des Empfängers sind mehr
> als die erwarteten Stopbits einfach nur Pausen zwischen den Zeichen. Je
> nach Protokoll können die natürlich Auswirkungen haben, z.B. bei Modbus
> RTU.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
Percy N. schrieb:
> Das war mir von Anfang an völlig klar, nur scheint hier einigermaßen
> unterzugehen,  dass man sich nicht darauf verlassen kann, Stoppbits von
> Übertragungspausen zu unterscheiden. Btw hatte auch Hmmm darauf
> hingewiesen:

A) man kann am Empfänger keine Anzahl an Stoppbits konfigurieren.

B) man kann am Sender nicht weniger als 1 konfigurieren

Damit ist Euer "erwartet" sinnlos oder zumindest verwirrend.

Percy N. schrieb:
> Solange mindestens so viele Stoppbits gesendet werden, wie der Empfänger
> erwartet,

von Peter D. (peda)


Bewertung
2 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Dann ist das Gerät nämlich eines von etwa 8 COM-Devices, die man ums
> Verrecken nicht unterschieden kann. Ein "automatischer Scan" versucht
> dann alle Ports aufzumachen und schickt überall was raus und lauscht,
> was zurückkommt.

Und dieser Scan muß dann auch noch verschiedene Baudraten 
durchprobieren. Das kann schon mal mehrere Minuten dauern (bei ner SPS 
erlebt).
Das PC Programm merkt sich zwar die gefundenen Einstellungen. Aber nur, 
bis man das Gerät versehentlich in eine andere USB-Buchse steckt.

: Bearbeitet durch User
von Walter T. (nicolas)


Bewertung
0 lesenswert
nicht lesenswert
Peter D. schrieb:
> Und dieser Scan muß dann auch noch verschiedene Baudraten
> durchprobieren. Das kann schon mal mehrere Minuten dauern.

Wieso sollte er das tun? Wenn meine Software ein bekanntes Gerät auch 
einem unbekannten COM-Port sucht, fragt es jeden COM-Port der Reihe nach 
ab:
  - Bist Du schon von anderer Software belegt? Wenn nein
  - Hallo Gerät, gibst Du die erwartete Antwort auf ein SYN-Paket mit 
erwarteter Baudrate? (Bei SCPI z.B. meist *IDN?.)

Wenn beides positiv beantwortet ist, ist das Gerät gefunden.

Edit: Man kann Deinen Post auch so verstehen, dass die PC-Software 
beliebig unterschiedliche Geräte in unbekannten Baudraten-Kombinationen 
sucht. Okay, dass das dauert, glaube ich. Aber das ist wohl bei jeder 
Form von Software, die viele Legacy-Komponenten unterstützen muss, z.B. 
auch bei jeder Netzwerk-Drucker-Software.

: Bearbeitet durch User
von Axel S. (a-za-z0-9)


Bewertung
0 lesenswert
nicht lesenswert
M. K. schrieb:
> Axel S. schrieb:
>> Oder mal anders gefragt: was wären denn deine Kriterien, die ein Gerät
>> erfüllen müßte, damit du es als USB-Gerät anerkennst?
>
> Na lass mal überlegen. Vielleicht, dass ein Gerät sich im System
> anmeldet als das, was es ist?

Das tut es doch? Es gibt nun mal nur eine endliche Liste an möglichen 
USB Geräteklassen. Das Gerät meldet sich mit Geräteklasse, Vendor- und 
Device-ID an. Das alles ist obligatorisch. Optional (von nahezu allen 
Geräten umgesetzt) gibt es dazu noch eine Seriennummer (damit man 
mehrere gleiche Geräte am Bus sauber unterscheiden kann) und eine 
Klartextbezeichnung. Und wie gesagt: das macht jedes USB Gerät so. 
Vollkommen egal, ob es HID oder CDC oder sonstwas ist. Ich sehe immer 
noch nicht, an welcher Stelle ein Gerät, das sich als CDC meldet, eine 
"Mogelpackung" ist.

> Schaun wir uns mal so ein Korad 3005P an, ...  in einem
> Windows-System meldet sich der Spass als COM-Port an. Man hätte
> natürlich das Ganze auch ordentlich als USB-Device der Klasse
> Test&Measurement Device aufbauen können, das wäre aber natürlich
> mehr aufwand gewesen.

Es wäre deutlich mehr Aufwand gesesen. Aber ja, in diesem speziellen 
Fall, wo es tatsächlich eine passend(er)e Geräteklasse gegeben hätte, 
kann man es in der Tat eine Mogelpackung nennen, wenn statt dessen CDC 
oder (sehe ich öfter) HID verwendet wird und der prorietäre Teil dann in 
einer darüber (im Sinne des ISO Stack-Modells) liegenden Schicht 
versteckt wird.

Nicht daß USBTMC da irgendwie besser wäre. Soweit ich ich beim kurzen 
Überfliegen sehen konnte, definiert das auch nur Container für 
proprietäre Datenpakete (Messages). Im Zweifel ist mir da ein 
Klartextprotokoll über CDC sogar lieber, das kann ich mit einem 
Terminalprogramm mitlesen.

von Toby P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
M. K. schrieb:
> Das Dingen hat auch einen
> USB-Anschluss was im Grund wieder nur ein UART-USB-Wandler ist, in einem
> Windows-System meldet sich der Spass als COM-Port an. Man hätte
> natürlich das Ganze auch ordentlich als USB-Device der Klasse
> Test&Measurement Device aufbauen können, das wäre aber natürlich mehr
> aufwand gewesen.

und imo etwas sinnfrei weil es keine Tools für diese Klasse gibt. Ein 
COM Port kann mit nem simplen Terminal Programm geöffnet werden, jede 
Software drauf aufsetzen und ohne Verbiegungen durch das Netzwerk 
geschickt werden.

Schon bei HID gehen die Probleme los, da muss man minimum ein HID 
Terminal haben das auf die Verbindung aufsetzt.

Per COM Port kannst du deine wie auch immer funktionierende Gurke 
kontrollieren. Mit fast jedem OS oder Smartphone. Das hat mir schon oft 
sehr geholfen. Meine Geräte haben alle einen, oft auch ein 
Terminalprogramm was einem die Konfig App erspart.

Vom Prinzip her könnte man sogar über RTS CTS Triggern, da USB aber 
nicht echtzeitfähig ist kann man da auch lassen. Da ist auch die Device 
class egal.

von Toby P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Dann ist das Gerät nämlich eines von etwa 8 COM-Devices, die man ums
> Verrecken nicht unterschieden kann.

Bei WIN in allen Versionen machst du den Geräte Manager auf, ziehst es 
einmal raus und steckst es wieder rein. Dann verschwindet der COM Port 
und ploppt wieder auf. So schwer ist das nicht ;-).

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Toby P. schrieb:
> Per COM Port kannst du deine wie auch immer funktionierende Gurke
> kontrollieren.
Das war schon vor fast 60 Jahren so und gilt auch heute noch!

Warum hat man überhaupt eine HID-Klasse gemacht? Vollkommen unnötig! 
Denn eine Maus konnte man früher ja auch schon am COM-Port betreiben.

Und eine richtig massive Höhle aus Stein geht auch nicht so arg leicht 
kaputt. Das war schon vor ein paar tausend Jahren so und gilt auch heute 
noch!

[/satire]

Toby P. schrieb:
> So schwer ist das nicht ;-).
Ja, halt Murks. Und Murksen ist bekannterweise immer an einfachsten...

: Bearbeitet durch Moderator
von Arno (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Toby P. schrieb:
> Lothar M. schrieb:
>> Dann ist das Gerät nämlich eines von etwa 8 COM-Devices, die man ums
>> Verrecken nicht unterschieden kann.
>
> Bei WIN in allen Versionen machst du den Geräte Manager auf, ziehst es
> einmal raus und steckst es wieder rein. Dann verschwindet der COM Port
> und ploppt wieder auf. So schwer ist das nicht ;-).

Das ist Murks, liegt aber ungefähr halb an Windows (für das das selbe 
USB-Gerät an einem anderen USB-Port ein anderes ist), halb an den 
Geräte-Entwicklern (die ihren Geräten keine individuelle Seriennummer 
und auch sonst keine Beschreibung mitgeben).

Beides hat aber sehr wenig damit zu tun, ob das Gerät einen "virtuellen 
COM-Port" implementiert oder nicht. Sehr wenig, weil manche anderen 
Geräteklassen so eine Nachlässigkeit nicht erlauben.

MfG, Arno

von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> A) man kann am Empfänger keine Anzahl an Stoppbits konfigurieren.
>
> B) man kann am Sender nicht weniger als 1 konfigurieren
>
> Damit ist Euer "erwartet" sinnlos oder zumindest verwirrend.

Auch wenn die gängigen UARTs sich generell mit einem Stopbit (bzw. mit 
rund 1/2) begnügen: Wenn z.B. 2 Stopbits vereinbart sind, sollte man sie 
auch senden, denn es spricht nichts dagegen, das Fehlen des zweiten in 
einem Software-UART o.dgl. als Framing Error zu behandeln.

In der Praxis dürfte es natürlich eher vorkommen, dass das Stopbit nicht 
mal explizit ausgewertet wird, sondern einfach nach dem letzten Datenbit 
ein Interrupt auf die fallende Flanke des nächsten Startbits gesetzt 
wird.

von Percy N. (vox_bovi)


Bewertung
-1 lesenswert
nicht lesenswert
Hmmm schrieb:
> In der Praxis dürfte es natürlich eher vorkommen, dass das Stopbit nicht
> mal explizit ausgewertet wird, sondern einfach nach dem letzten Datenbit
> ein Interrupt auf die fallende Flanke des nächsten Startbits gesetzt
> wird.

Das trifft sicherlich zu. Gleichwohl halte ich es für leichtfertig, 
diese Übung als allgemein verbindliche Praxis anzusehen, mag es auch 
noch so verführerisch erscheinen. Ein Gegenbeispiel hattest Du ja schon 
genannt.

von A. S. (achs)


Bewertung
1 lesenswert
nicht lesenswert
Hmmm schrieb:
> Auch wenn die gängigen UARTs sich generell mit einem Stopbit (bzw. mit
> rund 1/2) begnügen: Wenn z.B. 2 Stopbits vereinbart sind, sollte man sie
> auch senden, denn es spricht nichts dagegen, das Fehlen des zweiten in
> einem Software-UART o.dgl. als Framing Error zu behandeln.

??? natürlich sollte man sie senden, wenn man vereinbart, 2 zu senden.

Die beim Empfang auch zu "überprüfen" zeugt davon, dass Konzept der 
asynchronen Übertragung nicht ganz zu durchdringen:

Es gibt immer Baudratenunterschiede, darum ist es immer notwendig, 
länger Stoppbits zu senden als zu erwarten.

> In der Praxis dürfte es natürlich eher vorkommen, dass das Stopbit nicht
> mal explizit ausgewertet wird, sondern einfach nach dem letzten Datenbit
> ein Interrupt auf die fallende Flanke des nächsten Startbits gesetzt
> wird.
Das wäre grob Fahrlässig. Und (abgesehen vielleicht von privaten 
Basteleien) auch wohl eher selten. In Standard-Hardware glaube ich 
nicht, dass sowas existiert.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Und eine richtig massive Höhle aus Stein geht auch nicht so arg leicht
> kaputt. Das war schon vor ein paar tausend Jahren so und gilt auch heute
> noch!

und Steintafeln und Schellakplatten sind haltbarer und länger lesbar als 
Papier oder CDs (scnr)

Probleme bereiten eher Wachswalzen mangels Abspieler.

: Bearbeitet durch User
von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Arno schrieb:

> Das ist Murks, liegt aber ungefähr halb an Windows (für das das selbe
> USB-Gerät an einem anderen USB-Port ein anderes ist), halb an den
> Geräte-Entwicklern (die ihren Geräten keine individuelle Seriennummer
> und auch sonst keine Beschreibung mitgeben).

Nein, es liegt ALLEIN an den Geräteentwicklern. Wenn 
Unterscheidbarkeit und Persistenz mehrerer Instanzen desselben Device 
gewünscht ist, dann hat das Device, verdammt noch mal, eine eindeutige 
Serial zu haben. So sagt der USB-Standard, so setzt es Windows um.

Es macht sogar noch mehr (also Sachen, die schon weit über den Standard 
hinausgehen und eher als Workaround um die Unfähigkeit/Unwilligkeit der 
Devicehersteller zu sehen sind): solange die Busposition gleich bleibt, 
behalten sie ihre Identität, zumindest so lange nur USB-Klassentreiber 
von Windows involviert sind.

Es muss also neben der Unfähigkeit/Unwilligkeit der Device-Hersteller 
auch noch die Unfähigkeit/Unwilligkeit der Anwender mitspielen, um 
überhaupt zu einem Problem zu führen. Echt krass, wie doof manche 
sind...

von Percy N. (vox_bovi)


Bewertung
-2 lesenswert
nicht lesenswert
A. S. schrieb:
> Jedenfalls sind stoppbits nur für den Sender. Der Empfänger decodiert
> immer nur grob ein halbes.

A. S. schrieb:
> Damit ist Euer "erwartet" sinnlos oder zumindest verwirrend.

A. S. schrieb:
> ??? natürlich sollte man sie senden, wenn man vereinbart, 2 zu senden.

Warum, wenn sie doch eh nicht erwartet werden?

A. S. schrieb:
> Das wäre grob Fahrlässig.

A. S. schrieb:
> Jedenfalls sind stoppbits nur für den Sender. Der Empfänger decodiert
> immer nur grob ein halbes.
>
So langsam ist überhaupt nicht mehr erkennbar, was Du mitteilen 
möchtest.

von A. S. (achs)


Bewertung
1 lesenswert
nicht lesenswert
Percy N. schrieb:
> A. S. schrieb:
>> ??? natürlich sollte man sie senden, wenn man vereinbart, 2 zu senden.
>
> Warum, wenn sie doch eh nicht erwartet werden?

Du hast es selbst vorher schon zitiert:

Percy N. schrieb:
> A. S. schrieb:
>> Jedenfalls sind stoppbits nur für den Sender. Der Empfänger decodiert
>> immer nur grob ein halbes.

Und die Erklärung dazu nicht gelesen oder nicht verstanden.
A. S. schrieb:
> Es gibt immer Baudratenunterschiede, darum ist es immer notwendig,
> länger Stoppbits zu senden als zu erwarten.

Wenn Du zum Timing konkrete Fragen hast, frag gerne konkret.

von Percy N. (vox_bovi)


Bewertung
-2 lesenswert
nicht lesenswert
A. S. schrieb:
> Percy N. schrieb:
>> A. S. schrieb:
>>> ??? natürlich sollte man sie senden, wenn man vereinbart, 2 zu senden.
>> Warum, wenn sie doch eh nicht erwartet werden?
>
> Du hast es selbst vorher schon zitiert:
>
> Percy N. schrieb:
>> A. S. schrieb:
>>> Jedenfalls sind stoppbits nur für den Sender. Der Empfänger decodiert
>>> immer nur grob ein halbes.
>
> Und die Erklärung dazu nicht gelesen oder nicht verstanden.
Doch, ich habe es gelesen und verstanden. Du verstehst aber nicht, dass 
das im Widerspruch zu Deiner Forderung steht, so viele Stopbits zu 
senden, wue vereinbart. Wenn die weder erwartet noch ausgewertet werden, 
dann ist das doch bloß l'art pour l'art!
> A. S. schrieb:
>> Es gibt immer Baudratenunterschiede, darum ist es immer notwendig,
>> länger Stoppbits zu senden als zu erwarten.
>
Und plötzlich werden Stoppbits erwartet, was eben noch bestritten wurde!
Btw und OT: Deine Aussage ist falsch; Du kannst Dich nicht darauf 
verlassen, dass der Unterschied der Taktraten größer als Null ist. Du 
darfst Dich nur nicht darauf verlassen, dass er Null ist. Doch, das ist 
ein Unterschied.

> Wenn Du zum Timing konkrete Fragen hast, frag gerne konkret.
Danke, nein. Was mich interessieren könnte, wäre eine Autobaud-Funktion, 
aber das wäre hier völlig OT.

: Bearbeitet durch User
von Hmmm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Percy N. schrieb:
> Was mich interessieren könnte, wäre eine Autobaud-Funktion

Wenn das erste gesendete Bit (also das LSB) 1 ist, hat man nach dem 
Startbit direkt wieder eine Flanke, um die Bitlänge zu ermitteln. Siehe 
z.B. das A (0x41 und meistens auch 0x61) des guten alten 
AT-Befehlssatzes.

von Toby P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Toby P. schrieb:
>> Per COM Port kannst du deine wie auch immer funktionierende Gurke
>> kontrollieren.
> Das war schon vor fast 60 Jahren so und gilt auch heute noch!

Eben, das ist sehr bewährt und ausgereift.

>
> Warum hat man überhaupt eine HID-Klasse gemacht? Vollkommen unnötig!
> Denn eine Maus konnte man früher ja auch schon am COM-Port betreiben.

Vermutlich steht diese Satire um der Satire willen hier. Die HID Klassen 
bedienen bekanntlich Geräte deren Zweck so allgemein ist das man ihnen 
eine Classe spendiert hat. Das kann man in jedes noch so exotische Gerät 
implementieren und es ist kein Treiber nötig da der USB Standard das 
chon erledigt hat. HID funzt auch statt der CDC , man kann externes 
beliebig damit austatten. Das Gerät lässt sich sogar identifizieren aber 
ab dann?


>
> Und eine richtig massive Höhle aus Stein geht auch nicht so arg leicht
> kaputt. Das war schon vor ein paar tausend Jahren so und gilt auch heute
> noch!
>
> [/satire]

Lustig wenn Leute eine Satire über ihre eignen Aussagen schreiben. ;-).
Meiner einer würde daas nicht behaupten, der Kontext in dem das steht 
ist hoffe ich klar.


>
> Toby P. schrieb:
>> So schwer ist das nicht ;-).
> Ja, halt Murks. Und Murksen ist bekannterweise immer an einfachsten...

Wie willst da das anders machen? Wenn du ein unbekanntes Gerät hast hast 
du ein unbekanntes Gerät. Ohne zusätzliche Software funzt da nun mal 
nichts und wenn du 122 unbekannt HID Geräte oder 98 unbekannt Geräte wo 
du nicht mal das weißt (oder mit ner Exotenklasse wo es dir auch nix 
nütz) an deinem Rechner hast sieht das ganze in nichts besser aus. Im 
Gegenteil, du weist noch nicht mal wie die Gurke mit dem PC kommuniziert 
bei CDC ist wenigstens das klar.

von Gret (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Ein USB-UART ist etwa das Vernuenftigste was es gibt. Alles Andere ist 
quatsch. Weshalb ?
Weii ich darauf zaehlen kann, dass es dieses Port auch in 10 Jahren noch 
gibt.
Ich kaufe ein Device. Ein teures Device. zB Eines aus der Test & 
Measurement Klasse. Das hat heute zB ein USB Port. Wenn es einen eigenen 
Treiber mitbringt funktionert das jetzt. Beim naechten Windows in 5 
Jahren muss ich einen Treiber nachrennen. Vielleicht hat die Firma keine 
Lust mehr mir einen neuen Treiber zu einem alten Geraet zu liefern und 
moechte mir lieber ein neues Geraet verkaufen. Vielleicht laeuft es 
trotzdem noch. In zehn Jahren habe ich ein Problem. Die Herstellerfirma 
wurde schon das zweite mal verkauft und hat die Produktepalette 
"homogenisiert". Es gibt keinen Treiber mehr. Das Geraet, welches 
nochmals 10 Jahre laufen wuerde, tut's nicht mehr.
Nicht so wenn das Interface ein USB-Uart ist. Die mitgelieferte Software 
falls sie noch laeuft. Meinetwegen in einem Kompatibility modus, sieht 
immer noch ein UART, sieht mein Device.
Ihr habt ja keine Ahnung wie lange Gerate teilweise laufen. Wir haben 
einen Spektrumanalyzer bis 40GHz, welcher eine rechte Stange gekostet 
hat, der laeuft mit einem WinNT drauf, aus dem Jahr 1998 oder so, der 
hat noch eine Floppy. Und ein IEEE-488 Interface. Wir haben einen 
Networkanalyzer, bis 3GHz, der war auch recht teuer, aus Anfang 1990, da 
laeuft noch ein DOS drauf, auch mit Floppy. Er wurde kuerlich ergaenzt 
durch einen neuen 4 port Networkanalyzer.
Fuer etwas aufwendigere Geraete bevorzuge ich Ethernet ueber PCI-E, auch 
genau deswegen. Weil es Ethernet auch in 20 Jahren noch geben wird. Wir 
haben sehr teure Geraete, von 1995, welche ueber 10Base-2 angeschlossen 
werden. Das erste Ethernet mit Koaxial Kabel. Dafuer gibt es Konverter 
auf 10/100MBit Ethernet. Wir werden die Geraete nochmals 10 Jahre laufen 
lassen wenn sie's machen.

von A. S. (achs)


Bewertung
1 lesenswert
nicht lesenswert
Percy N. schrieb:
> Du verstehst aber nicht, dass das im Widerspruch zu Deiner Forderung
> steht, so viele Stopbits zu senden, wue vereinbart. Wenn die weder
> erwartet noch ausgewertet werden, dann ist das doch bloß l'art pour
> l'art!

Ausgewertet wird immer grob ein halbes.

Durch senden von einem Ganzen hat man grob 3% Baudraten-Toleranz (Sender 
3% schneller als Empfänger, die Gegenstrecke profitiert nicht davon, ist 
aber ein bisschen toleranter).

Durch senden von 1.5 ist es ein bisschen mehr, z.b. 3.5%. (Die 
Gegenstrecke profitiert wieder nicht davon).

Wenn ich einen Sender auf 1.5 oder 2 Stelle, sollte er das auch tun.

Den Empfänger kann man nicht konfigurieren.

von Percy N. (vox_bovi)


Bewertung
0 lesenswert
nicht lesenswert
Hmmm schrieb:
> Wenn das erste gesendete Bit (also das LSB) 1 ist, hat man nach dem
> Startbit direkt wieder eine Flanke, um die Bitlänge zu ermitteln. Siehe
> z.B. das A (0x41 und meistens auch 0x61) des guten alten
> AT-Befehlssatzes.

KISS ist immer noch das beste Prinzip, aber manche Dinge sind zu 
einfach, um darauf zu kommen ... ;-)

Danke für den Tipp!

von Toby P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. S. schrieb:
> Durch senden von einem Ganzen hat man grob 3% Baudraten-Toleranz (Sender
> 3% schneller als Empfänger, die Gegenstrecke profitiert nicht davon, ist
> aber ein bisschen toleranter).

Das mag ja alles sein und ist auch schön erklärt, aber wo hast du heute 
3% Baudraten Abweichung? Die meisten sind quarzgenau was ppm Toleranz 
bedeutet.

Wer jetzt unbedingt mit nem RC Glied seine Takte erzeugen will braucht 
so oder so ne Korrektur die er sich aus einem Autobaud verfahren holt, 
bzw holen sollte.

Toby P. schrieb:
> Wenn du ein unbekanntes Gerät hast hast
> du ein unbekanntes Gerät. Ohne zusätzliche Software funzt da nun mal
> nichts und wenn du 122 unbekannt HID Geräte oder 98 unbekannt Geräte wo
> du nicht mal das weißt

Mal für die Rasselbande hier Feldforschung betrieben.

Gerätemanager 14 USB Hid Devices, eines davon hatte nen Namen (Space 
Navigator) alle anderen nicht.

Nen Barcodeleser dazugesteckt, 2 USB HID Geräte mehr, keine weitere 
Beschreibung. Hab ich auch nur durch abzählen rausgefunden.

Da sind mir COM Port doch lieber.

von Arno (Gast)


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Arno schrieb:
>
>> Das ist Murks, liegt aber ungefähr halb an Windows (für das das selbe
>> USB-Gerät an einem anderen USB-Port ein anderes ist), halb an den
>> Geräte-Entwicklern (die ihren Geräten keine individuelle Seriennummer
>> und auch sonst keine Beschreibung mitgeben).
>
> Nein, es liegt ALLEIN an den Geräteentwicklern. Wenn
> Unterscheidbarkeit und Persistenz mehrerer Instanzen desselben Device
> gewünscht ist, dann hat das Device, verdammt noch mal, eine eindeutige
> Serial zu haben. So sagt der USB-Standard, so setzt es Windows um.
>
> Es macht sogar noch mehr (also Sachen, die schon weit über den Standard
> hinausgehen und eher als Workaround um die Unfähigkeit/Unwilligkeit der
> Devicehersteller zu sehen sind): solange die Busposition gleich bleibt,
> behalten sie ihre Identität, zumindest so lange nur USB-Klassentreiber
> von Windows involviert sind.

Eben, es glaubt, schlauer als der Anwender zu sein, und versucht, eine 
Pseudo-Persistenz einzuführen. Das tun zumindest nicht alle anderen 
Betriebssysteme, da heißt das erste angesteckte USB-Seriell-Kabel immer 
ttyUSB0 (oder so ähnlich) und nicht mal COM1 und mal COM8, je nachdem, 
an welchem Port es steckt.

Auch das kann schief gehen - es geht dann halt anders schief ;)

Hat aber beides noch so gut wie nichts damit zu tun, dass das Gerät ein 
USB-Seriell-Wandler ist, denn auch denen kann man Seriennummern geben.

MfG, Arno

von Soul E. (souleye) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Toby P. schrieb:

> Das mag ja alles sein und ist auch schön erklärt, aber wo hast du heute
> 3% Baudraten Abweichung? Die meisten sind quarzgenau was ppm Toleranz
> bedeutet.

Umgekehrt. Immer mehr Geräte nutzen den internen Highspeed-Oszillator 
des Controllers. Die erreichen mittlerweile auch Toleranzwerte im 
einstelligen Prozentbereich, aber 3% sind da schonmal sportlich.

Beim LIN ist es üblich, Slaves ohne Quarz auf den Sync-Frame des Masters 
aufzusynchronisieren. Die messen dann das 0x55 am Anfang aus und passen 
darauf ihre Baudrate an. Das geht entweder vollautomatisch in der 
LIN-Zelle, oder manuell per Software.

von Toby P. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Soul E. schrieb:
> Umgekehrt. Immer mehr Geräte nutzen den internen Highspeed-Oszillator
> des Controllers. Die erreichen mittlerweile auch Toleranzwerte im
> einstelligen Prozentbereich, aber 3% sind da schonmal sportlich.

Da nützt der 3% "Rauschabstand in der time domain" aber auch nicht mehr 
viel. Da kommt man wohl kaum ohne Autobaud aus.

Das der Baudratenteiler nicht immer eine Genaue Taktrate liefert hab ich 
aber vergessen.

von Uwe K. (ukhl)


Bewertung
2 lesenswert
nicht lesenswert
> A. S. schrieb:
>> Jedenfalls sind stoppbits nur für den Sender. Der Empfänger decodiert
>> immer nur grob ein halbes.
>>
> So langsam ist überhaupt nicht mehr erkennbar, was Du mitteilen
> möchtest.

Wenn man 1 Stoppbit mit "Übertragungspause mit 1 Bit länge" übersetzt, 
wird es vielleicht klarer, warum die Einstellung der Stoppbits beim 
empfangen nicht von Bedeutung ist. Warum sollte der Empfänger länger 
warten, als er wirklich braucht?

Nur der Sender macht eine Pause. Der Empfänger ist dann am Arbeiten. 
Braucht ein langsamer Empfänger mehr Zeit, muss der Sender eine längere 
Pause machen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.