ich bin neu hier und habe zu dem Thema bisher nicht wirklich was finden können oder eine Erklärung gesehen (vielleicht liegt es auch an meiner Suche aber auch die KI konnte mir keine vernünftige Lösung bieten).
Ich habe einen Arduino Nano Every mit einem DS18B20 Temp-Sensor verbunden und mir die Temperatur im seriellen Monitor mit einem einfachen Standard-Beispiel ausgeben lassen. Ich habe dann nach einiger Zeit festgestellt, dass ab und zu Zeichenfehler aufgetreten sind. Um den Sensor und alle andere Schaltungsteile als Fehlerquelle zu eliminieren habe ich einen ganz neuen Arduino Nano Every aus der Packung genommen und nur diesen via USB an den PC angeschlossen. Hier lasse ich mit einem simplen Beispiel Zeichen an den PC senden:
Wenn ich nun diesen Code ein paar Minuten laufen lasse, dann kommen immer mal wieder sporadische Zeichenfehler.
Ich habe es auch an einem anderen PC probiert, das Kabel getauscht, andere Zeichen gesendet, mittlerweile 3 Arduinos getestet (alle neue Nano Every) und auch die Zeichen mit Putty, HTERM und dem seriellen Monitor ausgelesen. In HTERM konnte ich dann sehen, dass die fehlerhaften Zeichen immer 0x80 sind. Das kommt bei ca. 1.000.000 gesendten Zeichen vielleicht 10x vor aber trotzdem finde ich das unschön und sollte so nicht sein. Das ist mir zuvor bei anderen Programmen und Boards auch noch nicht aufgefallen beim Arduino Uno oder normalem Arduino Nano.
Die KI hat was ausgespuckt bezüglich Timing-Problemen vom internen Oszillator und man könne das mit einem anderen Modus umgehen allerdings hat das das Problem gefühlt nur verstärkt (Double-Speed-Modus (CLK2X)). Die Alternative wäre noch ein Umstieg auf den so genannten "MegaCoreX" aber davon habe ich keine Ahnung und weiß nicht genau, was damit gemint ist und ob das funktioiert. Daher meine Frage hier in die Runde ob das was bekanntes ist mit dem Problem mit der seriellen Kommunikation und dem Nano Every oder ob das nur bei mir der Fall ist.
Ich habe jetzt noch einen Arduino Nano Clon (kein Every) gefunden und den gleichen Code mit diesem Board über mehr als 60 Minuten getestet, da konnte ich keinen Fehler feststellen. In dieser Zeitspanne hätte ich mit dem Every schon mehrfache Fehler gehabt.
Kann das jemand bestätigen oder kennt jemand die Ursache?
Ich habe auch den MegaCoreX zwischenzeitlich getestet. Dort tritt es auch auf.
0x80 hat nun wenig Ähnlichkeit mit 'A' bzw. 0x41.
Da ist es auch möglich, dass die TX-Leitung während einer Pause im delay(100) nicht komplett HIGH = Stopbit / IDLE ist, sondern --bei 115200-- für ca 70 µs (Start+7 Datenbit) LOW.
Das würdest du übrigens auch sehen, wenn du gar kein Serial.write() machen würdest.
Zeigt dein HTERM bei 57600 dann ein 0xF0 oder 0xF8 - Zeichen ?
Und was sieht HTERM, wenn es auf 9600 steht?
Außerdem ist erstmal zu klären, ob das Problem auf der USB-Seite oder auf dem atmega 4809 und vor dem samd11 USB-Controller sitzt. Ich nehme mal an, dass die Tatsache, dass du es (auch) per USB siehst, liegt an den einfachen Testmöglichkeiten, das Problem ist aber schon auf der Seriellen Tx-Leitung.
Im "echten Leben" ist die Frage, wie eine Übertragungsstörung zu erkennen ist (Parity, CRC-Bytes, ...), und was dann zu tun bleibt. Komplett fehlerfreie Serielle Übertragung kriegst du nicht garantiert.
Nein, der beobachtete Zeichenfehler drückt sich immer in 0x80 aus egal bei welcher Baudrate oder welches Kabel. Die Position und die Häufigkeit des Fehlers variiert und ist nicht deterministisch in meine Augen. Ich frage mich, ob das vorher noch nicht aufgefallen ist und was die Entwickler sich dabei gedacht haben, den Quarz wegzulassen. Darauf wäre es jetzt nicht mehr angekommen. Die Vermutung ist naheliegend, dass es was mit dem Takt zu tun haben könnte. Das war zumindest auch eine Vermutung der KI, dass der interne Oszialltor an der Schwelle der Zuverlässigkeit liegen könnte. Bei Uno und Nano mit externem Quarz ist mir das vorher nie aufgefallen.
Wie löst ihr denn so ein Problem? Es ist schonmal das Thema mit der Checksumme gefallen. Das würde doch aber auch nur helfen, wenn ich auf der Empfangsseite auch einen Code laufen habe, der diese dann Prüft. Wenn ich allerdings nur etwas anzeigen möchte, dann ist das doch auch unpraktisch.
Warum muss das unbedingt am Rechner erfolgen, um die Temperaturwerte anzeigen wurde ein LCD1602 oder ähnlichen mit I2C nehmen. Zu dem für volle Auflösung brauch der DS18B20 750ms. Damit weiss du ob es die MCU schuld ist oder der USB Baustein(ATSAMD).
Das mit der Temperatur ist ja nicht die einzige Funktion, die das Gerät später übernehmen soll. Es wird ja noch viel mehr dran hängen. Mir geht es ja aber jetzt um die grundlegende Funktion des Arduino, die schon nicht korrekt funktioniert.
Ohne Peripherie ist eine einfache Funktion schon nicht in Ordnung. Das würde ich gerne ergründen wieso das so ist und wie man das beheben kann.
Dann must du testen vo her kommt die Abweichung, von welcher MCU. Uno R3 hat auch zwei ATMEGA328P und 16U2, Nano R3 nur 328P, die funktioniren 1A. Wenn die Serialausgabe so wichtig ist und dazu Checksumen problematisch sind wurde eine andere MCU nehmen, in der Nano große gibt es genügend.
Sind die Nano's Originale oder Nachbauten, bei den Zweiten wurde ich vorsichtig, B-Ware usw.
kannst Du mal ein Serial.flush(); direkt nach dem write-Statement und damit vor dem Delay versuchen? Wäre interessant zu erfahren, ob das Problem dann weiter besteht...
Was mir auch nach lesen des Threads noch nicht klar ist:
Du schreibst nicht, ob das Zeichen 0x80 zusätzlich kommt oder ob ein A ersetzt wird.
Um für den 4809 wenigstens einen ersten Ansatz zu testen, würde ich an TX1 einen Serial-USB-Adapter oder ersatzweise einen normalen NANO via Softwareserial anflanschen und auf Serial1 ersatzweise versuchen, ob die Ausgabe dort funktioniert.
Ich hab leider keinen Every, finde das aber sehr spannend...
Dann bin ich auch auf der Seite, dass es ein Problem am SamD gibt.
Versuch das mal mit dem Serial1, wie von mir oben beschrieben.
Da das Problem bei 9600 genauso auftritt, dann auch nur mit 9600 auf der Kommunikationsstrecke verwenden. Softwareserial ist über 19200 etwas anspruchsvoll.
TX1 vom Every an einen PIN von einem NANO und dort einfach eine Ausgabe auf den Seriellen Monitor initieren.