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!
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
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"
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
Könnte diese Einschränkung obsolet sein, weil im Gegensatz zu Fernschreibern moderne Geräte nahezu beliebig getaktet werden können?
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.
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.
Ich wuerd mich mal mit der Standardeinstellung von 8,n,1 befassen. Der Rest hat sich nicht halten koennen
Solange mindestens so viele Stoppbits gesendet werden, wie der Empfänger erwartet, dürfte eigentlich nichts schief gehen.
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.
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.
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.
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?
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.).
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.
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.
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.
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
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.... |
> 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
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".
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
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.
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.).
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
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
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.
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.
> 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
Angehängte Dateien:
-
Startbit.png
50 KB
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.
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.
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.
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.
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
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.
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ß.
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.
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.
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.
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.
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.
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?
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 Malheur. Und im Werbeprospekt steht natürlich groß und breit "USB".
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
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 Malheur. 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 ;-) .
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.
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 Malheur. 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 ? ;-)
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 ;-).
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.
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...
Peter D. schrieb: > Erst wenn man das Gerät gekauft hat und an den PC anschließt, sieht man > das Malheur. 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
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 .. )?
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)
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 Malheur. 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 Malheur. > 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.
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.
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.
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,
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
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
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.
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.
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 ;-).
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
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
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.
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.
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.
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
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...
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.
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.
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
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.
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.
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.
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.
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!
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.
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
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.
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.
> 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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.