Nachdem ich schon einmal mit der USB2UART-Bridge CH340N gekämpft hatte (und kein vernünftiges Ergebnis hatte), habe ich mir dieses Teil noch einmal vorgenommen. Nur ein 8 pol. Chip, kein Quarz benötigt, lediglich ein 100nF Kondensator an V3 und ein Kondensator für Vcc und das ist dann alles. Um kein Mißverständnis aufkommen zu lassen: Ein CH340G funktioniert problemlos, mir geht es hier um die N-Variante. Also habe ich jetzt mehrere Versuche gemacht und experimentiert und das Ergebnis ist irgendwie ernüchternd. Egal was ich anstelle, eine saubere und stabile Verbindung bekomme ich nur bis zu einer Baudrate von 38400 hin. Jede Baudrate darüber produziert immer wieder Müll. Für meine Versuche habe ich eine kleine Platine gemacht, die in meine kleine Peltierklimabox passt, weil ich Temperatureinwirkungen gemutmaßt habe. Aber, von einer Temperatur von -5°C bis +40°C immer das gleiche Bild. Datenübertragungen sind nur bis 38400 Baud möglich. Compiliere ich einen Optibootloader für einen ATmega klappt das bis zur genannten Baudrate gut, darüber nur noch schlecht. Hat jemand von Euch eine Lösung wie das vllt. doch mit höheren Baudraten klappt, oder bleibt das bei einem CH340N auf so niedrige Baudraten beschränkt?
Angehängte Dateien:
-
ch340n_circuit.png
36 KB
Ralph S. schrieb: > Jede Baudrate darüber produziert immer wieder Müll. Als erstes könntest du die Baudrate und das Timing der Signale auf der UART-Seite prüfen, d.h. Baudrate und Jitter messen. "produziert immer wieder Müll" ist eine etwas dünne Aussage.
:
Bearbeitet durch User
Angehängte Dateien:
Ralph S. schrieb: > Egal was ich anstelle, eine saubere und stabile Verbindung bekomme ich > nur bis zu einer Baudrate von 38400 hin. Dann machst Du vermutlich etwas falsch oder hast einen Fakechip gekauft – ich vermute aber das erste, Dein Design ist schlecht und wenn jemand sich damit brüstet oder jubelt, dass nur ein Abblockkondensator auf der Spannungsversorgung benötigt wird, dann kann man sich schon denken, was im Busch ist. Der CH340N ist quasi mein Standard-IC, mit dem ich meine USB-UART-Brücken baue – die Baudrate habe ich erfolgreich im Peak bis 2 MBit getestet, im Dauerfeuer sollte man aber 460800 nicht überschreiten (Auszug im Anhang) und ab 115200 fange ich eigentlich erst an, das Ding zu nutzen, weil alles andere drunter mittlerweile nicht mehr zeitgemäß oder altbacken ist, und Du kommst gerade mal auf nur 38400. Mein Design ist natürlich wie gewohnt gut durchdacht und sehr solide und die Chips beziehe ich mir als Gewerbetreibender aus sicherer Quelle.
:
Bearbeitet durch User
Ich habe eine ganze Reihe Arduino Boards mit angeblichen CH340, die alle nur mit weniger als 500.000 Baud funktionieren. Als ich darauf stieß, kam bei mir zum ersten mal die Vermutung auf, dass die Chinesen inzwischen sogar ihre "eigenen" Chips fälschen. Inzwischen habe ich (bezüglich anderer Chips) mehrere solcher Berichte im Internet gelesen. Also: Ja, einen Fake halte ich für möglich.
Gregor J. schrieb: > Dann machst Du vermutlich etwas falsch oder hast einen Fakechip gekauft > – ich vermute aber das erste, Dein Design ist schlecht und wenn jemand > sich damit brüstet oder jubelt, dass nur ein Abblockkondensator auf der > Spannungsversorgung benötigt wird, dann kann man sich schon denken, was > im Busch ist. Na ja, das ist der Grund warum ich mir den CH340N angesehen habe und warum ich mit diesem Versuche mache, weil dieser ja gar keine andere Möglichkeit hat, als nur die Betriebsspannung mittels Kondensator zu stützen und an V3 einen 100nF gegen Masse benötigt. Alle anderen Pins sind funktionale Pins. Gregor J. schrieb: > Der CH340N ist quasi mein Standard-IC Mein Standard-IC ist der CH340G und mit diesem habe ich überhaupt keine Probleme. Gregor J. schrieb: > Mein Design > ist natürlich wie gewohnt gut durchdacht und sehr solide und die Chips > beziehe ich mir als Gewerbetreibender aus sicherer Quelle. Meine Quelle ist www.lcsc.com und ich hatte bisher noch nie Probleme mit Chips von diesem Lieferanten. Selbst mit dem extrem oft gefälschten STM32F103C8 nicht. Schön dass du deine Design gut durchdacht und sehr solide gemacht hast. Warum läßt du mich/uns nicht daran teilhaben und zeigst dein Design hier? (Eine Tabelle was das Dingens können SOLL hilft mir wenig, lt. Datenblatt - chinesisch mittels google-translate übersetzt - soll er das ja können). Auszug Datenblatt:
1 | CH340C/N/K/E and CH340B have integrated 12MHz clock, no external crystal required, CH340B also integrates EEPROM used to configure the serial number, etc |
2 | |
3 | Pin power supply voltage input, requires an external 0.1uF decoupling capacitor |
4 | |
5 | Pin V3 power connect to VCC when VCC is 3V3, connect to 0.1uF decoupling capacitor when VCC is 5V |
Monk schrieb: > Ich habe eine ganze Reihe Arduino Boards mit angeblichen CH340, die alle > nur mit weniger als 500.000 Baud funktionieren. Ich habe fast ausschließlich meine Boards mit CH340G aufgebaut und die funktionieren alle absolut einwandfrei, aber eben die "G" Variante des Chips. Rainer W. schrieb: > Als erstes könntest du die Baudrate und das Timing der Signale auf der > UART-Seite prüfen, d.h. Baudrate und Jitter messen. > "produziert immer wieder Müll" ist eine etwas dünne Aussage. Das habe ich natürlich gemacht. Die für mich interesanteste Baudrate ist 115200 Baud. Baudrate stimmt, der Jitter wechselt zwischen 2% und 18%, bei 57600 Baud zwischen 2% und 15%, bei 38400 Baud bleibt der Jitter immer unter 4%. Für Versuche zum Empfang mittels des CH340N habe ich ein Testprogramm in einem ATmega328p mit 16MHz ext. Quarz dessen Baudrate ich mittels Jumper an den I/O Pins von 19200 Bd bis 115200 Bd einstellen kann. Der maximale Jitter MCU-seitig beträgt bei 115200 Bd 2,5% und funktioniert in Verbindung mit einem CH340G perfekt. Monk schrieb: > Also: Ja, einen Fake halte ich für möglich. Na ja, aber 38400 Bd ist doch etwas wenig, oder?
Angehängte Dateien:
-
CH340N.PNG
23 KB -
CH340N_pins.PNG
52 KB
Gregor J. schrieb: > Dein Design ist schlecht Das Makro ist etwas unschön, weil es im Grunde das Layout in den Schaltplan zieht. Ein schöneres Makro hätte oben +VCC und V3, unten GND, links die USB- und rechts die RS232-TTL Anschlüsse. > und wenn jemand sich damit brüstet oder jubelt, dass nur ein > Abblockkondensator auf der Spannungsversorgung > benötigt wird, dann kann man sich schon denken, was im Busch ist. Naja, ich sags mal so: der Hersteller selber behauptet das... Aber man kann das im Layout natürlich tatsächlich noch ordentlich versauen. Monk schrieb: > dass die Chinesen inzwischen sogar ihre "eigenen" Chips fälschen Meine Erfahrung: "die Chinesen" bauen alles nach, was kommerziell erfolgreich ist und sich verkaufen lässt. Egal ob das aus irgendwo aus dem fernen Westen oder aus China selber kommt. Und die Krux: meist bauen sie es schlechter nach als das Original. Das war damals(tm) bei den Japanern noch anders... ;-)
:
Bearbeitet durch Moderator
Nur mal so als Anregung für die Zukunft. Neben dem Fake-Thema hier ist beim CH340 auch immer wieder das Problem mit der Seriennummer. Da es beim CH340 keine Seriennummern gibt, wird die Anmeldung bei Windows zum Glücksspiel, d.h. der COM-Port ändert sich dauernd. Wenig bekannt ist der FTDI-Baustein FT230XS - ein USB-UART mit wenigen Pins und Reduzierung auf das Wesentliche. Ja, schon wesentlich teurer, aber auch bei LCSC erhältlich und bestückbar. In alter FTDI-Manier sind die Teile sehr funktionssicher und natürlich gibt es auch eine ordentliche Seriennummer. In QFN oder SSOP auch noch kleiner als ein SO8.
:
Bearbeitet durch User
Beitrag #7749846 wurde vom Autor gelöscht.
Angehängte Dateien:
-
ch340n_fotoansicht.png
36 KB -
ch340n_layoutpic.png
32 KB
@Lothar: Sorry wenn ich das so schreibe, aber der Schaltplan in Deinem Post gibt zwar mehrere Typen an, ist aber mit der Pinzuordnung für einen 10 pol. Chip beschriftet (wobei eine Pinnummer 0 schon etwas "lustig" ist). Wie dem auch sei, ist das jedoch, wenn man die Pinnummern an den CH340N anpasst ja genau die Schaltung, die ich aufgebaut habe. Einen Unterschied habe ich jedoch, dass ich über die Vbus zusätzlich einen 10µF Tantal gelegt habe und 2 Serienwiderstände in RxD und TxD eingefügt habe. Natürlich habe ich Versuche gemacht mit entferntem Tantalkondensator und überbrückten Serienwiderständen Lothar M. schrieb: > Aber man kann das im Layout natürlich tatsächlich noch ordentlich > versauen. Im Anhang kann man mein Layout sehen. Ich kann mir zwar nicht vorstellen, dass das Layout dafür verantwortlich ist, aber vllt. seht ihr ja etwas grundsätzliches, das ich nicht sehe (vor lauter Wald den Baum nicht sehen).
Die Abblock Cs sind sehr suboptimal angebunden. Schau mal hier rein: http://www.lothar-miller.de/s9y/archives/12-Entkopplung.html Dort ist das gut beschrieben.
Andreas B. schrieb: > Die Abblock Cs sind sehr suboptimal angebunden. Ich finde die gar nicht mal so schlecht für ein so ungünstig bepinntes IC mit diametralen Vcc/GND-Anschlüssen. Auf jeden Fall liegt die Fehlfunktion sicher nicht daran. Und zudem ist auch ein fetter 10µ Kondensator noch im Spiel. Ralph S. schrieb: > und 2 Serienwiderstände in RxD und TxD eingefügt habe. Was für welche? Hast du dir die Signale schon mal mit dem Oszi angeschaut? Und auch die tatsächlichen Bitzeiten gemessen? Ralph S. schrieb: > Hat jemand von Euch eine Lösung wie das vllt. doch mit höheren Baudraten > klappt Brücke mal RX und TX an der Platine und schau im Terminal, ob der CH340 wenigtens mit seiner eigenen Baudrate klarkommt.
> Das habe ich natürlich gemacht. Die für mich interesanteste Baudrate ist > 115200 Baud. Baudrate stimmt, der Jitter wechselt zwischen 2% und 18%, > bei 57600 Baud zwischen 2% und 15%, bei 38400 Baud bleibt der Jitter > immer unter 4%. Gib doch mal immer 0xaa aus, trigger darauf und dreh mal die Persistenz an deinem Oszi hoch. Vanye
Ralph S. schrieb: > Jede Baudrate darüber produziert immer wieder Müll. Hast du auch mal einen anderen PC probiert? Ich kann mir gut vorstellen, dass die Controller "CH340C/N/K/E/X/B", die laut Hersteller "have integrated clock, no external crystal required" beworben werden, ihren Takt gegen das USB-Signal abgleichen. Denn ein integrierter RC-Oszillator ist sicher nicht ausreichend genau und stabil für USB.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Was für welche? Hast du dir die Signale schon mal mit dem Oszi > angeschaut? Und auch die tatsächlichen Bitzeiten gemessen? Ich hatte von 0 Ohm über 100, 1k, 4,7k, 10k versucht gehabt. Keine Änderung. Bitzeiten habe ich gemessen, es jittert ! Lothar M. schrieb: > Brücke mal RX und TX an der Platine und schau im Terminal, ob der CH340 > wenigtens mit seiner eigenen Baudrate klarkommt. Das macht er witzigerweise perfekt! Auch dann wenn ich das nicht mit einem Terminal mache, sondern mit einem Programm dass alle 10 Sekunden ein anderes Zeichen zum CH340N schickt. Abstand zwischen den Zeichen 50 ms.
Ralph S. schrieb: > Lothar M. schrieb: >> ob der CH340 wenigtens mit seiner eigenen Baudrate klarkommt. > Das macht er witzigerweise perfekt! Er erzeugt sich seinen internen Takt ja auch selber. Und zu sich selber genau zu sein ist eigentlich nicht schwierig... > Das macht er witzigerweise perfekt! Auch wenn du mal eine 1MB große Datei am Stück überträgst?
Ralph S. schrieb: > Lothar M. schrieb: >> Brücke mal RX und TX an der Platine und schau im Terminal, ob der CH340 >> wenigtens mit seiner eigenen Baudrate klarkommt. > > Das macht er witzigerweise perfekt! Auch dann wenn ich das nicht mit > einem Terminal mache, Klingt logisch. Auch wenn der interne Oszillator schief läuft, dann laufen RX & TX gleichermaßen parallel schief und damit gibts dann kein Problem im Loop-Back.
Lothar M. schrieb: > Andreas B. schrieb: >> Die Abblock Cs sind sehr suboptimal angebunden. > Ich finde die gar nicht mal so schlecht für ein so ungünstig bepinntes > IC mit diametralen Vcc/GND-Anschlüssen. Ich hätte den GND außen am IC weggelassen und nur innen über die C Anschlüsse zum IC laufen lassen. Aber ok, mag pingelig sein..... Wenn der Jitter vom USB kommt, wäre es mal interessant, das an einem anderem PC zu testen.
In einem englischen Datenblatt von Sparkfun steht: "The baud rate error of CH340 UART reception is about 2%, the baud rate error of CH340G/CH340T/CH340R UART transmission is less than 0.3%, and the baud rate of CH340C/CH340N/CH340K/CH340E/CH340X/CH340B is less than 1.2%" https://cdn.sparkfun.com/assets/5/0/a/8/5/CH340DS1.PDF
Stefan K. schrieb: > In einem englischen Datenblatt von Sparkfun steht: Beim Hersteller gibs schon ein neueres DB: - https://www.wch-ic.com/downloads/CH340DS1_PDF.html > the baud rate error ... of UART transmission ... CH340N ... less than 1.2%" Das passt aber nicht zu den Messwerten, von denen Ralph S. schrieb: > Die für mich interesanteste Baudrate ist 115200 Baud. Baudrate stimmt, > der Jitter wechselt zwischen 2% und 18%, bei 57600 Baud zwischen 2% und > 15%, bei 38400 Baud bleibt der Jitter immer unter 4%. Auch wenn % für Jitter eine unübliche Angabe ist, gehe ich davon aus, dass diese % auf die theoretische Bitzeit gerechnet sind. Und damit den Fehler in der Baudrate angeben.
:
Bearbeitet durch Moderator
Andreas B. schrieb: > Wenn der Jitter vom USB kommt, wäre es mal interessant, das an einem > anderem PC zu testen. USB lässt nur einen extrem geringen Jitter zu, ohne jetzt nachzuschlagen meine ich mich an maximal ein viertel Prozent** bei USB2.0 zu erinnern. Und das wäre schon grenzwertig viel. Der Chip kann also seine Frequenz-Synchronisation hinreichend genau direkt aus der USB-Anbindung generieren. ** Hab' nun doch nachgeschaut: FullSpeed:±0.25% LowSpeed:±1.5%
:
Bearbeitet durch User
Ralph S. schrieb: > Also habe ich jetzt mehrere Versuche gemacht und experimentiert und das > Ergebnis ist irgendwie ernüchternd. Immer mit dem selben CH340N?
Angehängte Dateien:
-
ATMEGA_-_UART-Abweichung.png
140 KB
Ralph S. schrieb: > Für Versuche zum Empfang mittels des CH340N habe ich ein Testprogramm in > einem ATmega328p mit 16MHz ext. Quarz dessen Baudrate ich mittels Jumper > an den I/O Pins von 19200 Bd bis 115200 Bd einstellen kann. Der maximale > Jitter MCU-seitig beträgt bei 115200 Bd 2,5% und funktioniert in > Verbindung mit einem CH340G perfekt. Das ist keine gute Idee, weil Du so zwei Fehlerquellen hast und die summieren bzw. überlappen sich unter Umständen, sie können sich natürlich auch gegenseitig aufheben usw. – den ATMEGA328P für die Tests müsstest Du mit z.B. 11,0592MHz oder 18,432MHz betreiben, damit hier der Fehler definitiv immer bei 0% liegt, denn 2,5% auf einer Seite ist schon ziemlich viel. Das ATMEGA-Datenblatt zeigt auch, dass der Fehler sogar bei 3,5% liegen kann, je nach Betriebsmodus – und das ist schon verdammt an der Grenze und wenn sich da noch der Fehler des CH340N überlagert, kann es passieren, dass es halt nicht mehr geht oder gehen kann, weil man schon drüber ist. So wie man das im Arduino mit 16MHz seit Jahren betreibt, ist grenzwertig – kaum einer weiß es, alle machen mit. PS: meine Platine habe ich hier schon gezeigt und Deine Bezugsquelle für den IC dürfte OK sein, wenn Du nicht gerade einen IC verwendest, der 10 Jahre in der Schublade lag und damals doch von woanders bezogen wurde; das Layout ist ausreichend – der Fehler kommt nicht von dort
:
Bearbeitet durch User
Gregor J. schrieb: > wenn Du nicht gerade einen IC verwendest, der 10 > Jahre in der Schublade lag und damals doch von woanders bezogen wurde; Was soll den das Gelaber? Ralph S. schrieb: > Baudrate stimmt, der Jitter wechselt zwischen 2% und 18%, > bei 57600 Baud zwischen 2% und 15%, bei 38400 Baud bleibt der Jitter > immer unter 4%.
Soooodele, nachdem ich jetzt viel überlegt habe und 2 verschiedenen Rechnern eine Terminalverbindung hergestellt habe die jeweils einem CH340N haben und diese Verbindung einwandfrei klappt (auch mit höheren Baudraten) wohl am Controller liegen. Also habe ich den ATmega fremdversorgt und siehe da, es sind auch höhere Baudraten möglich Gregor J. schrieb: > den ATMEGA328P für die Tests > müsstest Du mit z.B. 11,0592MHz oder 18,432MHz betreiben, damit hier der > Fehler definitiv immer bei 0% liegt, denn 2,5% ... auch mit einem 16Hz Quarz. Also konnte das wohl nur noch an der Versorgung liegen. Eine Drosselspule und ein Kondensator in die Versorgungsleitung des ATmega und es hat funktioniert. Ein STM32F030 der über einen AMS1117 3.3 an der 5V Leitung des USB hängt funktioniert dann auch sofort. Für mich gut zu wissen, denn bisher (beim CH340G) war die Drosselspule nicht notwendig. Vielen Dank an alle, die gepostet haben. Viele Grüße, Ralph
Ralph S. schrieb: > Also konnte das wohl nur noch an der Versorgung liegen. Eine > Drosselspule und ein Kondensator in die Versorgungsleitung des ATmega > und es hat funktioniert. Da wäre das Layout Deiner ATMega Schaltung wiederum interessant. Ich habe da noch nie eine Drossel benötigt.
Ralph S. schrieb: > Für mich gut zu wissen, denn bisher (beim CH340G) war die Drosselspule > nicht notwendig. Ist sie auch nicht, nur Dein Testaufbau, den Du natürlich NICHT gezeigt hast, den ich aber mit dem Design ganz am Anfang auch gemeint habe (also nicht nur die kleine PCB, sondern alles was dazugehört), ist vermutlich nicht so gut und das wird vermutlich auch die Ursache für die ganzen Probleme sein – wenn sich dann noch die Fehler auf beiden UART-Seiten zufällig addieren, dann geht es nicht mehr. Mit Deinen 16MHz und vermeintlicher Lösung mit Deiner Drossel bist Du nicht auf der sicheren Seite – das ist eine wackelige Geschichte, aber wenn Du der Meinung bist, dass es für Dich so passt, dann ist gut.
:
Bearbeitet durch User
Ralph S. schrieb: >> Also: Ja, einen Fake halte ich für möglich. > Na ja, aber 38400 Bd ist doch etwas wenig, oder? Allerdings. Harald A. schrieb: > Da es beim CH340 keine Seriennummern gibt, wird die Anmeldung bei > Windows zum Glücksspiel, d.h. der COM-Port ändert sich dauernd. Daran haben sich wohl die meisten hier gewöhnt. Bei dem Billig-kram muss man mit Abstrichen leben.
Monk schrieb: > Daran haben sich wohl die meisten hier gewöhnt. Bei Linux ist es die Reihenfolge des Einsteckens. Kann man sich auch dran gewoehnen. ;)
Ralph S. schrieb: > Rainer W. schrieb: >> Als erstes könntest du die Baudrate und das Timing der Signale auf der >> UART-Seite prüfen, d.h. Baudrate und Jitter messen. >> "produziert immer wieder Müll" ist eine etwas dünne Aussage. > Das habe ich natürlich gemacht. Die für mich interesanteste Baudrate ist > 115200 Baud. Baudrate stimmt, der Jitter wechselt zwischen 2% und 18%, > bei 57600 Baud zwischen 2% und 15%, bei 38400 Baud bleibt der Jitter > immer unter 4%. Dann war das aber schon irgendwie "wer Mist misst misst Mist", oder wie? Denn natürlich hätte ich erwartet, dass sich diese Messungen auf den RS232-Ausgang des fraglichen CH340 beziehen. Und der bekommt an seinem Ausgang nichts davon, dass der µC ab&zu stolpert. Ralph S. schrieb: > Also habe ich den ATmega fremdversorgt Wie wurde der denn bisher versorgt? Über den USB? Wie sieht denn die Versorgungsspannung dann auf dem Oszi aus, wenn die den Oszillator des µC gleich so ausser Takt bringt? > an der 5V Leitung des USB Merke: Es ist nur eine grobe Schätzung, das da 5V herauskommen. > Ein STM32F030 der über einen AMS1117 3.3 an der 5V Leitung des USB hängt > funktioniert dann auch sofort. Und wenn du den AVR mit diesen LDO-geregelten 3V3 versorgst?
Ralph S. schrieb: > Ein STM32F030 der über einen AMS1117 3.3 an der 5V Leitung des USB hängt > funktioniert dann auch sofort. Für die Tests wären die STM32 mit der 'Fraktionalbaudrate' deutlich besser geeignet als irgendein Arduino mit 16MHz oder gar ein Steckbrett mit Drähtchen und Dupontleitungen. Die Tests mit höheren Standard-Baudraten (also ein Vielfaches von 115200) sind eh nur so möglich. Einen kleinen Jitter/Fehler produzieren sie auch, wenn von dem Fraktionalgenerator Gebrauch gemacht wird, dieser ist aber in der Regel vernachlässigbar.
Lothar M. schrieb: > Wie wurde der denn bisher versorgt? Über den USB? Das war über den USB... und hab ich dann schnelle Peaks "entdeckt", die wohl wirklich vom ATmega gekommen sind (und jetzt weg sind, sowohl bei der Versorgungsspannung am MCU als auch am CH340N)
Ralph S. schrieb: > und hab ich dann schnelle Peaks "entdeckt", die wohl wirklich vom > ATmega gekommen sind Dann ist die Masseführung und/oder die Abblockung dieses µC schlecht.
Lothar M. schrieb: > Dann ist die Masseführung und/oder die Abblockung dieses µC schlecht. Ralph hat den Abblockkondensator wohl auch "vergessen", denn: Ralph S. schrieb: > Eine Drosselspule und ein Kondensator in die Versorgungsleitung des > ATmega und es hat funktioniert. Ich tippe hier dann doch eher auf den fehlenden Kondensator als auf die Drosselspule. @Ralph, nimm doch mal bitte die Nebelk^H^H^H^H^H Drosselspule raus, lasse den Abblockkondensator drin und teste nochmal.
:
Bearbeitet durch Moderator
Blockkondensatoren sind drin. Ohne die Spule gehts leider nicht. ATmega hat direkt an Vcc, AVcc 100nF, an Aref 10uF. Masse sind 0,6mm Leiterbahn. Wenn ich den CH340N auf dem Steckbrett betreibe, ihn dort über einen Spannungsregler AMS1117 mit 3,3V betreibe und dort dann V3 direkt an 3,3V anschließe, RX und Tx über 10k PullUp an die Eingänge des ATmega hänge, funktioniert es auch. Masse und 5,5V sehen dann auf dem Scope gut aus! Ich hätte nicht gedacht, dass der CH340 so empfindlich ist!
Ralph S. schrieb: > Ich hätte nicht gedacht, dass der CH340 so empfindlich ist! Ohne nachvollziehbare detaillierte Messprotokolle wird das niemand vernünftig kommentieren können.
Ralph S. schrieb: > Ich hätte nicht gedacht, dass der CH340 so empfindlich ist! Ich würde in so einem Fall den Fehler noch bei mir in meinem Aufbau suchen. Denn wenn der so kritisch wäre, dann würde man das ganz leicht im Netz finden. > Ohne die Spule gehts leider nicht. Was ändert sich mit dieser Spule messtechnisch? > Masse sind 0,6mm Leiterbahn. Sieh dir diesen Hauch von Leiterbahn mal in echt an: muss das unbedingt so unheimlich schmal sein? Meine Devise: Masse und Vcc sollen SOOO BBRREEIIITT wie möglich (= so niederimpedant wie möglich) gemacht werden. Man bekommt vom LP-Hersteller kein Geld zurück, wenn man weniger Kupfer auf seiner Leiterplatte verwendet. > ATmega hat direkt an Vcc, AVcc 100nF, an Aref 10uF. Blockkondensatoren gehören zwischen Vcc und GND. Direkt dazwischen.
:
Bearbeitet durch Moderator
Ralph S. schrieb: > an Aref 10uF Warum nicht die empfohlenen 100nF? Wird hier zwar nicht das Problem sein, aber beim Umschalten der Referenz dauert es damit lange, bis Du wieder brauchbare ADC-Messwerte bekommst.
Ralph S. schrieb: > Ich hätte nicht gedacht, dass der CH340 so empfindlich ist! Ist er nicht bzw. nicht mehr oder weniger als andere ICs, den Fehler solltest Du bei Dir selbst suchen (das ist in über 95% der Fälle immer so) – Du hast die Designregeln verletzt, Du benutzt gerne Steckbretter, hast anfangs vermutlich nicht genügend oder nicht richtig Abblockkondensatoren verwendet, Du verbindest das womöglich mit Dupontkabeln, Du hast auf der anderen Seite den UART mit einem ATMEGA mit 16MHz betrieben, was krumme Baudraten und erhebliche Fehler verursacht, willst das alles aber nicht zugeben und Dir eingestehen. Diese Haltung kann ich nicht nachvollziehen. Du erzählst auch im Nachhinein, wenn man Dich auf Deine Fehler aufmerksam macht, dass das nicht stimme, weil Du es angeblich jetzt nochmal gestestet hast und willst um jeden Preis beweisen, dass Du von Anfang an richtig gehandelt hast und dass der Fehler beim IC liegt. Mir ist schon klar, dass man das Gesicht wahren will und es nicht einfach ist, die Fehler zuzugeben, aber genau durch diese Haltung verlierst Du es und an Deine immer anschließenden Erzählungen kann ich (und andere vermutlich auch) mittlerweile nicht so richtig glauben; und an Deine exorbitanten angeblichen Jitter-Werte leider auch nicht – die kommen vermutlich von Deinem Aufbau oder wurden nicht richtig abgelesen oder mit Absicht ein wenig 'verschönert', um dem ganzen eine gewisse Tragik zu verleihen.
:
Bearbeitet durch User
Verändere doch mal spaßeshalber die Länge des USB-Kabels. Also in der „problematischen“ Version. Das Layout mag nicht optimal sein, aber das ist es IMHO nicht. Oder löte einen klassischen Elko 10..47uF parallel zum Keramischen.
:
Bearbeitet durch User
Harald A. schrieb: > Das Layout mag nicht optimal sein, aber das ist es IMHO nicht. Das Problem ist ja auch nicht der CH340 an sich, sondern nur zusammen mit dem AVR. Und dann auch nur, wenn der direkt aus dem USB versorgt wird.
Lothar M. schrieb: > Harald A. schrieb: >> Das Layout mag nicht optimal sein, aber das ist es IMHO nicht. > Das Problem ist ja auch nicht der CH340 an sich, sondern nur zusammen > mit dem AVR. Und dann auch nur, wenn der direkt aus dem USB versorgt > wird. Okay, aber die Versuche würde ich trotzdem durchführen.
Eigentlich war dieser Thread für mich abgeschlossen, aber ich komme wegen eines Forummitglieds in Gedanken nicht zur Ruhe und insbesondere im Umgang mit Menschen hier. Hier meine ich jetzt ganz speziell Gregor J. Auch wenn ich mir gesagt habe ich rege mich des Forums wegen nicht mehr auf, hat es Gregor dann doch wieder erreicht und ich möchte hier mal Stellung nehmen, exemplarisch auch für andere die hier ähnlich auftreten. Zu allererst: Wenn sich hier verdiente Forenmitglieder wie Lothar, Frank (die hier gepostet haben) oder Yalu und Jörg (die hier nicht gepostet haben) etwas schreiben, anmerken oder beitragen dann verdient das grundsätzlich Beachtung, weil der Äußerungen in aller Regel fundiert und auch belegbar sind. Aber - und das schreibe ich jetzt so, weil ich angepisst bin und nicht wenn - wenn ein Gregor großspurig erklärt: Gregor J. schrieb: > Dein Design ist schlecht um dann Oberlehrermäßig zu äußern: Gregor J. schrieb: > Mein Design ist natürlich wie gewohnt gut durchdacht und sehr solide natürlich ! und natürlich wie gewohnt ! Ich bin von Gregor gar nichts gewohnt und gesehen habe ich von Ihm auch nicht, aber das hier sagt in einer pseudofachlichen Sprache: "Hey, ich stehe über dir du Niete". Mag sein, dass Gregor etwas drauf hat oder auch nicht (mir ist das schnuppe), aber dieses Getue "seht her wie toll ich bin" ohne den Beweis anzutreten und bei Nachfrage zu sagen: "Ich habe hier schon mein Designe gepostet und gezeigt" ohne einen Link dazu zu geben ... na ja! Okay, das schlucke ich ja noch! Dann die hier ewig auftauchenden Bemerkungen zu Blockkondensatoren. Ich glaube hier hatte mehr als deutlich gemacht gehabt, dass diese sehr wohl vorhanden sind und auch das Layout gepostet. Für die Hinweise, wie man das besser machen kann bin ich (insbesondere Lothar) dankbar. Allerdings enger an den Chip heranführen kann ich das deshalb nicht, weil ich Kondensatoren kleiner 0805 einfach nicht mehr von Hand gelötet bekomme. Außerdem war das Design des PCB's des CH340N definitiv nicht das Problem, sondern schlichtweg die Kopplung an einen MCU (und hier dann im ersten Ansatz an einen ATmega). Diese war nicht optimal und Lothar hat vollkommen recht: "wer Mist misst misst Mist" Mir ist sehr wohl bekannt, dass Leiterbahnführung oft ein Problem ist, aber bei weitem seltener als es hier permanent verlautbart wird. Allerdings weiß ich auch, dass bei "kritischen" Bauteilen die Masseführung das A und O ist (nur hätte ich nicht angenommen, dass ein CH340N zu den "kritischen" Bauteilen gehört, wenn duch sein "größerer Bruder" absolut unkritisch ist). Leider finde ich die Seite mit dem für mich entscheidenden Hinweis nicht mehr, dass die Kopplung eines MCU's an einen CH340N bei gleicher Versorgungsspannung eine Schaltung zwischen beiden Teilnehmern an den RxD / TxD Leitung erfordert (die ich nicht gemacht habe und leider auch nicht mehr finde). Dort ging auch hervor dass es dieses Problem bei getrennten Spannungsversorgungen nicht gibt. Darauf hin habe ich - wie oben schon geschrieben gehabt - die Versorgungsspannung nicht nur mit dem Multimeter überprüft, sondern auf meinem alten Scope (und ja, das hätte ich tatsächlich viel früher machen können)... Frank M. schrieb: > Ich tippe hier dann doch eher auf den fehlenden Kondensator als auf die > Drosselspule. Sorry Frank, in diesem Falle habe ich den Kondensator tatsächlich nicht vergessen: Wenn etwas nicht funktioniert oder nicht zuverlässig funktioniert ist es das erste was ich nachschaue, wo ich eventuell Kondensatoren unterbringen kann. Hier war wirklich nichts zu machen. Lothar M. schrieb: >> Masse sind 0,6mm Leiterbahn. > Sieh dir diesen Hauch von Leiterbahn mal in echt an: muss das unbedingt > so unheimlich schmal sein? > Meine Devise: Masse und Vcc sollen SOOO BBRREEIIITT wie möglich (= so > niederimpedant wie möglich) gemacht werden. Man bekommt vom > LP-Hersteller kein Geld zurück, wenn man weniger Kupfer auf seiner > Leiterplatte verwendet. Natürlich Lothar, so breit wie möglich. Ich wollte die Schaltung aber auch so klein wie möglich haben. Und wie wir jetzt ja wissen: Die USB2UART-Bridge war es nicht und auch nicht die Masseführung. Aber ich gebe zu, dass das besser gelöst werden kann (nur leider bin ich nicht DER Routingexperte überhaupt, sondern bestenfalls "geht so"). Deswegen nehm ich da Eure Hinweise mit. Lothar M. schrieb: >> ATmega hat direkt an Vcc, AVcc 100nF, an Aref 10uF. > Blockkondensatoren gehören zwischen Vcc und GND. Direkt dazwischen. Hatte ich doch gemacht gehabt, und zwar auf dem kürzesten Wege. Hmmm schrieb: > Ralph S. schrieb: >> an Aref 10uF > > Warum nicht die empfohlenen 100nF? Um "sicher zu sein" dass da nichts passiert. Für die Versuche mit dem CH340N hat es den ADC des ATmegas nicht benötigt. Für mich habe ich ja eine Lösung gefunden, den CH340N mit Baudraten < 38400 Bd zu betreiben, und zwar mit ATmega und STM32. Warum ich mich aber wirklich wirklich tierisch aufrege (aber so richtig) - und ich höre jetzt nicht auf meine Frau die sagt ich solle diesen Text hier bleiben lassen, weil sie meint "getroffene Hunde bellen in der Regel" ist der abschließende Kommentar von Gregor. Meine Güte was er nicht alles über mich weiß, was er nicht alles weiß was ich gemacht oder nicht gemacht habe. Unglaublich. Was mich am meisten ärgert sind diese pseudofachliche Aussagen, die sich ja eigentlich gut anhören und sich fast so lesen, als wüßte der gute Mann bescheid und hat mir über die Schulter gesehen was ich gemacht habe (oder auch nicht). Nur um sich wohl selbst zu überhöhen und sich gut darzustellen. Sich ein gutes "Gefühl auf Kosten anderer zu geben" herjeh. Aber diese perfide Art und Weise bösärtige Unterstellungen zu machen, diese so darzustellen als würden sie der Wahrheit entsprechen, das hat schon etwas von Donald Trump, aber echt. So, jetzt nehm ich mal das Posting von Gregor auseinander, weil ich es einfach nicht so stehen lassen will. Gregor J. schrieb: > Fehler > solltest Du bei Dir selbst suchen (das ist in über 95% der Fälle immer > so) Das hier stellt mich dar, als würde ich den Fehler immer wo anderst als bei mir suchen. Wer mich kennt weiß, dass ich zu allererst den Fehler bei mir suche, denn in aller Regel habe ich den Fehler auch produziert. Einer meiner Fehler ist es wohl auch, dass ich für mich noch nicht alle Optionen durchgegangen bin und hier etwas gepostet hatte... mit der Bitte, ob jemand evtl. schon den selben Fehler gemacht hat und dass es evtl. ein Problem mit der Kopplung der Versorgungsspannung zwischen Bridge und MCU geben könnte. Aber: mir war schon sehr bewußt, dass der Fehler bei mir liegen MUSS, denn sonst wäre im Netz da deutlich mehr darüber zu lesen (by the way: es gibt viele Unterlagen, Schaltungen und Statements zu CH340G, aber erstaunlich wenig zu 340N). Gregor J. schrieb: > Du hast die Designregeln verletzt, Du benutzt gerne Steckbretter, > hast anfangs vermutlich nicht genügend oder nicht richtig > Abblockkondensatoren verwendet Was du nicht alles weißt: So schlecht war das Design gar nicht und überhaupt: wo kann ich denn diese Designregeln nachlesen. Meines Wissens - und so hatte ich das mal gelernt gehabt - ist es immer ein Kompromiss ein Layout zu erstellen (vor allen Dingen dann, wenn etwas klein werden soll). Ich benutze gerne Steckbretter? Woher weißt du das? Du schreibst dass so hin als würdest du mich und meine Arbeitsweise kennen? Ich verwende Steckbretter sogar relativ ungerne, schlicht aufgrund von Kabelführung und noch schlimmer nicht mehr einwandfreien Steckverbindungen die immer wieder das Problem an einer Schaltung sind. Aber ich verwende sie, schlicht deshalb, weil es oftmals die einzige Lösung ist noch zu entwickelnde Schaltungen zu testen. Aber wie gesagt stellst du es so dar, als ob ich das gerne mache (auch wenn ich manchmal - aber auch nur manchmal - ein Seckbrettjunkie bin, nämlich immer dann, wenn ich denke das muß doch auch auf dem Steckbrett gehen). Am liebsten mache ich mir Schaltungsmodule auf einem PCB, die Steckbrettkonform sind ... und so sollte auch der CH340N auf einem PCB sein, dass ich - auch einfach wegen der mechanischen Fixierung - dann dort weiterverwende. Außerdem hatte ich, wenn du das Layout angesehen hättest, wie vom Hersteller gefordert die Blockkondensatoren an den Pins angelegt gehabt plus einen zusätzlichen über der Betriebsspannung. Du mußt diese Unterstellung aber noch einmal posten, obwohl das schon lange geklärt war (schlich um jemanden blöd darzustellen und um deine scheinbare fachliche Kompetenz zu unterstreichen). Gregor J. schrieb: > Du verbindest das womöglich mit Dupontkabeln Was du nicht schon wieder alles weißt. Ts-ts-ts ! Meistens habe ich Drähte aus einem Innenkabel, die ich mir nach guter alter Väter Sitte auf die Länge bringe die ich benötige. Aber scheinbar hast du auch etwas gegen Kupferdrähte und verbindest deine Komponenten nur mit extra konfektionierten für deinen Gebrauch benötigten Verbindern. Allerdings habe ich auch Dupontkabel, die immer dann in den Müll wandern wenn etwas der Kabel wegen nicht geklappt hat. Gregor J. schrieb: > Du verbindest das womöglich mit > Dupontkabeln, Du hast auf der anderen Seite den UART mit einem ATMEGA > mit 16MHz betrieben, was krumme Baudraten und erhebliche Fehler > verursacht Wieviele Millionen von ATmega werden mit 16 MHz betrieben und funktionieren mit einer Baudrate von 115200 Bd absolut zuverlässig? Wenn der 16 MHz Quarz perfekt ist, ergibt sich bei einer Baudrate von 115200 Bd eine Abweichung in der Bitrate von 2,1% Rechnet man einen Fehler von vllt. 50 ppm am Quarz und noch falsche Ziehkondensatoren hinzu, hast du vllt. eine Abweichung in der Bitrate von 2,5 bis allerhöchstens 3%. Hiermit arbeitet noch jede serielle Schnittstelle einwandfrei ! Gregor J. schrieb: > was krumme Baudraten und erhebliche Fehler > verursacht, willst das alles aber nicht zugeben und Dir eingestehen. Nirgendwo, überhaupt nirgendwo habe ich geschrieben, das das keine "krummen" Baudraten erzeugt, aber "erhebliche" Fehler sind das nicht (und gebe ich auch so nicht zu). Und auch das ist etwas, das mich maßlos stört an deinen Aussagen: Dieses Abkanzeln als wäre ich "lernresisten", würde die Fachleute ignorieren (wie gesagt, was fachlich kompetente Menschen wie Lothar, Frank, Yalu und Jörg, auch andere die keine Moderatoren sind) zu sagen haben höre / lese ich gerne. Abgesehen davon gibt es in meinem Umfeld genügend, die auch mich als Fachmann bezeichnen (und du es glaubst oder nicht, ich habe den Meister und zusätzlich bin ich staatl. geprüfter Techniker. Allerdings weiß auch sehr wohl den Unterschied zu manchen studierten Leuten). Bei diesem Hinstellen eines anderen als "Depp" muß dir wohl schier einer abgehen oder? Gregor J. schrieb: > Du erzählst auch im > Nachhinein, wenn man Dich auf Deine Fehler aufmerksam macht, dass das > nicht stimme, weil Du es angeblich jetzt nochmal gestestet hast und > willst um jeden Preis beweisen, dass Du von Anfang an richtig gehandelt > hast Donald Trump in Deutschland? Nirgendwo, nirgendwo habe ich geschrieben dass ich richtig gehandelt habe. Wäre ich davon überzeugt, hätte ich hier nicht gepostet. Und - entgegen deiner Aussage - suche ich tatsächlich den Fehler bei mir nur manchmal kann ich mir den nicht erklären. An Fehler in einem Chip glaube ich angesichts der Unmenge an Chips nicht. Der bekannteste Fehler den ich kenne war der Pentium-Bug anno dazumals. Ansonsten gibt es für mich nur "leicht zu handelnde" Chips und eben "weniger leicht zu handelnde". Nachdem ich weiß auf was ich bei einem CH340N achten muß ist der für mich auch nicht mehr schwierig. Außerdem habe ich nicht mehr "nochmal" getestet, sondern ich habe die Schaltung und die Anbindung geändert, an irgendetwas mußte es ja gelegen haben und nachdem ich eben NICHT an einen Fehler im Chip geglaubt habe (aber auch nicht an die nicht ganz optimal platzierten Blockkondensatoren) mußte es etwas anderes sein. Gregor J. schrieb: > Mir ist schon klar, dass man das > Gesicht wahren will und es nicht einfach ist, die Fehler zuzugeben, aber > genau durch diese Haltung verlierst Du es und an Deine immer > anschließenden Erzählungen Boah, am liebsten würde ich hier jetzt etwas schreiben was ich selbst bei anderen nicht gut finden würde. Ich habe überhaupt kein Problem Fehler zuzugeben, mit Schaltungen und Programmierung macht man genügend Fehler und zwar immer wieder, manchmal - dummerweiße - auch immer wieder diselben. Ich muß hier kein Gesicht wahren, aber ich kann es ums verrecken nicht leiden wenn ich wie ein Penner dargestellt werde. Echt. Gregor J. schrieb: > die kommen vermutlich von > Deinem Aufbau oder wurden nicht richtig abgelesen oder mit Absicht ein > wenig 'verschönert', um dem ganzen eine gewisse Tragik zu verleihen. Die Signale hatte ich mit einem Logicanalyzer aufgenommen (weil ich schlicht außer einem Speicherscope) nichts anderes mehr habe und habe mir die Abweichungen der Impulslängen bei gesendeten Werten 0xCC und 0xAA angesehen und bestimmt, wie weit sie von der Solllänge abweichen. Hier gibt es für mich mit Sicherheit Lernbedarf, wie man Jitter richtig mißt. Für mich war es aber ein Mittel der Fehlersuche. So, alles in allem [ironie-an] lieber Gregor [ironie-aus] hast du mir in keinster Weise geholfen, keiner deiner Texte war für mich Sinnvoll und Zielführend und es würde mich sehr freuen (das hier dann keine Ironie), wenn du auf zukünftige Posts von mir einfach nicht reagierst. ------------------------------ Vielen Dank an alle anderen !
> wahren, aber ich kann es ums verrecken nicht leiden wenn ich wie ein > Penner dargestellt werde. Echt. Mach dir nix draus. Zur haelfte ist dieses Verhalten in Deutschland vollkommen normal. Ich frag mich auch oft ob diese Leute hier jemals im internationalen Umfeld gearbeitet haben. Zum anderen sind hier wohl ein paar alte Zausel unterwegs wo auch im echten Leben jeder die Hand ueber den Kopf zusammen schlaegt. > vllt. eine Abweichung in der Bitrate von 2,5 bis allerhöchstens 3%. > Hiermit arbeitet noch jede serielle Schnittstelle einwandfrei ! Ich hatte vor einigen Jahren da selbst mal ein Problem und hab da mal recherchiert. Interessanterweise gibt es nirgendwo eine "offizielle" Angabe wo die Grenze liegt. Aber so 3% gilt wohl als Obergrenze wo man von problemlosen Betrieb ausgehen kann. Und wie hier ja schonmal jemand anderes gesagt hat, fuer USB gelten da strengere Massstaebe. Es ist also mindestens mal erstaunlich wenn die Daten problemlos per USB zum Controller kommen, aber daraus dann zu schlecht sind. Vanye
Harald A. schrieb: > Da es > beim CH340 keine Seriennummern gibt, wird die Anmeldung bei Windows zum > Glücksspiel, d.h. der COM-Port ändert sich dauernd. > Wenig bekannt ist der FTDI-Baustein FT230XS - [...] Ja, schon wesentlich teurer, > [...] und natürlich gibt es auch eine ordentliche Seriennummer. Und da im uC-Net Forum Wissen scheinbar auch ein Glücksspiel ist und Anfänger die ahnungslos auf diesen Thread stoßen solche Aussagen vielleicht für bare Münze nehmen: Wenig bekannt ist hier im Forum scheinbar der CH340B - den gibt es auch schon seit Jahren (!) mit eingebautem EEPROM - fast genauso günstig wie der Rest der CH340-Reihe ... und natürlich gibt es auch eine ordentliche Seriennummer. Verwende als Hobbyist ausschliesslich den CH340B und habe keinerlei Probleme - weder mit der Baudrate, noch mit der eigenen Seriennummer unter Windows oder Linux... ;)
Jochen D. schrieb: > Wenig bekannt ist hier im Forum scheinbar der CH340B - den gibt es auch > schon seit Jahren (!) mit eingebautem EEPROM - fast genauso günstig wie > der Rest der CH340-Reihe ... und natürlich gibt es auch eine ordentliche > Seriennummer. > > Verwende als Hobbyist ausschliesslich den CH340B und habe keinerlei > Probleme - weder mit der Baudrate, noch mit der eigenen Seriennummer > unter Windows oder Linux... ;) Das mag ja sein, aber ist meine Aussage deshalb nun falsch oder abwegig? > Und da im uC-Net Forum Wissen scheinbar auch ein Glücksspiel ist und > Anfänger die ahnungslos auf diesen Thread stoßen solche Aussagen > vielleicht für bare Münze nehmen: Wie ist denn das zu verstehen? Möchtest Du die Reputation der Firma retten? Der CH340B mag die Seriennummern-Misere ja verbessern - genau wie eine Reihe anderer IC (CP210x oder MCP…) auch. Der „ahnungslose Anfänger“ stößt ja ganz gerne auf den CH340 ohne Seriennummer. Nimmt er halt beim nächsten Mal den CH340B oder eben nen ganz anderen.
Vanye R. schrieb: > Ich hatte vor einigen Jahren da selbst mal ein Problem und hab da mal > recherchiert. Interessanterweise gibt es nirgendwo eine "offizielle" > Angabe wo die Grenze liegt. Aber so 3% gilt wohl als Obergrenze wo man > von problemlosen Betrieb ausgehen kann. Das hängt auch von der Paketlänge ab. Beim AVR sind das max Startbit + 9 Datenbits + Parity + Stopbit = 12 Bitzeiten. Nur beim Startbit wird synchronisiert und beim 12. Bit sollten alle 3 Abtastzeitpunkte noch den gleichen Pegel haben. Damit kann man den genauen Wert ausrechnen. Und da es 2 Teilnehmer sind, muß der Wert noch halbiert werden, da die ja entgegengesetzt abweichen können. 3% je Teilnehmer, d.h. max 6% zusammen wird nicht mehr zuverlässig funktionieren. Das geht nur noch mit Baudratenquarz und 0% rechnerischer Fehler auf einer Seite. In der Praxis rechne ich den Fehler auf <1% aus, also max 2% gesamt. Die USB-Chips haben von Haus aus alle einen Jitter, da sie ja ein Vielfaches von 12MHz benötigen. Und glatte 12MHz ist ein denkbar ungünstiger Wert für Standardbaudraten. Ich hatte nicht schlecht gestaunt, als meine Baudratenerkennung an PCs mit echter UART einwandfrei funktionierte, an USB-Konvertern jedoch nicht. Auf dem Oszi habe ich dann die unterschiedlichen Bitlängen gut sehen können.
:
Bearbeitet durch User
Harald A. schrieb: > Das mag ja sein, aber ist meine Aussage deshalb nun falsch oder abwegig? Diese Aussage ist einfach falsch: > Da es beim CH340 keine Seriennummern gibt Impliziert nämlich die ganze CH340-Reihe. Und der CH340B hat unter anderem eine frei definierbare Seriennummer
:
Bearbeitet durch User
Peter D. schrieb: > Die USB-Chips haben von Haus aus alle einen Jitter, da sie ja ein > Vielfaches von 12MHz benötigen. Und glatte 12MHz ist ein denkbar > ungünstiger Wert für Standardbaudraten. Da sie aus den 12MHz sowieso 48MHz für USB machen müssen, dienen diese 48MHz auch als Frequenzbasis. Des weiteren beinhalten diese Chips auch einen fraktionalen Teiler, so das man selbst bis 48*19200, also 921600 nur einen Fehler von <= ±0.16% hat. Klar, Jitter ist vorhanden, aber im nur im Nanosekunden Bereich. Und da hat er praktisch keinerlei Auswirkungen auf UART Operationen.
Vanye R. schrieb: > Interessanterweise gibt es nirgendwo eine "offizielle" Angabe wo die > Grenze liegt. Weil das natürlich sehr auf die implementierte SIO-Hardware der beteiligten Komponenten ankommt. Nehmen wir mal den "üblichen" UART mit 8-fachem Oversampling, wo also 1 Bit 8x abgetastet werden kann. Der liegt dann also beim 1. Bit um bis zu 1/8 der Bitzeit daneben. Man hat also bereits da einen "Jitter", weil die Übertragung ja asynchron ist und das Startbit am RX-Eingang mal früher und mal später erkannt wird:
1 | Startbit Datenbit 0 |
2 | 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 |
3 | Baudtakt | | | | | | | | | | | | | | | | | | | | | | |
4 | RX -------------________________________------------------------_________ |
5 | RX --------------________________________------------------------________ |
6 | RX ---------------________________________------------------------_______ |
7 | Eingelesen 0 1 |
Dann nehmen diese UART gerne die "mittleren 3 Abtastungen" und machen daraus einen Mehrheitsentscheid, um den Pegel des Bits einzulesen. Ersatzweise kann man einfach die "mittlere Abtastung" nehmen, bei 8 Takten 0..7 also den Pegel am Takt 3. Nehmen wir jetzt mal reale Zahlen z.B. 9600/s, dann dauert 1 Bit 104µs, und der Jitter beim Erkennen des Startbits ist damit 13µs. Damit dann auch das letze Bit bei einem Telegramm, bei dem der Wert 0 übertragen wird, noch passt, darf die Mitte des Stopbits (das ist als einziges Bit high) nicht so weit "nach vorne" wandern, dass es als MSB erkannt wird. Es darf aber auch nicht mehr so weit "nach hinten" wandern, dass der Pegel des letzten Datenbits als Stopbit eingelesen wird. Das letzte Bit darf also höchstens um 50µs verschoben werden. Weil da idR. insgesamt 10 Bits übertragen werden, darf das jedes einzelne Bit (bei idealer Erkennung des Startbits) nur um 50µs/10 = 5µs = 5% = daneben liegen. Weil jetzt aber wie gesagt das Startbit nur mit Jitter erkannt wird, muss dieser Wert noch um den Jitter 13µs/10 Bits = 1,3% reduziert werden. Und damit kommen wir bei 3,7% heraus. Ein wenig "Reserve" abgezogen (z.B. wegen asymmetrischen oder sonstwie "flachen" Flanken), dann bleiben 3% über. Ralph S. schrieb: > Wenn der 16 MHz Quarz perfekt ist, ergibt sich bei einer Baudrate von > 115200 Bd eine Abweichung in der Bitrate von 2,1% Rechnet man einen > Fehler von vllt. 50 ppm am Quarz und noch falsche Ziehkondensatoren > hinzu, hast du vllt. eine Abweichung in der Bitrate von 2,5 bis > allerhöchstens 3%. Hiermit arbeitet noch jede serielle Schnittstelle > einwandfrei ! Diese 3% sind jetzt aber nicht der Wert, um den jeder der beiden Teilnehmer von einer "idealen Baudrate" abweichen darf, sondern diese 3% sind der Wert, den die Baudrate der beiden Teilnehmer voneinander(!!!1eins!elf) abweichen darf. Wenn beide Teilnehmer z.B. um +13,7% von der "idealen Baudrate" abweichen, dann funktioniert die Übertragung zwischen denen garantiert tadellos. Wenn aber ein Teilnehmer -2% von der "idealen Baudrate" abweicht und der andere um +2%, dann kommen (bei üblicher Hardware) genauso garantiert Übertragungsfehler.
:
Bearbeitet durch Moderator
Norbert schrieb: > Klar, Jitter ist vorhanden, aber im nur im Nanosekunden Bereich. Der Jitter ist aber deutlich auf dem Oszi zu sehen. Soweit ich die Funktion des fraktionalen Teilers verstanden habe, wird dafür der Vorteiler 1:8 der Bitzeit verwendet. Die Baudratenbasis wird also mal /8 und mal /7 geteilt und das ergibt einen erheblichen Jitter.
> Der Jitter ist aber deutlich auf dem Oszi zu sehen.
Ich kenn auch Bausteine die haben einen fraktionalen Teiler fuer
die serielle Schnittstelle. Dann ist das 3bit ploetzlich etwas
breiter wie das 4bit aber im Ergebnis beim 9Bit ist dann wieder
alles tacko. Deshalb hab ich ja vorgeschlagen mal mit unendlicher
Persistenz aufzuzeichen. Dann haette man das gesehen.
Vanye
Jochen D. schrieb im Beitrag > Diese Aussage ist einfach falsch: > >> Da es beim CH340 keine Seriennummern gibt > > Impliziert nämlich die ganze CH340-Reihe. Und der CH340B hat unter > anderem eine frei definierbare Seriennummer Das ist fein! Ehre, wem Ehre gebührt!
Lothar M. schrieb: > Wenn aber ein Teilnehmer > -2% von der "idealen Baudrate" abweicht und der andere um +2%, dann > kommen (bei üblicher Hardware) genauso garantiert Übertragungsfehler. Das ist natürlich richtig!
Peter D. schrieb: > Der Jitter ist aber deutlich auf dem Oszi zu sehen. Soweit ich die > Funktion des fraktionalen Teilers verstanden habe, wird dafür der > Vorteiler 1:8 der Bitzeit verwendet. Die Baudratenbasis wird also mal /8 > und mal /7 geteilt und das ergibt einen erheblichen Jitter. Ich nutze hier einen einfachen, selbstgeschriebenen LA mit 5ns Auflösung. Wenn man beständig \125 also 0x55 durch die Leitung schiebt, dann sind die einzelnen Datenbits sehr stabil. Allerdings scheint das Stoppbit künstlich verlängert. (Habe noch nicht herausgefunden warum) Auf einem Scope würde das natürlich als (Pseudo)Jitter erscheinen, da man nur ein präzises Stoppbit erwarten würde. Ach ja, gemessen mit einem pl2303. Im Anhang zwei vcd Dateien mit 4MBit und 921.6kBit.
Norbert schrieb: > Im Anhang zwei vcd Dateien mit 4MBit und 921.6kBit. Womit sollte man die denn anschauen können? Google meint, das wären Disk-Images: - https://www.google.com/search?q=vcd+dateien > Ach ja, gemessen mit einem pl2303. Du meinst an einem pl2303, oder?
Lothar M. schrieb: > Womit sollte man die denn anschauen können? Zum Beispiel mit GTKwave (aptitude install gtkwave), einem der vielen freien vcd Viewer. (Auch für Windows WIMRE) (Oder zB. mit vi (Ist aber nicht so schön)) https://en.wikipedia.org/wiki/Value_change_dump > Google meint, das wären Disk-Images: Vermutlich arbeitet Google auch schon mit AI. ;-) > Du meinst an einem pl2303, oder? Gemessen wurde der Output, welcher vom PC über USB an einen PL2303 gesendet und von diesem an seinem TX Ausgang erzeugt wurde. Hoffe das war präzise genug.
:
Bearbeitet durch User
Norbert schrieb: > Allerdings scheint das Stoppbit künstlich verlängert. (Habe noch nicht > herausgefunden warum) Der Baustein scheint wohl unabhängig von der Baudrate nach jedem Byte 0,5µs Verschnaufpause zu brauchen. Je höher die Baudrate, umso mehr fällt das auf.
Yalu X. schrieb: > Der Baustein scheint wohl unabhängig von der Baudrate nach jedem Byte > 0,5µs Verschnaufpause zu brauchen. Hab's gerade mal mit 19200baud getestet. Da braucht das Stoppbit 57340ns im Vergleich zu 52010ns für normalen Bits. Das wäre eine 1/10 Bitbreite länger. Bei 300baud sind's übrigens 3670µs zu 3329µs. Scheint wohl nicht so sauber zu skalieren. Immerhin sind Startbit und Datenbits absolut perfekt (im Rahmen meiner Messmöglichkeiten)
Norbert schrieb: > Scheint wohl nicht so sauber zu skalieren. Immerhin sind Startbit und > Datenbits absolut perfekt Das ist letztlich dann auch nur ein Schieberegister, wo diese Bits mit dem Baudtakt rausgetaktet werden. Da kann bei stabilem Baudtakt nicht viel Jittern. > Das wäre eine 1/10 Bitbreite länger. Das geht noch genauer:
1 | 57340ns/52010ns = 1,102424029 |
2 | 3670µs /3329µs = 1,102433163 |
Im Rahmen der Messgenauigkeit ist diese Verzögerung konstant und abhängig vom Baudtakt. Man könnte fast meinen, da ist ein zeitverplempernder Bug in der Hardware... ;-)
:
Bearbeitet durch Moderator
Angehängte Dateien:
-
921600.png
4,6 KB
Lothar M. schrieb: > Im Rahmen der Messgenauigkeit ist diese Verzögerung konstant und > abhängig vom Baudtakt. Man könnte fast meinen, da ist ein > zeitverplempernder Bug in der Hardware... ;-) Na ja, nicht ganz. Bei zügigerer Gangart dehnt sich das Stoppbit schon ein wenig mehr. So sehr, dass man nicht mehr messen, sondern nur noch schauen muss. ;-)
Ich habe gerade mal nachgeschaut, wie sich andere USB-UARTs bzgl. der Pausen zwischen den übertragenen Bytes verhalten:
1 | max. Baudrate/Bd |
2 | Typ absolut ohne Pausen |
3 | ────────────────────────────────── |
4 | FT232R 4.000.000 4.000.000 |
5 | CP2102 6.000.000¹ 3.000.000 |
6 | CH340G 3.000.000 255.319² |
7 | ────────────────────────────────── |
8 | ¹) Lt. Datenblatt nur 1 MBd, aber auch 2 MBd, 3 MBd, 3,43 MBd, 4 MBd und |
9 | 6 MBd lassen sich einstellen |
10 | ²) = 12E6 / 47 |
Der FT232R sendet die Bytes auch bei der höchsten Baudrate ohne Pausen. Beim CH340G sind die Pausenlängen mehr oder weniger zufällig. Insofern verhält er sich etwas anders als der PL2303. Beim CP2102 können die Pausen sporadisch bis zu 300 µs lang werden, weswegen die (ohnehin außerhalb der Spezifikation liegenden) 4 und 6 MBd vermutlich weniger Durchsatz bringen als die 3 MBd.
Ralph S. schrieb: > So, alles in allem [ironie-an] lieber Gregor [ironie-aus] hast du mir in > keinster Weise geholfen, keiner deiner Texte war für mich Sinnvoll und > Zielführend und es würde mich sehr freuen (das hier dann keine Ironie), > wenn du auf zukünftige Posts von mir einfach nicht reagierst. Undankbar zu sein und andere zu beleidigen gehört zu den Symptomen dessen, was ich bereits erwähnt habe – eigentlich habe ich mit dem AVR+16MHz und den daraus resultierenden krummen Baudraten die wichtigste Info hier im Thread gegeben. Ach ja, da Du Trump erwähnt hast – einfach mal in den Spiegel schauen schadet nie.
:
Bearbeitet durch User
Yalu X. schrieb: > Ich habe gerade mal nachgeschaut, wie sich andere USB-UARTs bzgl. der > Pausen zwischen den übertragenen Bytes verhalten: Danke. Kurze Pausen beim Senden sind zwar unschön aber stören meist wenig. Problematischer wären Fehler beim Empfangen von kurzen Datenpaken die eigentlich in den Empfangspuffer der USB-UARTs passen sollten.
:
Bearbeitet durch User
Stefan K. schrieb: > Danke. Kurze Pausen beim Senden sind zwar unschön aber stören meist > wenig. Problematischer wären Fehler beim Empfangen von kurzen Datenpaken > die eigentlich in den Empfangspuffer der USB-UARTs passen sollten. Das habe ich gerade für den PL2303 getestet. Alle krummen Baudraten bis 921.6kBaud, sowie 1,2,3,4MBaud lassen sich fehlerfrei vom µC zum PC übertragen. Getestet mit 64KiB Blöcken, jeweils 256 mal mit 0x00…0xff gefüllt.
Norbert schrieb: > Alle krummen Baudraten bis 921.6kBaud, sowie 1,2,3,4MBaud lassen sich > fehlerfrei vom µC zum PC übertragen. Mein Begriff der 'krummen Baudraten' meint, das die nicht in das Vielfache von 9600 passen, also z.B. 111111 statt 115200, die dann eine Abweichung im Timing jedes Bytes verursachen, hier im Beispiel dann ca. 3,5% als Tabellenangabe (als Betrag, das Vorzeichen lassen wir mal weg). Eine 921600 Baudrate wäre nach dieser Definition also keine krumme Baudrate, da sie exakt das Vielfache von 9600 und folglich auch das Vielfache von 115200 ist und demnach auch keine Fehler im Timing verursacht (Timingabweichung 0,0%, wenn man eine minimale Quarzungenauigkeit selbst jetzt beiseitelegt). Am Ende ist es natürlich nur eine Konventionssache, was mit diesem Begriff gemeint ist, aber man sollte das nicht durcheinanderbringen oder vermischen.
:
Bearbeitet durch User
Gregor J. schrieb: > Mein Begriff der 'krummen Baudraten' meint, das die nicht in das > Vielfache von 9600 passen, Na ja, dann wäre alles von – Moment, muss mal nachschauen was das Ding kann – 50 75 110 134 150 200 300 600 1200 1800 2400 4800 – krumme Baudraten. Ich hatte gehofft das der Unterschied zwischen den ›traditionell‹ Genutzten und dem Vielfachen eines glatten MBaud aus dem Kontext klar wird. Deiner Definition nach wären diese MBaudraten alle ›krumm‹, obschon sie bei glatten MHz Quarzen perfekt geeignet sind. Des weiteren, jeder halbwegs akzeptable, etwas größere µC kann im Jahre 2024 den Vorteiler mit mindestens einem Achtel oder sogar einem Sechzehntel einstellen und damit so ziemlich jede denkbare Baudrate realisieren.
Norbert schrieb: > Na ja, dann wäre alles von – Moment, muss mal nachschauen was das Ding > kann – 50 75 110 134 150 200 300 600 1200 1800 2400 4800 – krumme > Baudraten. Ich habe 9600 genommen, weil das einfacher im Beispiel zu sehen ist. __ > Deiner Definition nach wären diese MBaudraten alle ›krumm‹, obschon sie > bei glatten MHz Quarzen perfekt geeignet sind. Ja, aber ich bezog mich in meiner Aussage in erster Linie nur auf die Standardbaudraten, also das Vielfache von 9600. Wenn wir die glatten hohen Zehner-Baudraten wie 1 oder 2 MBit in die Betrachtung einbeziehen wollen, dann ist meine Definition unpräzise und man müsste sagen, dass eine Baudrate dann 'krumm' ist, wenn die des Senders von der des Empfängers abweicht, also z.B. 111111 zu 115200 oder 1,05 Mbit zu 1Mbit. _ > Des weiteren, jeder halbwegs akzeptable, etwas größere µC kann im Jahre > 2024 den Vorteiler mit mindestens einem Achtel oder sogar einem > Sechzehntel einstellen und damit so ziemlich jede denkbare Baudrate > realisieren. Ja, das geht z.B. mit den STM32 und deren Fraktionalbaudratengenerator ganz gut, der ATMEGA ist in dem Sinne etwas altbacken oder obsolet, weswegen man bei Tests immer darauf achten sollte, dass das nur mit einem entsprechenden Quarz gehen kann, so dass es mit dem Vorteiler dann auch wirklich passt, was dem Autor offensichtlich nicht bewusst war oder nach wie vor nicht ist. Bei solchen Tests muss man definitiv wenigstens auf einer Seite einen Baudratenfehler von 0% haben und im Betrieb später am besten auch – also entweder CH340 mit Quarz und dann kann man sich auf der anderen Seite einen gewissen zulässigen Baudratenfehler erlauben oder CH340 ohne Quarz und auf der anderen Seite dann eine Baudrate ohne diesen Fehler (0%). Wenn man auf beiden Seiten Baudraten mit Timinigabweichungen verwendet, dann kann es sehr schnell schiefgehen, weil sich die Fehler addieren, manchmal können sie sich aber auch aufheben. Auch wenn es vermeintlich funktioniert, kann es passieren, dass man einen anderen IC nimmt oder sich die Temperatur ändert und das ganze Konstrukt auf einmal nicht mehr funktioniert. Man sollte sich die UART-Timings, die Sende- und Empfangsverläufe immer auch mit einem Oszilloskop anschauen – das ist das wichtigste überhaupt.
:
Bearbeitet durch User
Stefan K. schrieb: > Kurze Pausen beim Senden sind zwar unschön aber stören meist wenig. Klar, sie reduzieren halt etwas den Durchsatz, weswegen man den Vorteil hoher Baudraten nicht voll nutzen kann, was aber meist nicht so schlimm ist. > Problematischer wären Fehler beim Empfangen von kurzen Datenpaken > die eigentlich in den Empfangspuffer der USB-UARTs passen sollten. Bei manchen USB-UARTs kann bei hohen Baudraten schon mal der Empfangspuffer überlaufen, wenn dauerhaft Daten ankommen. Bei kurzen Datenpaketen, gefolgt von einer Pause, sollte es eigentlich keine Probleme geben. Hast du diesbezüglich schon schlechte Erfahrungen gemacht? Ein anderer Punkt, der manchmal stört, ist die verzögerte Übertragung der UART-Daten an die USB-Schnittstelle. Je nach Baustein gibt es verschiedene Kompromissmöglichkeiten, um einerseits diese Verzögerung möglichst kurz zu halten, andererseits aber den USB nicht unnötig mit Minipaketen zu verstopfen. Die Echtzeitfähigkeit einer direkt (ohne USB) an den Host angebundenen UART erreicht man damit aber nie.
Gregor J. schrieb: > der ATMEGA ist in dem Sinne etwas altbacken oder obsolet, Benutze die zwar nicht, aber selbst die XMEGAs sollen das wohl auch schon können. Bei der ganzen Betrachtung war nur eines wirklich wichtig: Es gab die Behauptung dass diese UART-USB Chips einen wilden Jitter erzeugen, was auf die Abhängigkeit des Baudratengenerators vom 12MHz Quarz zurückgeführt wurde. Dies hat sich eindeutig als falsch herausgestellt und wurde mit Meßdaten untermauert. Die zweite, sich aus den entdeckten verlängerten Stoppbits ergebende Frage war, ob dies in der anderen Richtung zu Problemen führen würde. Das konnte zumindest für den PL2303 ebenfalls ausgeschlossen werden. Alles andere sind nur unwichtige Nebenkriegsschauplätze und haben mit dem eigentlichen Thema nichts zu tun (außer die Diskussion zu verwässern).
Yalu X. schrieb: > Bei manchen USB-UARTs kann bei hohen Baudraten schon mal der > Empfangspuffer überlaufen, wenn dauerhaft Daten ankommen. An diesen Informationen wäre ich ebenfalls interessiert. Zumindest beim PL2303 kann man das Szenario aber getrost vergessen.
Norbert schrieb: > Bei der ganzen Betrachtung war nur eines wirklich wichtig: > Es gab die Behauptung dass diese UART-USB Chips einen wilden Jitter > erzeugen, was auf die Abhängigkeit des Baudratengenerators vom 12MHz > Quarz zurückgeführt wurde. Ich habe in der Vergangenheit meine Tests durchgeführt und keine offensichtlichen, groben Fehler entdeckt, unter anderem habe ich mir angeschaut, wie der CH340N mit einer relativ schnellen Datenübetragung zurechtkommt und z.B. eine Bilddatei von ca. 100 Kilobyte in Schleife (RX und TX des CH340N verbunden) mit dem PC durch den durchgejagt. Bei 1Mbit kam die Datei unbeschädigt an, bei 2Mbit war das Bild ab einem gewissen Zeitpunkt nur ein schwarzer Hintergrund, was eindeutig belegte, dass er das nicht mehr verarbeiten konnte (Bufferproblem). Dauerfeuer ist aber laut Hersteller bis 460800 erlaubt, insofern dürfte das schon bei 1Mbit nicht mehr funkionieren, hat aber funktioniert – es gibt aber noch Verzögerungen duch den PC und das Sendeterminal, insofern könnten die Angaben im Datenblatt schon zutreffend sein. Wie auch immer, ich werde demnächst sowieso neue, andere und bessere Tests mit dem CH340N in diesem Kontext durchführen, weil ich eben diese maximale Dauerfeuerrate für das Programmieren von größeren SPI-Speichern mit meinen selbstgeschriebenen PC-Anwendungen untersuchen und nutzen möchte.
:
Bearbeitet durch User
Gregor J. schrieb: > Dauerfeuer > ist aber laut Hersteller bis 460800 erlaubt, Ups. Das ist aber eine ernsthafte Limitierung. Sieht ja fast schon so aus, als wenn die ›ancient‹ USB-LS (1.5MBit/s) benutzen. Andererseits, wenn's für die Anwendung ausreichend ist… Yalu X. schrieb: > Ein anderer Punkt, der manchmal stört, ist die verzögerte Übertragung > der UART-Daten an die USB-Schnittstelle. Je nach Baustein gibt es > verschiedene Kompromissmöglichkeiten, um einerseits diese Verzögerung > möglichst kurz zu halten, andererseits aber den USB nicht unnötig mit > Minipaketen zu verstopfen. Die Echtzeitfähigkeit einer direkt (ohne USB) > an den Host angebundenen UART erreicht man damit aber nie. Das habe ich gerade mal – nur der Vollständigkeit halber – ebenfalls getestet. µC und PC senden sich ein einzelnes Ping-Pong Byte zu, wobei auf der PC Seite Zeitstempel genommen werden. Jeweils ein Byte hin und zurück: leicht variabel um die 65ms. Das sieht schon verdächtig nach einer sechzehntel Sekunde aus. Muss ich mal in den USB Specs schauen, wo das herkommt.
Angehängte Dateien:
Norbert schrieb: > Ups. Das ist aber eine ernsthafte Limitierung. Sieht ja fast schon so > aus, als wenn die ›ancient‹ USB-LS (1.5MBit/s) benutzen. Andererseits, > wenn's für die Anwendung ausreichend ist… Es gibt noch andere ICs in der CH340-Familie – auch mit deutlich höheren Dauerfeuerraten (z.B. 1, 2, 6 oder 9 MBit), auch in DUAL-Ausführungen, ist aber alles eine Frage des Geldes, was dann letztendlich auf die Leiterplatte kommt. Im Normalfall, d.h. beim Hantieren eines Otto-Normalverbauchers mit einem µController braucht man solche schnellen USB-UART-Brücken-ICs nicht, hier reichen die günstigeren, mit moderaten Dauerfeuerraten ausgestatteten völlig aus.
Angehängte Dateien:
Da hier im Thread auch Spekulationen und Berechnungen zu dem maximalen Baudratenfehler gemacht wurden, gibt es im Angang noch die maximalen Baudratenfehler aus den Datenblättern (ATMEGA328P und CH340) – man muss das Rad nicht neu erfinden, Berechnungen dazu wurden schon angestellt, aber man kann seine eigenen Überlegungen und Berechnungen damit vergleichen. Der maximal zulässige Baudratenfehler hängt im Wesentlichen von der Anzahl der übertragenen Bits ab (der Fehler setzt sich fort und addiert sich mit jedem Sendebit) und der Art und Weise wie in der Mitte eines Bits oder generell wie gesampelt wird. Auf dem zweiten Bild sind die Angaben zu den Varianten des CH340 – hier hängt es im Wesentlichen davon ab, ob eben mit Quarz oder ohne betrieben wird, aber beim Empfang haben offenbar alle einen Fehler von 2%, so zumindest könnte man die Aussage des Datenblatts auffassen, was mit dem Einsynchronisieren auf das ankommende Signal zusammenhängen könnte.
:
Bearbeitet durch User
Norbert schrieb: > Jeweils ein Byte hin und zurück: leicht variabel um die 65ms. Das sieht > schon verdächtig nach einer sechzehntel Sekunde aus. Muss ich mal in den > USB Specs schauen, wo das herkommt Wahrscheinlich schickt der Sender ein BRK um das Ende der "Nachricht" zu signalisieren. Ich hatte auch die Aufgabe kleine Pakete schnell zwischen rpi und avr auszutauschen. Ohne Aufruf von tcdrain() beim Senden vom rpi ging das im Dauerbetrieb gar nicht. Mit tcdrain() war die Latenz viel zu groß. Lösung war tcdrain() durch "Warten bis das letzte Byte den rpi verlassen hat" zu ersetzen.
Harald schrieb: > Ich hatte auch die Aufgabe kleine Pakete schnell zwischen rpi und avr > auszutauschen. Es geht um ein USB-CDC Device zwischen µC und PC. Nicht um UART <-> UART. Harald schrieb: > Wahrscheinlich schickt der Sender ein BRK um das Ende der "Nachricht" zu > signalisieren. Eindeutig Nein. Wie oben bereits beschrieben habe ich mit einem LA aufgezeichnet. Und mal so nebenbei, wenn mir irgendetwas ungefragt mit einem Break an meinem Datenstrom herumwursteln würde, flöge es umgehend raus und in die Müllkiste. Des weiteren, ich hatte von einem Ping-Pong mit einem Byte gesprochen. Da muss man nicht warten bis etwas gesendet wurde, da wartet man beidseitig abwechselnd auf den Empfang des Bytes und retourniert es.
:
Bearbeitet durch User
Yalu X. schrieb: > Ich habe gerade mal nachgeschaut, wie sich andere USB-UARTs bzgl. der > Pausen zwischen den übertragenen Bytes verhalten: > max. Baudrate/Bd > Typ absolut ohne Pausen > ────────────────────────────────── > FT232R 4.000.000 4.000.000 Bist du sicher, dass der FT232R und die 4MBd echt sind? Laut Datenblatt und AN232B-05 "Configuring FT232R, FT2232 and FT232B Baud Rates" sind maximal 3MBd möglich. Mehr habe ich bei meinem Adapter auch nicht gesehen.
Norbert schrieb: > Es geht um ein USB-CDC Device zwischen µC und PC. CH340 ist kein CDC. USB-Seriell-Bridges können CDC-Devices sein, sind es aber meistens nicht, sondern brauchen eigene, proprietäre Devicetreiber.
Harald K. schrieb: > CH340 ist kein CDC. USB-Seriell-Bridges können CDC-Devices sein, sind > es aber meistens nicht, sondern brauchen eigene, proprietäre > Devicetreiber. Ahhh, interessant. Hatte bisher noch nie so genau in die Descriptoren geschaut, da es einfach funktioniert wie erwartet. Aber ich werde das auf jeden Fall mal im Hinterkopf behalten.
Harald K. schrieb: > USB-Seriell-Bridges können CDC-Devices sein, sind es aber meistens > nicht Genauer gesagt: Sie können vorgeben, CDC-Devices (also Modems) zu sein, sind es aber nie, da es eben Bridges sind. Norbert schrieb: > Ahhh, interessant. Hatte bisher noch nie so genau in die Descriptoren > geschaut Man erkennt den Unterschied auch daran, dass CDC-Devices als /dev/ttyACM*, die anderen als /dev/ttyUSB* erscheinen.
:
Bearbeitet durch Moderator
Yalu X. schrieb: > Genauer gesagt: Sie können vorgeben, CDC-Devices (also Modems) zu > sein, sind es aber nie, da es eben Bridges sind. Äh, das ist jetzt eine andere Spitzfindigkeit. Der Punkt, auf den ich hinauswollte, ist, ob sie die USB-Standardgeräteklasse "CDC" implementieren oder ob sie eine komplett andere Ansteuerung benötigen. (Wenn wir Spitzfindigkeiten auf die Spitze treiben wollen, müssen wir zwischen CDC ACM und CDC ECM unterscheiden - beide fallen in die Kategorie "CDC", sind aber komplett unterschiedliche Dinge. Das erste, ACM, das ist das, was ursprünglich mal für Modems geschaffen wurde, das zweite wiederum sind Ethernet-Adapter ...)
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.