ich habe bei einem aktuellen Projekt mit einem Arduino UNO Rev3 SMD ein Problem beim Empfangen von Daten, die über die Serielle Schnittstelle von einem PC gesendet werden. Auf PC Seite verwende ich das Tool SerialSend was eigentlich ganz nett gemacht ist. Der Nachteil an SerialSend ist allerdings, dass der Com Port bei jedem Sendevorgang erneut geöffnet und danach wieder geschlossen wird. Daraus ergeben sich beim Arduino 2 Probleme:
Durch das DTR Signal führt der Arduino einen Reset durch.
Der RX Pin (auf Arduinoseite) wird 2 Mal auf Low gezogen und die eigentliche Nachricht verfälscht. Im Signalverlauf sind die beiden Spikes gut erkennbar und markiert, der Teil gehört nicht zur Nachricht, diese beginnt mit 0x0D.
Für das erste Problem gibt es hardwareseitig mehrer Lösungen, also kein Thema.
Beim Zweiten Problem bin ich noch nicht weitergekommen. Durch das Verhalten wird die Nachricht verfälscht und es ist schwierig den Fehler zu filtern, da das Timing leicht variiert und so teilweise unterschiedliche Werte interpretiert werden oder sogar Nachfolgende Bytes nicht richtig erkannt werden. Die beiden Spikes treten auch auf, wenn lediglich der Port geöffnet wird und keine Nachricht versendet wird. Ganz egal ob SerialSend oder ein normales Terminalprogramm verwendet wird. Ist dieses Verhalten normal oder wird es durch eine Eigenheit des USB Serial Converters des Arduinos verursacht?
ist die Folge von 1.
Warum willst Du unbedingt den Programmingport benutzen?
Kannst Du vor dem senden eine Pause einbauen, um sicherzugehen dass der Port kein zweites reset macht?
und warum stellt das ein Problem dar? Dein Empfangsparser soll sowieso so stabil sein, dass er diesen "fehlerhaften" Anfang als Fehler erkennt und wegwirft. Wenn der Anfang ein 0x0D ist doch alles gut ... eigentlich...
Beim seriellen Monitor verhält es sich genau so, es fällt meiner Meinung nach nur nicht auf, da der Arduino beim öffnen des seriellen Monitors einen Reset macht, der Port dann geöffnet bleibt und die Daten durch die manuelle Eingabe so spät nach dem öffnen gesendet werden, dass man die beiden Impulse nicht mitbekommt. Ich habe davor schon mehrere Projekte mit serieller Schnittstelle realisiert, aber das Verhalten ist mir auch zum ersten Mal aufgefallen.
Ich habe das Programm Docklight verwendet.
Alles klar, das war auch meine Vermutung. Habe darum schon einen USB Serial Converter mit FT232 bestellt, es muss nicht zwingend er Programmierport sein, wäre eben einfach gewesen ;). Meinst du, dass das Problem damit nicht auftritt?
Mir geht es nicht nur darum eine Lösung zu finden sondern auch darum zu verstehen, was genau passiert. Fände es einfach noch interessant zu wissen, warum die Impulse auf einer Datenleitung auftauchen und nicht nur der Reset ausgelöst wird. Die Impulse sind im übrigen auch noch da, wenn die RESTE EN Lötbrücke entfernt wird.
Jaein, das war auch der Workarround der mir als erstes eingefallen ist, funktioniert prinzipiell, schöner und sauberer ist es aber natürlich wenn sich die beiden Impulse generell vermeiden lassen.
Absolut richtig, für den Fall, dass nur ein Fehlerhaftes Byte erkannt wird ist das natürlich problemlos möglich. Auch das Triggern auf definierte Startbytes wäre kein Problem. Da das Timing der beiden Impulse allerdings leicht Variiert kommt es vor, dass dadurch die ersten Bytes der Nutzdaten nicht richtig interpretiert werden und 0x0D nicht mehr als 0x0D erkannt wird. Tritt zwar seltener auf, kommt aber durchaus vor und da wird es dann schwer die Daten mittels Empfangsparser zu retten.
Mit dem "eigentlich" hast du natürlich recht, mir geht es auch darum dieses Thema zu verstehen und dass anderen die auf die Problematik stoßen geholfen ist
Sorry, die Info ist natürlich wichtig und wird oben noch ergänz. Geht um einen UNO Rev3 SMD.
Ich habe mich für die Variante mit der Lötbrücke entschieden, zwar wird dann kein Reset mehr durchgeführt, allerdings sind die Impulse trotzdem noch auf der Datenleitung sichtbar. Weißt du ob es dafür auch eine Lösung gibt und ob die Impulse vom Arduino kommen oder völlig normal sind und generell beim öffnen eines Com Ports auftreten?
Ich werde morgen das Verhalten mit einem Serial Converter auf FT232 Basis testen und berichten.
Gute Idee, wird aber vermutlich nicht helfen , die RESET EN Brücke ist bereits entfernt, es wird also kein Reset mehr beim öffnen des Com Ports durchgeführt und somit die setup() Routine nicht durchlaufen. Generell ist es natürlich nicht so toll, die Programmierschnittstelle zu verwenden, das ist mir klar, ich bin gespannt was der Test mit dem FT232 ergibt.
Sorry, vielleicht habe ich dich falsch verstanden und mich nicht gut ausgedrückt. Das war keinesfalls besserwisserisch gemeint, ich bin für jede Hilfe dankbar! setup() wird natürlich beim booten durchlaufen, allerdings nicht mehr nach dem öffnen des Com Ports, da hier ja kein Reset mehr durchgeführt wird. Darum meine Vermutung, dass es am Verhalten nichts ändert. Vielleicht habe ich aber auch einfach nicht richtig verstanden was die Verzögerung in dem Fall bringt. Werde es morgen testen und berichten wie der Signalverlauf auf dem LA aussieht
Alles klar, danke
Du weißt nicht zufällig ob das Verhalten bei allen anderen USB Serial Convertern wie z.B. FT232 auch so ist oder ob das nur beim Arduino so ist wenn über die Programmierschnittstelle kommuniziert wird?
Ich hab nur die Vermutung, das evtl. irgendwas vom UNO den Spike auslöst und das evtl. vermieden werden kann, wenn der nicht sofort startet.
Wie gesagt, ich kann Dir da nicht weiter helfen - ausser Ausschlußverfahren.
Alles klar, war auch meine Vermutung, hatte es nur aufgrund der Begründung von oben Gedanklich schon ausgeschlossen, war vielleicht ein Fehler. Wird morgen getestet
also das Problem hat sich mittels externem USB Serial Converter lösen lassen. Wird bei diesem der Com Port geöffnet gibt es die zwei Spannungsimpulse nicht und alles funktioniert ordnungsgemäß.
Delay in der Setup() Routine hat leider nichts bewirkt. Es scheint also so, als würde der UNO auch ohne Autorest noch etwas auf der RX Leitung machen. Die Sauberste Lösung für eine USB Serial Verbindung ist einfach ein externer Baustein.
, die RESET EN Brücke ist bereits entfernt, es wird also kein Reset mehr beim öffnen des Com Ports durchgeführt und somit die setup() Routine nicht durchlaufen. Generell ist es natürlich nicht so toll, die Programmierschnittstelle zu verwenden, das ist mir klar, ich bin gespannt was der Test mit dem FT232 ergibt.