Jahrelang hatte ich keine Probleme mit schneller USART-Ausgabe auf Arduino nano3 oder mega2560 unter WinAVR. Momentan sehe ich unerwartete Probleme bei Atmega32u4 und hterm bei 256000bd. Der Code ist angehängt. Darin ist auch main.hex. In einer Schleife werden 2 Meldungen über USART ausgegeben. Nach einer ganzen Weile werden die Meldungen auch korrekt von hterm angezeigt, anfangs jedoch nicht. Es dauert eine ganze Weile bis korrekte Zeichen kommen. wenn ich ein delay 100us einbaue nach der ersten Zeile klappt es rascher. es kommen Ausgaben in der Art: ‚)R"•ÍÑ•2I5ÿ…FRAM sequentiell schreiben teste FRAM FRAM sequentiell schreiben teste FRAM FRAM sequentiell schreiben teste FRAM FRAM sequentiell schreiben .... am Ende klappt es also, aber am Anfang kommt Unsinn. Ohne das delay kann der Unsinn recht lange erscheinen. Das macht natürlich wenig Sinn. früher kamen bereits die ersten beiden Zeichen (A und \n) aus main.c Zeile 226/227 bereits richtig an. Frage: woran liegt das? wie kann man das beheben ohne viel an Geschwindigkeit zu verlieren?
:
Verschoben durch Admin
Matthias W. schrieb: > korrekt von hterm Hi, hterm "Hyperterminal" am PC? Probier mal Teraterm oder anderes alternatives PC-Terminal. ciao gustav
:
Bearbeitet durch User
Karl B. schrieb: > hterm "Hyperterminal" am PC? bisher lief das viele Jahre gut. > Probier mal Teraterm Danke Gustav. Du meinst dieses: https://de.wikipedia.org/wiki/Tera_Term http://ttssh2.osdn.jp/index.html.en https://osdn.net/projects/ttssh2/releases/ ich probiere es aus. Es gibt eine exe-Version und eine zip-Version. > oder anderes alternatives PC-Terminal. früher nutzte ich das Bray-Terminal gerne und oft. Bis es Probleme gab die mit hterm nicht auftraten.
ich habe das zip von Tera Term ausgepackt, TERATERM.INI editiert wie in
README-archive.txt angeraten und ein Fenster gestartet. Das Verbinden
klappt, nur leider sieht die Ausgabe ähnlich dem obigen Problem aus:
‚)Rb•ÍÑ•2I5ÿ…FRAM sequentiell schreiben
teste FRAM
FRAM sequentiell schreiben
teste
FRAM
FRAM sequentiell schreiben
...
nach Rb zeigt TeraTerm chinesische/japanische Zeichen die hier nicht
korrekt dargestellt werden.
so einfach verschwindet das Problem nicht.
Matthias W. schrieb: > Frage: > woran liegt das? wie kann man das beheben ohne viel an Geschwindigkeit > zu verlieren? Karl B. schrieb: > Probier mal Teraterm oder anderes alternatives PC-Terminal. Das hat garantiert nichts mit dem Terminal Programm zu tun. Die Arduinos haben als Takt-Referenzgeber einen keramischen Resonator der je nach Ausführung, Toleranz und Temperatur keine ausreichend genauen hohen Baudraten erlaubt. Matthias W. schrieb: > am Ende klappt es also, aber am Anfang kommt Unsinn. Typisches Symptom eines driftenden Referenz-Taktes. Da wird ein Bauteil ein bisschen wärmer oder kälter und schon ändert sich was im Kleinen beim Takt. Ich habe die Erfahrung gemacht dass je nach Resonator schon bei 115200 Baud keine zuverlässige Übertragung mehr möglich ist. Bei bzw. bis zu 57600 Baud funktioniert alles gut - bisher keine Ausfälle erlebt. Matthias W. schrieb: > wie kann man das beheben ohne viel an Geschwindigkeit > zu verlieren? Statt Resonator einen Quarz mit zwei Lastkapazitäten einbauen. Ist wegen der Platzverhälnisse nicht ganz einfach. Auch elektrisch (Masseführung, Verbindung) muss man ein bisschen aufpassen. Ein Zeichen dass der Kermaik-Resonator dran schuld ist, ist auch dass die Designer des Arduino sich nicht getraut haben für den USB-AVR keinen Quarz vorzusehen.
Matthias W. schrieb: > Arduino nano3 oder mega2560 unter WinAVR. Momentan sehe ich unerwartete > Probleme bei Atmega32u4 Kann sein dass ich durch die unklare Angabe der Konstellation etwas missverstanden habe. Ob der Atmega32u4 jetzt ein Arduino ist oder nicht und ob er mit Quarz oder kermaik- Oszillator betrieben wird ist nicht klar ... Trotzdem ist so etwas ein klares Zeichen für einen driftenden und zu stark abweichenden Takt (kann im Extremfall auch bei Quarzbetrieb auftreten): Matthias W. schrieb: > es kommen Ausgaben in der Art: > > ‚)R"•ÍÑ•2I5ÿ…FRAM sequentiell schreiben
Jo Mei schrieb: > Das hat garantiert nichts mit dem Terminal Programm zu tun. sieht so aus. > Die Arduinos haben als Takt-Referenzgeber einen keramischen > Resonator der je nach Ausführung, Toleranz und Temperatur > keine ausreichend genauen hohen Baudraten erlaubt. danke für den Hinweis. keine Ahnung was das wirklich auf diesen ProMicro-Boards ist. Es ist jedenfalls nicht sehr groß. bisher sah ich solche Probleme nicht. Beim mega2560 war ein Quarz drauf. Allerdings musste ich den mal erneuern weil er nach 2 Jahren nicht mehr lief. beim Arduino nano ist auch etwas kleines drauf. Das schien stets zu laufen. Nie Probleme. wenn man USB etwas schneller machen will - dazu ist der Chip doch da - so sollte auch der Takt +-0.25% genau sein. Ist es nicht so? Also müsste das Teil doch genau genug sein? wenn man die Tabellen im Datenblatt mit den dort angegebenen teilweise großen Abweichungen anschaut? > Typisches Symptom eines driftenden Referenz-Taktes. Da wird > ein Bauteil ein bisschen wärmer oder kälter und schon ändert > sich was im Kleinen beim Takt. kleine Änderungen sollten doch wohl kein Problem sein? ich halte ja keinen Lötkolben in die Nähe. Bestenfalls ist da der Lüfter des Laptops eine Wärmequelle. > Ich habe die Erfahrung gemacht dass je nach Resonator schon bei > 115200 Baud keine zuverlässige Übertragung mehr möglich ist. > Bei bzw. bis zu 57600 Baud funktioniert alles gut - bisher keine > Ausfälle erlebt. ich kann das mal probieren. > Statt Resonator einen Quarz mit zwei Lastkapazitäten einbauen. danke für den Hinweis ! > Ist wegen der Platzverhälnisse nicht ganz einfach. ich schau das mal an. Irgendwie ist das doch komisch. Diese Platinen werden doch in riesigen Stückzahlen gemacht? Auch von bekannten Herstellern. Das Design ist ja nicht made in China. Meines Wissens stammt das von SparcFun. Die sollten doch wissen was sie tun? Oder? Es gibt noch eine neuere Ausführung von SparcFun. Die ist rot. Die habe ich nicht.
Ist es nicht möglich, dass der Oszillator und eine eventuell nachgeschaltete PLL nach dem Aktivieren einfach eine Zeit braucht bis der Takt stabil ist? Bin mit dem Chip jetzt nicht wirklich vertraut, bei anderen µCs ist es aber üblich, auf diverse Statusbits zu warten nachdem man die Taktquelle ändert. Von CLKPR = (0<<CLKPS1) | (0<<CLKPS0); // laeuft mit 16 MHz bis zur Ausgabe der ersten Zeichen scheints auf den ersten Blick recht schnell zu gehen.
Matthias W. schrieb: > keine Ahnung was das wirklich auf diesen ProMicro-Boards ist. Es ist > jedenfalls nicht sehr groß. Es sollte auch für dich nicht schwer sein einen Link zu einem Board zu posten oder ein Bild an einen Beitrag anzuhängen. Du kannst dein Board sehen, wir nicht. Matthias W. schrieb: > Beim mega2560 war ein Quarz drauf. > Allerdings musste ich den mal erneuern weil er nach 2 Jahren nicht mehr > lief. Da ist immer ein Quarz drauf. Wenn der Mega2560 auch mit Quarz getaktet ist müssten zwei drauf sein. Jetzt kapiert? Ich sehe bei den Arduinos immer nur einen Quarz. Matthias W. schrieb: > Diese Platinen > werden doch in riesigen Stückzahlen gemacht? Soll das ein Argument sein dass die Dinger unter allen Umständen garantiert funktionieren? Matthias W. schrieb: > kleine Änderungen sollten doch wohl kein Problem sein? Wenn du schon an der "Kotzgrenze" bist: schon. Ich sehe schon, es ist dir nicht leicht beizubringen, da bin ich dann mal draussen. Auch weil du es nicht schaffst deine Konfiguration klar darzstellen. Da kommt ein wildes Sammel- surium von Gedankenfetzen.
rµ schrieb: > und eine eventuell nachgeschaltete PLL Welche PLL? rµ schrieb: > Bin mit dem Chip jetzt nicht wirklich vertraut Dann lies das Datenblatt wenn du mitreden willst. Die Takterzeugung ist gegenüber heutigen modernen Controllern sehr einfach.
Jo Mei schrieb: > Ob der Atmega32u4 jetzt ein > Arduino ist oder nicht und ob er mit Quarz oder kermaik- > Oszillator betrieben wird ist nicht klar ... es ist ein blaues ProMicro-Board aus China. Rechts am Platinenrand das größere Teil scheint ein 16MHz-Quarz und direkt daneben 2 kleine Kondensatoren. Das sollte doch so gehen? Auf der Rückseite steht V1.1. es gibt von SparcFun dasselbe Design etwas optimiert in rot V1.3. Quarz und Kondensatoren sehen da genauso aus. keine Ahnung ob da eine Fehldimensionierung ist. Falls ja müssten ja viele so ein falschbestücktes Board bekommen haben? ich kann den Frequenzzähler mal dranhängen oder das Oszi mit dem eingebauten Zähler. Kleine Abweichungen sind per Oszi sonst nicht einfach zu sehen.
rµ schrieb: > bis zur Ausgabe der ersten Zeichen scheints auf den ersten Blick recht > schnell zu gehen. das stimmt. Die PLL erzeugt den Takt für USB. Sind wohl 48 MHz. die 16MHz für die CPU kommen wohl direkt aus dem Quarz, so wie auch beim mega2560-Board.
Jo Mei schrieb: > rµ schrieb: >> und eine eventuell nachgeschaltete PLL > > Welche PLL? Darum eventuell, was weiss ich was da drin verbaut ist. > rµ schrieb: >> Bin mit dem Chip jetzt nicht wirklich vertraut > > Dann lies das Datenblatt wenn du mitreden willst. Die > Takterzeugung ist gegenüber heutigen modernen Controllern > sehr einfach. Ja mag sein, instantan mit richtiger Frequenz anlaufen tut der Oszillator aber trotzdem nicht. Bis zum Ausgabe der ersten Zeichen vergehen gerade ein paar Bit-Zeiten. Da ein Delay vor der ersten Ausgabe die Menge an empfangenen Kauderwelsch anscheinend verringert und danach die Daten korrekt empfangen werden, liegt es nahe, dass der Anlauf des Takts das Problem ist, und nicht eine langsame Drift oder allgemein eine zu große Abweichung des Takts. Ein vernünftiger Empfänger verträgt da einiges an Abweichung bevor nichts mehr ankommt (5% und mehr). Natürlich muss man sich für ernstgemeinte plausible Vorschläge im Forum anmotzen lassen.
Matthias W. schrieb: > es ist ein blaues ProMicro-Board aus China. Ja ... schönes Bild, schöner Link. Scheinbar ist es die Aufgabe eines Thread-Erstellers seine Leser so zu erziehen dass sie sich die notwendigen Informationen gefälligst selbst zusammensuchen.
Jo Mei schrieb: > Es sollte auch für dich nicht schwer sein einen Link zu einem > Board zu posten ruhig Blut ! hier ist ein Link ! https://www.ebay.de/itm/Pro-Micro-Arduino-komp-Board/253565177853 > oder ein Bild an einen Beitrag anzuhängen. Bilder können ggf. viel Ärger machen - siehe Abmahngefahr ! >> Diese Platinen werden doch in riesigen Stückzahlen gemacht? > Soll das ein Argument sein dass die Dinger unter allen Umständen > garantiert funktionieren? das behaupte ich nicht. Das Design scheint jedoch erprobt und die Umgebungsbedingungen nicht grenzwertig. > Wenn du schon an der "Kotzgrenze" bist: schon. dann erkläre bitte in klaren verständlichen Worten wie ich das herausfinden kann/soll.
Wie schauts aus wenn man das Delay am Anfang länger macht, z.b. 1-2ms? Wenn der Empfänger mal falsch "synchronisiert" ist und zwischen den Zeichen keine Pause ist kanns sein, dass er irgendwelche gesendeten Bits als Start-Bit interpretiert. Wenn dann einmal der Wurm drin ist kommt er so einfach nicht mehr herunter.
Wähle mal eine Baudrate, durch die man den Systemtakt glatt teilen kann. Zum Beispiel 250000 baud statt 256000 baud. Oder 1000000 Baud.
Jo Mei schrieb: > dass sie sich die notwendigen Informationen > gefälligst selbst zusammensuchen. Du bekommst doch alles was Du willst. Warum so unhöflich? gehts nicht auch etwas positiver, freundlicher?
Zur Info: Der CH340 Chip unterstützt folgene Baudraten: 50, 75, 100, 110, 134.5, 150, 300, 600, 900, 1200, 1800, 2400, 3600, 4800, 9600, 14400, 19200, 28800, 33600, 38400, 56000, 57600, 76800, 115200, 128000, 153600, 230400, 460800, 921600, 1500000, 2000000. 250000 und 256000 sind leider nicht dabei.
rµ schrieb: > Ja mag sein, instantan mit richtiger Frequenz anlaufen tut der > Oszillator aber trotzdem nicht. Bis zum Ausgabe der ersten Zeichen > vergehen gerade ein paar Bit-Zeiten. ja. Guter Punkt ! Danke ! > Da ein Delay vor der ersten Ausgabe die Menge an empfangenen > Kauderwelsch anscheinend verringert und danach die Daten korrekt > empfangen werden, liegt es nahe, dass der Anlauf des Takts das Problem > ist, guter Hinweis ! > und nicht eine langsame Drift oder allgemein eine zu große > Abweichung des Takts. Ein vernünftiger Empfänger verträgt da einiges an > Abweichung bevor nichts mehr ankommt (5% und mehr). das klingt plausibel. > Natürlich muss man sich für ernstgemeinte plausible Vorschläge im Forum > anmotzen lassen. leider. Warum nur? schlechte Laune hat jeder mal. Die sollte man vor dem Posten abreagieren. Das sollte doch gehen?
rµ schrieb: > Wie schauts aus wenn man das Delay am Anfang länger macht, z.b. 1-2ms? gute Idee. Das kann ich probieren. komisch ist halt daß früher solche Klimmzüge nicht nötig waren. Die Zeit dazwischen war auch nicht viel anders und schon diese beide ersten Zeichen wurden richtig erkannt. Früher verwendete ich aber eine etwas langsamere USART-Ausgabe. im Chip kann man ja auch noch delays für den Quarz beeinflussen - per fuse. Vielleicht ist da etwas ungünstig eingestellt. AVRDUDE zeigt die fuses wohl an. > Wenn der Empfänger mal falsch "synchronisiert" ist und zwischen den > Zeichen keine Pause ist kanns sein, dass er irgendwelche gesendeten Bits > als Start-Bit interpretiert. Wenn dann einmal der Wurm drin ist kommt er > so einfach nicht mehr herunter. ja. Wenn er es mal gepackt hat dann klappt es !
Stefanus F. schrieb: > Zur Info: Der CH340 Chip unterstützt folgene Baudraten: Nachdem die Salamitaktik langsam offenbart um welchen Controller es sich handelt ist anzunehmen dass hier nicht um einen CH340 spekuliert werden braucht.
Jo Mei schrieb: > ist anzunehmen dass hier nicht um einen CH340 spekuliert werden braucht. Zum Verwendeten UART Adapter/Interface zwischen Mikrocontroller und PC hat sich der TO noch gar nicht geäußert.
Matthias W. schrieb: > ja. Wenn er es mal gepackt hat dann klappt es ! Vielleicht ist es auch gar nicht der Oszillator, sondern irgendwas(tm) schluckt das erste Start-Bit, der Empfänger-UART ist dann aus dem Tritt, und kann nicht neu synchronisieren da die Zeichenfolge nie abreisst? 115200bps sind ja über 1300 Takte pro Zeichen für die CPU, d.h. die wartet eigentlich immer auf den UART.
Stefanus F. schrieb: > Zum Verwendeten UART Adapter/Interface zwischen Mikrocontroller und PC > hat sich der TO noch gar nicht geäußert. Richtig. Zu der Salamitaktik gehört dass wir das noch nicht wissen. Es war jedoch vernünftig anzunehmen dass ein Mikrocontroller der ein USB Interface besitzt nicht nochmal extra einen UART Adapter zwischengeschaltet bekommt um seine Daten an ein Terminal zu senden.
Matthias W. schrieb: > am Ende klappt es also, aber am Anfang kommt Unsinn. Normales Verhalten wenn keine Pause zwischen Zeichen gemacht wird. Der Empfänger synct auf irgendein low Bit als Start Bit. Abhilfe: Beim Start ein 0xFF oder ein 0x00 senden. Damit wird der Empfänger synchronisiert. Optional danach ein CRLF für eine neue Zeile im Terminal. Eventuell hat OPs AVR noch einen Bootloader drin, der u.U. eine andere Baudrate fährt oder binäre Daten sendet.
Stefanus F. schrieb: > Wähle mal eine Baudrate, durch die man den Systemtakt glatt teilen kann. > Zum Beispiel 250000 baud statt 256000 baud. Oder 1000000 Baud. Danke für den Hinweis Stefanus ! normalerweise nehme ich gerne hterm her weil das leichter/besser bedienbar ist als die anderen Programme die ich probierte. hterm hat jedoch nur Einstellungen wie 57600, 115200, 128000, 256000. Dazwischen und darüber gibt es nichts. bei teraterm kann ich 250000 einstellen. Leider bringt das keine Besserung.
Jo Mei schrieb: > Nachdem die Salamitaktik langsam offenbart um welchen > Controller es sich handelt oben steht doch klar daß es ein 32u4 ist. Der AVR mit USB halt. Und davon nutze ich den USART. Salami ist da gar keine !
Jim M. schrieb: > Abhilfe: Beim Start ein 0xFF oder ein 0x00 senden. Damit wird der > Empfänger synchronisiert. Optional danach ein CRLF für eine neue Zeile > im Terminal. Danke Jim. Das ist die Lösung ! ein einziges 0xff und danach ein \n reicht. > Eventuell hat OPs AVR noch einen Bootloader drin, der u.U. eine andere > Baudrate fährt oder binäre Daten sendet. ja. Ein ARDUINO LEONARDO Bootloader ist drin. Der nutzt den USB-Port (bei mir COM4) mit 57600 Baud.
Stefanus F. schrieb: > 250000 und 256000 sind leider nicht dabei. Danke für den Hinweis Stefanus. Ich habe einen FTDI232TTL mit Kabelschwanz angesteckt.
Jo Mei schrieb: > ist anzunehmen dass hier nicht > um einen CH340 spekuliert werden braucht. ja. Denn wenn der CH340 diese Baudrate nicht hat kann er es nicht sein.
ich bedanke mich herzlich für die wertvollen Beiträge und die einfache Lösung des unangenehmen Problems. Vielleicht braucht das ja mal ein Anderer.
Jo Mei schrieb: > Es war jedoch vernünftig anzunehmen dass ein Mikrocontroller > der ein USB Interface besitzt nicht nochmal extra einen > UART Adapter zwischengeschaltet bekommt um seine Daten an > ein Terminal zu senden. Wenn er die USB Schnittstelle verwendet hätte, dann hätte er mit Sicherheit nicht das beschriebene Problem gehabt. > In einer Schleife werden 2 Meldungen über USART ausgegeben. > es kommen Ausgaben in der Art: ‚)R"•ÍÑ•2I5ÿ…
Matthias W. schrieb: > ich bedanke mich herzlich für die wertvollen Beiträge und > die einfache Lösung des unangenehmen Problems. Was war denn jetzt die Lösung? Auf eine (für den AVR) glatte Baudrate zu wechseln und außerdem auf einen dazu passenden USB-UART Adapter (FTDI) zu wechseln?
Angehängte Dateien:
-
Versatz_01.jpg
110 KB
Hi, hier noch ein paar Bildchen. Kommt also darauf an, ob es "systematische" Fehler sind, keine total zufälligen. Teraterm hat noch eine bessere Abtastung, es wird nicht direkt auf der Flanke, sondern etwas danach übernommen. Das war bei mir damals die Lösung. Und der durch Jitter produzierte Versatz verschwand. Und das schon bei 8N1 9k6. Wie stark muss das erst bei höherer Baudrate sein. Schaut doch erst einmal, bis zu welcher Baudrate die Anwendung garantiert ist. ciao gustav
:
Bearbeitet durch User
Karl B. schrieb: > Teraterm hat noch eine bessere Abtastung, es wird nicht direkt > auf der Flanke, sondern etwas danach übernommen. Karl, ich kann Dir nicht folgen. Nach meinem Kenntnisstand geht es hier um eine serielle UART Übertragung, die der PC mit Hilfe eines UART Adapters empfängt. Es scheint, dass der TO mindestens zwei unterschiedliche versucht hat. Inwiefern hat die PC Software Einfluss auf die "Abtastung"?
Hi, einmal die µC-Seite beleuchten: http://ww1.microchip.com/downloads/en/devicedoc/atmel-7766-8-bit-avr-atmega16u4-32u4_datasheet.pdf 18.7.1 Asynchronous Clock Recovery und folgende Seiten zeigen, wie die "Verarbeitung" (oder "Abtastung") erfolgt. Und die Toleranzen der Baudraten, was noch geht, was vielleicht noch geht, was nicht mehr geht ohne Fehler. Und das Terminalprogramm im PC hat auch "Recovery-Möglichkeiten" eines nicht ganz seiner intern erzeugten Baudrate übereinstimmenden seriellen Eingangssignals. Mir kommt ein anderer Gedanke: Wie wird gesendet/empfangen UART mit Interrupt oder nur Polling. Vielleicht knallt ein Interrupt mit höherer Prio mitten in die serielle Übertragung rein. ciao gustav
Karl B. schrieb: > Und das Terminalprogramm im PC hat auch "Recovery-Möglichkeiten" eines > nicht ganz seiner intern erzeugten Baudrate übereinstimmenden seriellen > Eingangssignals. Das bezweifle ich. Wenn schon, dann müsste das der USB-UART Adapter tun. > Vielleicht knallt ein Interrupt mit höherer Prio mitten in > die serielle Übertragung rein. Das spielt keine Rolle, da die Übertragung der einzelnen Zeichen davon unberührt bleibt. Das Herausschieben der Bits erledigt die UART ganz alleine.
Stefanus F. schrieb: > Wenn er die USB Schnittstelle verwendet hätte, dann hätte er mit > Sicherheit nicht das beschriebene Problem gehabt. auch die habe ich verwendet. Es dauerte lange bis ich brauchbare Ausgaben damit erreichte. Die serielle Schnittstelle verwende ich zusätzlich.
Stefanus F. schrieb: > Was war denn jetzt die Lösung? die Ausgabe eines einzigen Bytes mit 0xff und danach \n löst das Problem. > Auf eine (für den AVR) glatte Baudrate zu > wechseln und außerdem auf einen dazu passenden USB-UART Adapter (FTDI) > zu wechseln? nein. Den FTDI hatte ich ja schon. Das war nicht die Lösung.
Karl B. schrieb: > hier noch ein paar Bildchen. Danke Gustav. > Teraterm hat noch eine bessere Abtastung, es wird nicht direkt > auf der Flanke, sondern etwas danach übernommen. > Das war bei mir damals die Lösung. ok. > Schaut doch erst einmal, bis zu welcher Baudrate die Anwendung > garantiert ist. momentan geht es mit 256kbd. Mehr kann ich bei hterm scheinbar nicht einstellen.
Ok, dann sieht es doch sehr danach aus, dass dein Oszillator mehr Zeit zum Einschwingen braucht.
Karl B. schrieb: > Und die Toleranzen der Baudraten, was noch geht, was vielleicht noch > geht, in meinem Fall ist die Abweichung 2.4%. Es gibt auch Beispiele wo 7% oder mehr angegeben wurden.
Stefanus F. schrieb: > Ok, dann sieht es doch sehr danach aus, dass dein Oszillator mehr Zeit > zum Einschwingen braucht. das ist die Frage, denn er hat nun ja schon mit dem ersten Zeichen kein Problem mehr. Ein Einschwingen kann ich da nicht sehen. man könnte die fuses für das Einschwingen noch ansehen.
Matthias W. schrieb: > momentan geht es mit 256kbd. Mehr kann ich bei hterm scheinbar nicht > einstellen. das heißt nicht daß nicht auch höhere Geschwindigkeiten noch gingen. Nur bei hterm endet der Einstellbereich eben. Andere Programme schaffen ggf. mehr.
Angehängte Dateien:
Stefanus F. schrieb: > Das bezweifle ich. Wenn schon, dann müsste das der USB-UART Adapter tun. Hi, also, Teraterm ist bestimmt besser als das Terminalprogramm von "Basic" 100 "Open com 1 for output A$1 /D /S" also, das produzierte I/O-Error en mass. Bin der Meinung, dass auch das Terminalprogramm was damit zu tun hat. OK. Bei Transmit kann man noch Delay einstellen, bei Receive entgegen irriger Annahme von mir leider nicht. Also ist das schon mal keine Lösung hier. Wo kann man jetzt suchen, nachdem diese Möglichkeit ausgeschlossen werden kann? ciao gustav
Karl B. schrieb: > Wie wird gesendet/empfangen UART mit Interrupt oder nur Polling. in diesem Beispiel wird das USART-Senderegister beschrieben und dann abgeschickt. Wenn leer kann das nächste Byte kommen. Das geht so schnell es eben geht per Software. > Vielleicht knallt ein Interrupt mit höherer Prio mitten in die serielle > Übertragung rein. beim Empfang von Zeichen über USART kann ein Interrupt eine Rolle spielen. Solange ich jedoch nur Zeichen per USART ausgeben lasse und keine per Terminal zum USART sende sollte das keine Rolle spielen.
Angehängte Dateien:
Stefanus F. schrieb: > Zur Info: Der CH340 Chip unterstützt folgene Baudraten: > 50, 75, 100, 110, 134.5, 150, 300, 600, 900, 1200, 1800, 2400, 3600, > 4800, 9600, 14400, 19200, 28800, 33600, 38400, 56000, 57600, 76800, > 115200, 128000, 153600, 230400, 460800, 921600, 1500000, 2000000. > > 250000 und 256000 sind leider nicht dabei. Der CH340 Chip selbst unterstützt sehr viel mehr als die aufgelisteten Baudraten. Der Treiber unterstützt ggf. nicht alle Baudraten oder unter Umständen mit einer großen Abweichung, da die verwendete Formel unpräzise ist. Natürlich muss auch die Applikation die Baudrate unterstützen. Um herauszufinden welche Baudrate der Treiber tatsächlich verwendet kann man mit aktuellen Wireshark Versionen den USB Verkehr mitschneiden und nachrechnen, siehe ScreenShot. Das Libreoffice Spreadsheet zum Berechnen der tatsächlichen Baudrate aus dem Wert von "wIndex" bei den Requests mit "wValue=0x1312" (siehe Filterzeile in Wireshark) findet ihr hier auf Seite "Register to baud": https://github.com/nospam2000/ch341-baudrate-calculation/blob/master/docs/ch341_baudrate_error_calculation.ods?raw=true In Spalte "16-Bit Hex value" gibt man den Wert ein (hier: "f983") und kann in Spalte "Real Baud rate" die tatsächliche Baudrate ablesen. Wenn man in Spalte "Target Baud rate" die eigentlich gewünschte Baudrate einträgt kann in Spalte "error" noch ablesen wie groß der relative Fehler ist. In manchen Fällen kann es helfen, wenn man eine etwas niedrigere oder höhere Baudrate im Terminalprogramm einstellt, als man eigentlich benötigt. Bei Mac OSX geht dies leider nicht, dort wird dann der Ersatzwert 9600 Baud verwendet. Zum Thema Baudratenberechnung des CH340/CH341 habe ich hier mal Informationen zusammengetragen: https://github.com/nospam2000/ch341-baudrate-calculation Michael
:
Bearbeitet durch User
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.