Hallo, habe ein Problem mit Arduino Mega2560 und einem USB-seriell-Wandler mit dem FTDI-Chip. Nachdem ich die Verbindung eines ESP8266 mit dem PC über die Wandler-Schnittstelle partout nicht hinbekommen habe, wollte ich den Wandler testen. Dafür habe ich den 2560 genommen. Es gibt unter den Beispielen ein Sketch 'Serialpassthrough', das eigentlich für einen eher speziellen Zweck gedacht ist. Auf dem 2560 aber bewirkt es genau das Gewünschte: Alle Daten, die auf dem einen Anschluss reinkommen, gehen hinten wieder raus, und umgekehrt. Das Ganze funktioniert auch ... im Prinzip. Wenn man zwei HTerm aufmacht, Eines auf dem 2560, das Andere auf dem FTDI, tauschen die Beiden sich aus. Problem: Die Datenm stimmen nicht überein. Sende ich lauter 'j' (als Beispiel), kommen 'L' raus usw. Der Fehler ist reproduzierbar, es kommt immer das Gleiche heraus bei bestimmten Eingaben. Aber eben Falsches. Die Rate stimmt, um das Ganze mittels LED verfolgen zu können, ist sie nur 300bit/s. 8n1 stimmt ebenso. Auch auf dem 2560 ist natürlich eine Rate von 300 eingestellt. Hat jemand eine Idee, wo ich noch nach dem Fehler suchen könnte? Tschüß und Danke Manni
Zuerst würde ich den FTDI allein testen. Dazu einfach RX mit TX verbinden.
pegel schrieb: > Zuerst würde ich den FTDI allein testen. > Dazu einfach RX mit TX verbinden. Schon mal gemacht. Dann sind alle Zeichen richtig. Jörg E. schrieb: > Pegel invertieren? Wäre eine Möglichkeit. Leider klappt es so aber nicht. Ich habe in HTerm den Hex-Modus aktiviert. Da war dann zu sehen, dass nur einzelne Bits gekippt waren, nicht alle. Ulkigerweise weder ein Versatz (etwa 01110011 00110001 10000011 wird zu 11001100 11000110 000011...) oder bestimmte Bits (zum Beispiel Nummer 4) in allen Zeichen, sondern ohne jede Regel. Hätte ich erwähnen sollen, tschuldigung. Umso überraschender, dass bei mehreren Versuchen iimmer wieder das Gleiche herauskam. Tschüß Manni
Taktquelle für den 2560?
Manfred P. schrieb: > RX mit TX verbinden. > > Schon mal gemacht. Dann sind alle Zeichen richtig. Dann fallen mir 3 Möglichkeiten ein. 1. Handshake XON/XOFF 2. Baudrate wirklich identisch? 3. Unicode Zeichen
normal: mit Start/Stop
j = 6a = 01101010 0011010101
L = 4c = 01001100 0010011001
01110011 00110001 10000011 wird zu
11001100 11000110 000011
gesendet schaut es ja so aus:
s76543210os76543210os76543210o s=start o=stop
001110011100011000110100000111 wird zu
11001100101100011010000011
x x
Ich tippe auf falsche Baudrate oder Invertierung, evtl. läuft der
interne RC-Oszillator und der Calibration-Wert stimmt nicht.
Sende mal ein paar 100 Buchstaben und stoppe die Zeit, wie lange das
dauert.
Ein Soundkarten-Oszilloskop oder billigst-LA kann das Problem leicht
lösen.
Oder wenn Du einen Frequenzmesser (evtl. im Multimeter oder im
Universal-Bauteiletester) hast, gib mal ununterbrochen 0xaa aus und
messe die Frequenz am TxD, das sollte 0101010101 ergeben mit f=halbe
Baudrate.
Angehängte Dateien:
-
Bild1_serielltest.jpg
4,3 KB
Hallo, Unicode? Wohl eher nicht, dann wären die Hex-Zahlen nicht verschieden. Beide HTerm verwenden ASCII. ein Testprotiokoll: Ich habe eine Textdatei mit dem Editor angelegt. Sie ist 200002 Bytes groß und besteht aus den Zeilen ABCDEFGHIJKLMNOPQRSTUVWXYZ und abcdefghijklmnopqrstuvwxyz im Wechsel. Damit will ich herausfinden, was sich in was verwandelt. Hinter jeder Zeile stehen natürlich noch 0x0D 0x0A für das Zeilenende Eingestellt sind (laut Einstellfeld im HTerm) 300 Baud, der Mega ist auf 300 Baud programmiert. Zwei LED sind parallel angeschlossen und zeigen die Übertragung an. Erster Versuch: Arduino (COM6:) auf den FTDI (COM4:): Zeichen falsch. Gesendete Zeichenzahl und empfangene Zeichenzahl des anderen HTerm differieren schon zu Beginn der Aktion: 18000 zu ~17650 Da scheint also einiges zu fehlen. Dauert allerdings länger als erwartet ... man sollte sowas vorher mal nachrechnen. Allerdings liefert diese lange Zeit natürlich auch sehr gute Werte. So, fertig. 200002 Bytes in 101 min. ergeben 330 Baud bei 10 Bit pro Byte. Rx auf COM4 198388 Bytes, es fehlt also was. Gesendet wurden 200002 Bytes. Die Datei selbst ist zu lang. Doch dies ist das Ende: 37 35 33 31 2F 2D 2B 29 27 25 23 21 1F 1D 1B 19 17 15 13 11 0F 0D E5 EB 7D 7B 79 77 75 73 71 6F 6D 6B 69 67 65 63 61 5F 5D 5B 59 57 55 53 51 4F 4D 4B E5 EB 3D 3B 39 37 35 33 31 2F 2D 2B 29 27 25 23 21 1F 1D 1B 19 17 15 13 11 0F 0D 0B E5 EB 7D 7B 79 77 75 73 71 6F 6D 6B 69 67 65 63 61 5F 5D 5B 59 57 55 53 51 4F 4D 4B E5 EB 3D 3B 39 37 35 33 31 2F 2D 2B 29 27 25 23 21 1F 1D 1B 19 17 15 13 11 0F 0D 0B E5 EB 7B 79 77 75 73 71 6F 6D 6B 69 67 65 63 61 5F 5D 5B 59 57 55 53 51 4F 4D 4B 00 Ein Muster oder so kann ich aber nicht erkennen. Morgen erst mal die Kurvenform kontrollieren. Tschüß erstmal Manni
Gab es da nicht mal was das die langsamen Baudraten nicht korrekt funktionieren? Probier das doch mal mit 38400. Geht auch schneller.
Jetzt lass den COM4 senden (deutlich geringere Anzahl reicht) und messe, wie lange er braucht. Dann weißt Du, welche Baudrate er zum Empfang erwartet. Achte darauf, dass bei Soft-Serial keine anderen IRQs oder IRQ-Sperren erlaubt sind (je nach Implementation). 0D E5 EB 7D 7B 79 0D 0B E5 EB 7D 7B 79 0D 0B E5 EB 7B 79 Das gepostete Muster wiederholt sich alle 55 bzw. 56 Bytes. Beim ersten Mal fehlt ein 0B, beim dritten Mal das 7D drei Stellen weiter hinten. 2* (26+2)=56 Was hat die oben vorgeschlagene Frequenzmessung ergeben?
pegel schrieb: > Gab es da nicht mal was das die langsamen Baudraten nicht korrekt > funktionieren? Das hängt natürlich vom Takt ab. Fakt ist, dass das Teilerregister BRR nur 12 Bit hat, also maximal durch 4096 teilen kann. Die UART-Statemachine teilt ihren Eingangstakt dann effektiv noch einmal, und zwar entweder durch 8 oder durch 16, je nach Einstellung des U2X-Bits. Der maximal mögliche Teilerfaktor ist also 4096*16 = 65536. D.h.: 300 Baud sind nur dann möglich, wenn der Systemtakt <= 300*65536 = 19660800Hz ist. Probleme sind also allenfalls für 20MHz Systemtakt zu erwarten. Da kann man dann nur den maximalen Faktor einstellen und muß mit dem sich ergebenden Bitratenfehler von ca. +1,7% leben. Das ist allerdings wirklich an der Schmerzgrenze und wird in der Praxis oft zu Problemen führen. Da der Mega2560, um den es hier geht, aber eh' nur bis 16MHz läuft, kann dieses Problem hier nicht zuschlagen.
c-hater schrieb: > mit dem sich ergebenden Bitratenfehler von ca. +1,7% leben. Das ist > allerdings wirklich an der Schmerzgrenze und wird in der Praxis oft zu > Problemen führen. Ergänzung: Viele davon lassen sich beheben, indem man die UART für zwei Stopbits konfiguriert. Das läßt dem Empfänger dann die Zeit, um sich korrekt auf den nächsten Wortanfang synchronisieren zu können.
Manfred P. schrieb: > Hallo, > habe ein Problem mit Arduino Mega2560 und einem USB-seriell-Wandler mit > dem FTDI-Chip. Nachdem ich die Verbindung eines ESP8266 mit dem PC über > die Wandler-Schnittstelle partout nicht hinbekommen habe, wollte ich den > Wandler testen. Dafür habe ich den 2560 genommen. Es gibt unter den um noch mal auf dein eigentliches Anliegen zurückzukommen - was für einen FTDI-Wandler hast du da? Mit einem FTDI-USB-Kabel auf 3.3V TTL bekomme ich auch keine ordentliche Verbindung zu einem ESP. Das Problem ist das der FTDI dort ohne eigenen Quarz läuft und seinen Takt deshalb auf den USB-Anschluss syncronisiert. Ich hab dann mal gemessen - das führt am FTDI zu einer etwas höheren Baudrate, während der ESP mit seiner etwas darunter liegt. Für Debugausgaben geht das aber ein Programmupload war nicht zuverlässig möglich. Mit einem FTDI an dem ein Quarz angeschlossen ist klappt es problemlos. Sascha
Sascha W. schrieb: > Manfred P. schrieb: >> Hallo, >> habe ein Problem mit Arduino Mega2560 und einem USB-seriell-Wandler mit >> dem FTDI-Chip. Nachdem ich die Verbindung eines ESP8266 mit dem PC über >> die Wandler-Schnittstelle partout nicht hinbekommen habe, wollte ich den >> Wandler testen. Dafür habe ich den 2560 genommen. Es gibt unter den > um noch mal auf dein eigentliches Anliegen zurückzukommen - was für > einen FTDI-Wandler hast du da? Mit einem FTDI-USB-Kabel auf 3.3V TTL > bekomme ich auch keine ordentliche Verbindung zu einem ESP. Das Problem Was für einen ESP meinst Du denn? Ich meine den ESP8266 (habe das oben auch einmal erklärt, nur eben nicht immer ausgeschrieben). Der läuft mit 3.3V und verträgt 5V gar nicht erst (soll angeblich dann sogar kaputt gehen). Das nur dazu. > ist das der FTDI dort ohne eigenen Quarz läuft und seinen Takt deshalb Das allerdings könnte hier sein (ist so'n 'no-name') denn ein Quartz ist da nirgendwo zu erkennen. > auf den USB-Anschluss syncronisiert. Ich hab dann mal gemessen - das > führt am FTDI zu einer etwas höheren Baudrate, während der ESP mit > seiner etwas darunter liegt. Für Debugausgaben geht das aber ein > Programmupload war nicht zuverlässig möglich. Mit einem FTDI an dem ein > Quarz angeschlossen ist klappt es problemlos. > > Sascha c-hater schrieb: > c-hater schrieb: > >> mit dem sich ergebenden Bitratenfehler von ca. +1,7% leben. Das ist >> allerdings wirklich an der Schmerzgrenze und wird in der Praxis oft zu >> Problemen führen. > > Ergänzung: Viele davon lassen sich beheben, indem man die UART für zwei > Stopbits konfiguriert. Das läßt dem Empfänger dann die Zeit, um sich > korrekt auf den nächsten Wortanfang synchronisieren zu können. Das probier ich mal aus. Wie bekommt man den Arduino auf 2 Stoppbits (bin noch nicht so ganz firm mit den Kommandos)? Läuft über einen Konfigurationsbefehl an serial, nur welchen? eProfi schrieb: > Jetzt lass den COM4 senden (deutlich geringere Anzahl reicht) und > messe, > wie lange er braucht. > Dann weißt Du, welche Baudrate er zum Empfang erwartet. > > Achte darauf, dass bei Soft-Serial keine anderen IRQs oder IRQ-Sperren > erlaubt sind (je nach Implementation). > > 0D E5 EB 7D 7B 79 > 0D 0B E5 EB 7D 7B 79 > 0D 0B E5 EB 7B 79 > > Das gepostete Muster wiederholt sich alle 55 bzw. 56 Bytes. Beim ersten > Mal fehlt ein 0B, beim dritten Mal das 7D drei Stellen weiter hinten. > 2* (26+2)=56 > Was hat die oben vorgeschlagene Frequenzmessung ergeben? Noch nichts. Bin ja auch nicht immer da dran (habe auch noch andere Dinge am Hals). Kommt jetzt.
Hallo, Nachtrag: Habe das Ganze an ein Oszilloskop angeschlossen. Dann habe ich eine Datei mit 5000 mal 0xAA erzeugt. Die sende ich jetzt hin und her. Zunächst: Bei 8n1 wird 0x95 daraus, bei 8n2 auf einmal 0x15. ERs liegt also sicher an der Synchronisation. Nicht verstanden habe ich das Bild auf dem Oszi: Gu7t getriggert sieht es si aus. HLHLHLHHHLLHLHL... Dabei steht mehrmals H für eine entsprechend lange Zeitphase mit diesem Pegel. Ich bekomme abe rdas irgendwie nicht zusammen: Das Startbit ist Low, die Stoppbits sind High, also sollte das so aussehen (0xAA): LHLHLHLHLHH (bei 8n2). Da finde ich keine drei High-Pegel hintereinander. Werden die Daten (und nur die) invertiert, kommt LLHLHLHLHHH heraus, was dann hinhaut (ich schreibe beim Nachdenken; kam mir also gerade). Habe daraufhin im Arduino-Sketch beide Datenströme biutweise invertiert. Das hilft allerdings auch nichts. Aus 0xAA immer Dauerbetrieb wird sowas wie: (alles Hex, dann kann ich dieses 0x immer weglassen) AA A9 A9 A5 A5 95 95 55 55 55 und von Vorne (das sind übrigends 10 Bytes; ob das was heist? ). Das ist jetzt allerdings nur Arduino zum FTDI. Umgekehrt sieht es so aus: EA EA ..... kontinuierlich. Ach ja, der Arduino wurde an seiner serial1-Schnittstelle auf 8n2 eingestellt. serial arbeitet weiter hin 8n1, ebenso der CH340G auf dem Arduino-Board. Auf dem Oszi sind übrigends die Bilder auch nicht identisch. Jetzt erst mal eine Kaffepause. Später mehr. Tschüß Manni
also die Schnittstelle musst du dann auf beiden Seiten auf 8n2 einstellen, sonst geht die Übertragung in die eine Richtung je nach Zeichenzwischenabstand überhaupt nicht. Gib doch mal ein Zeichen 0x00 oder 0xff auf und miß dann am Oszi die Bitbreite aus, dann kannst du die Baudrate ausrechnen. (und ja ich sprach auch von einem ESP8266) Sascha
> also die Schnittstelle musst du dann auf beiden Seiten auf 8n2
Interessanterweise ist fast allen Empfängern die Anzahl der Stop-Bits
egal.
Auch wenn 2 Stopbits eingestellt sind, kann er mit 1 Stopbit empfangen
und umgekehrt. Nur sehr wenige bringen dann einen Framing-Error.
Ich behaupte immer noch, es liegt an einem Interrupt.
Wir brauchen die komplette Software. Was läuft im Hintergrund?
Der atMega2560 hat doch 4 Hardware-Uarts.
eProfi schrieb: > Ich behaupte immer noch, es liegt an einem Interrupt. Kein Schwein wagt es auch nur ansatzweise daran zu denken was schon (scheinbar nicht detlich genug) vorgeschlagen wurde: Rufus Τ. F. schrieb: > Taktquelle für den 2560? Der Arduino Mega2560 hat einen keramischen Resonator drauf anstatt etwas "Gescheitem", einen Quarz. Da kann der Takt schon mal ein wenig mehr daneben liegen. In Summe mit dem FTDI-Umsetzer der ohne eigenen Quarz läuft kann da immer mehr passieren.
Sascha W. schrieb: > also die Schnittstelle musst du dann auf beiden Seiten auf 8n2 > einstellen, sonst geht die Übertragung in die eine Richtung je nach > Zeichenzwischenabstand überhaupt nicht. > > Gib doch mal ein Zeichen 0x00 oder 0xff auf und miß dann am Oszi die > Bitbreite aus, dann kannst du die Baudrate ausrechnen. > > (und ja ich sprach auch von einem ESP8266) > > Sascha Habe ich getan. 10 Bits dauerten genau (soweit das Oszilloskop das hergibt. Das ist noch analog mit Röhre und RC-Glied für die X-Rampe) 33ms, was genau 300Bit/s entspricht. Das verwundert mich, weil Du so speziell die Spannung erwähnst. Mitlesa schrieb: > eProfi schrieb: >> Ich behaupte immer noch, es liegt an einem Interrupt. Wo? Der Arduino hat nur diesen kleinen Sketch, sonst nichts. Auf dem PC läuft natürlich so Einiges, doch das ist kaum zu vermeiden. Ob das hier allerdings Wirkung hat, weis ich nicht. Zudem: Sowas Zufälliges und Externes wie ein Interrupt soll ein regelmäßiges Abweichungsmuster liefern? Erscheint mir unwahrscheinlich. > > Kein Schwein wagt es auch nur ansatzweise daran zu denken was > schon (scheinbar nicht detlich genug) vorgeschlagen wurde: > > Rufus Τ. F. schrieb: >> Taktquelle für den 2560? > > Der Arduino Mega2560 hat einen keramischen Resonator drauf > anstatt etwas "Gescheitem", einen Quarz. Da kann der Takt > schon mal ein wenig mehr daneben liegen. In Summe mit dem > FTDI-Umsetzer der ohne eigenen Quarz läuft kann da immer > mehr passieren. Nach meinem Eindruck hat der Arduino einen Quartz-Generator mit 12 MHz drauf, wie gut der allerdings ist, weis auch niemand. Auf dem Arduino läuft ein Sketch, der alle Daten von serial (USB-UART) auf serial1 (die Pins 18 & 19; TxD1 und RxD1) kopiert ... und umgekehrt. Jeder Durchlauf der Loop fragt die beiden Schnittstellen (getrennt) nach verfügbaren Zeichen ab und schickt sie dann an die andere Schnittstelle. Deshalb darf der COM6 auch nicht auf 8n2 stehen, denn das ist serial (also USB), der FTDI ist aber mit serial1 verbunden, hier muss also im Sketch auf 8n2 gestellt werden (was ich tue). Ich kann mich auf den Kopf stellen und mit den Beinen Hurra schreien ... ich finde den Fehler nicht. Tschüß Manni
Du sollst nicht schwafeln, sondern den kompletten Sourcecode gezippt als Anhang schicken. Und meine Fragen beantworten: warum schreibst du oben von 330 baud? > So, fertig. 200002 Bytes in 101 min. ergeben 330 Baud bei 10 Bit > pro Byte.
Manfred P. schrieb: > Nach meinem Eindruck hat der Arduino einen Quartz-Generator mit 12 MHz > drauf, wie gut der allerdings ist, weis auch niemand. Sorry aber das klingt schon fast nach Starrsinn. Dein Eindruck täuscht. Wissen ist besser als glauben. Nein, das ist kein "Quartz-Generator mit 12 MHz" sondern einfach ein Quarz. Und nein, das ist der Quarz für den USB (Mega16U2). Das kleine winzige Etwas an einer Ecke des 2560 ist der keramische Resonator.
Manfred P. schrieb: > Habe ich getan. 10 Bits dauerten genau (soweit das Oszilloskop das > hergibt. Das ist noch analog mit Röhre und RC-Glied für die X-Rampe) > 33ms, was genau 300Bit/s entspricht. ist das jetzt der UART des Arduino oder der Ausgang des FTDI? Sascha
Mitlesa schrieb: > Und nein, das ist der Quarz für den USB (Mega16U2). Wenn es ein 12 Mhz Quarz ist, dann natürlich für einen CH340 (USB-Serial Converter).
eProfi schrieb: > Du sollst nicht schwafeln, sondern den kompletten Sourcecode > gezippt als > Anhang schicken. > > Und meine Fragen beantworten: warum schreibst du oben von 330 baud? >> So, fertig. 200002 Bytes in 101 min. ergeben 330 Baud bei 10 Bit >> pro Byte. Weil mein Taschenrechner das herausbekommt. 200002 Bytes x 10Bits/Byte /(101 min. x 60 sec./min.) = 330,036 Bit/s ich weis, entspricht nicht den anderen Ergebnissen, aber ich kann's ja nun auch nicht ändern. Irgendwas hat mir hier ungenaue Zahlen geliefert, wie es scheint. Mitlesa schrieb: > Manfred P. schrieb: >> Nach meinem Eindruck hat der Arduino einen Quartz-Generator mit 12 MHz >> drauf, wie gut der allerdings ist, weis auch niemand. > > Sorry aber das klingt schon fast nach Starrsinn. Wieso? Ich hab' den einfach nicht gefunden. Immer noch nicht, übrigends. Wie ist denn sowas üblicherweise bezeichnet (ich meine den Buchstaben: Widerstände haben R, Kondensatoren C und ein ker. Resonator?)? Allerdings: So wichtig ist das nun auch wieder nicht. Funktioniert das Ding eigentlich auch mit einem einfachen RC-Glied oder sowas? Denn davon sind eine Menge auf der Platine. > > Dein Eindruck täuscht. Wissen ist besser als glauben. > Nein, das ist kein "Quartz-Generator mit 12 MHz" sondern > einfach ein Quarz. > Und nein, das ist der Quarz für den USB (Mega16U2). Der Quartz (in einem länglichen Metallgehäuse; ich hab's für einen kompletten Generator gehalten. Da habe ich mich also ebenfalls vertan)) sitzt tatsächlich neben dem CH340G, ist also für den. > > Das kleine winzige Etwas an einer Ecke des 2560 ist > der keramische Resonator. Sascha W. schrieb: > Manfred P. schrieb: >> Habe ich getan. 10 Bits dauerten genau (soweit das Oszilloskop das >> hergibt. Das ist noch analog mit Röhre und RC-Glied für die X-Rampe) >> 33ms, was genau 300Bit/s entspricht. > ist das jetzt der UART des Arduino oder der Ausgang des FTDI? Beide, da bei beiden Ausgängen fast identische Kurven (Amplitude war ein bisschen anders) herauskamen. > > Sascha Das hatte ich glatt vergessen. Hier der Code für den Arduino:
1 | /*
|
2 | Created 23 May 2016
|
3 | by Erik Nyquist
|
4 | */
|
5 | |
6 | void setup() { |
7 | Serial.begin(300); |
8 | Serial1.begin(300, SERIAL_8N2); |
9 | }
|
10 | |
11 | void loop() { |
12 | if (Serial.available()) { // If anything comes in Serial (USB), |
13 | Serial1.write(~Serial.read()); // read it and send it out Serial1 (pins 18 & 19) |
14 | }
|
15 | |
16 | if (Serial1.available()) { // If anything comes in Serial1 (pins 18 & 19) |
17 | Serial.write(~Serial1.read()); // read it and send it out Serial (USB) |
18 | }
|
19 | }
|
Basiert fast komplett auf dem serialpassthrough-Beispiel aus dem Arduino-IDE-Paket. Serial1 ist bei den eigentlich von dem Sketch adressierten Bausteinen mit den Anschlüssen 0&1 verbunden (was sich im Kommentar niederschlägt), entspricht beim etwas besser ausgestatteten Mega2560 aber den Anschlüssen 18 & 19. Eigentlich habe ich nur das geändert. Und dann natürlich die Negierung der Daten. Was allerdings die Bibliothek-Funktionen im Einzelnen tun, weis ich leider nicht. Tschuldigt die Fehler, ich weis leider im Moment weder, was da los ist, noch wo ich suchen soll. Dadurch wohl habe ich anscheinend nicht so recht mitgekriegt, wonach gefragt wird. Tschüß Manni
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.