Ich habe von AZ-Delivery diesen Arduino-Uno-Clone:
https://www.az-delivery.de/collections/mikrocontroller/products/mikrocontroller-board
Ich programmiere das Board mit AVRDude und dem vorinstallierten
Bootloader. Aber meine Anwendung die ich flashe ist komplett frei von
Arduino entwickelt.
Das Board funktioniert wie erwartet, hat aber eine kleine Angewohnheit
die mich stört. Keine Ahnung ob original UNOs das auch haben.
Immer wenn ich den COM-Port mit PuTTY öffne mach das Board einen Reset.
Und das möchte ich nicht.
Als USB-UART-Bridge ist der CH340G drauf.
Ich habe mal die Pins am CH340G durch gepiepst.
DTR ist über einen Kondensator mit Reset verbunden.
Außer einem Pullup-Widerstand nahe dem SPI-Stecker, habe ich keine
weitere Verbindung der Restleitung gefunden.
Ich habe nachgemessen sobald ich mich mit PuTTY verbinde wechselt der
Pin von Hi auf Low. Und beim Trennen geht er wieder auf Hi zurück.
Ich habe die Flow-Control Einstellungen in PuTTY alle durchprobiert.
Aber ich konnte das nicht verhindern.
Ist das normal, bleibt mir nichts anderes übrig als den Kondensator
auszulöten, oder habe ich da eine Option in PuTTY übersehen?
(Ich weiß, wenn ich den Kondensator auslöte ich zum flashen manuell den
Resetkopf drücken muss)
EDIT, das Bild ein zweites mal angehangen, beim ersten mal, war der
Dateiname zu lang (Forum Bug?)
Christian K. schrieb:> Ist das normal, bleibt mir nichts anderes übrig als den Kondensator> auszulöten
Man könnte auch ein anderes Terminalprogramm als Putty verwenden.
Nämlich eins, bei dem das konfigurierbar IST.
HTerm z.B....
Christian K. schrieb:> Immer wenn ich den COM-Port mit PuTTY öffne mach das Board einen Reset.> Und das möchte ich nicht.
Dann gewöhne PuTTY ab, mit DTR rumzuzappeln oder nimm gleich HTerm. Da
kannst du die Signalisierung garantiert abschalten.
Philipp K. schrieb:> Der Reset ist normal, der com port wird erst beim öffnen> initialisiert.>> Müsste bei jedem originalen Board ebenso sein.
Nöö....
z.B. der Leonardo und seine Kumpels tut das nicht.
Es ist hat das Gewackel am DTR Pin!
Und dafür ist das Anwendungsprogramm, mit seiner Comport Öffnung
zuständig.
Also Putty nicht geeignet.
Die Alternativen:
* 300 Ohm von Reset nach Vcc unterdrückt den DTR Impuls
* 10µF von GND zu Reset unterdrückt den DTR Impuls
* Die originalen UNOs haben eine durchkratz Reset-Enable Lötbrücke
EAF schrieb:>> Müsste bei jedem originalen Board ebenso sein.> Nöö....> z.B. der Leonardo und seine Kumpels tut das nicht.
Es geht hier aber um einen Arduino UNO.
Stefan ⛄ F. schrieb:> EAF schrieb:>>> Müsste bei jedem originalen Board ebenso sein.>>> Nöö....>> z.B. der Leonardo und seine Kumpels tut das nicht.>> Es geht hier aber um einen Arduino UNO.
Der UNO ist ein konkretes Board.
Der UNO ist eine Teilmenge von "jedem originalen Board"
Aber solche Feinheiten kannst du ja nicht wissen, verstehen, oder gar
akzeptieren.
c-hater schrieb im Beitrag #6833194:
>> Ich habe wie gesagt Flow control in PuTTY ausgeschaltet, und auch die>> anderen Modi probiert. Aber DTR wird immer auf Low gezogen.>> Ja schön. Und was hindert dich nun daran HTerm statt Putty zu verwenden?
Interessant: Mal fix den ChinUNO angeklemmt, egal, was ich einstelle,
liefert er mit PuTTY einen Reset - stört mich nicht.
Auf der Platte findet sich ein älteres HTerm 0.6beta, da finde ich
keinerlei Einstellungen zu Handshake etc., kann nur COMx und Bitrate
auswählen.
Tatsächlich, das verbindet sich mit dem UNO ohne Reset !
Manfred schrieb:> Auf der Platte findet sich ein älteres HTerm 0.6beta, da finde ich> keinerlei Einstellungen zu Handshake etc., kann nur COMx und Bitrate> auswählen.
Versuchs doch mal mit dem Internet. Da gibt es die Version 0.8.5 und bei
der lässt sich DTR deaktivieren.
https://www.der-hammer.info/pages/terminal.html
Wolfgang schrieb:> Versuchs doch mal mit dem Internet. Da gibt es die Version 0.8.5 und bei> der lässt sich DTR deaktivieren.
Texte verstehen ist nicht Dein Ding:
Manfred schrieb:> Tatsächlich, das verbindet sich mit dem UNO ohne Reset !
Es gibt also kein Problem, die hier ausprobierte 0.6 erfüllt genau das,
was Christian K. (the_kirsch) angefragt hat!
Manfred schrieb:> Texte verstehen ist nicht Dein Ding:
Wenn man eindeutig nachvollziehen möchte, dass DTR der Grund ist, wäre
es vielleicht nicht die schlechteste Idee, die Steuerbarkeit von DTR im
aktuellen HTerm zu nutzten - geht/geht nicht - du verstehst?
Die Pegeländerung des DTR beim Öffnen des CH340-COM-Ports macht nach
meiner Beobachtung der CH340 und sein Treiber automatisch. Selbiger
Treiber ist offensichtlich eine Blackbox. Darum hat weder PuTTY noch
H-Term schätzungsweise Zugriff auf DTR. Es bleibt zur Unterbindung des
Resets die Entfernung des Kondensators zwischen DTR und Reset.
Aber vielleicht gibts ja hier in der erlauchten Expertenrunde Jemanden
der/die die Geheimnisse des CH340-Treibers kennt? ...
Wolfgang W. schrieb:> Die Pegeländerung des DTR beim Öffnen des CH340-COM-Ports macht nach> meiner Beobachtung der CH340 und sein Treiber automatisch.
Genau das hatte ich vermutet. Siehe weiter vorne, mein kurzer Test mit
HTerm bestätigt das nicht.
Ein link zu HTerm wurde gezeigt, jetzt ist es an Christian, das zu
testen und zu berichten.
Wolfgang W. schrieb:> Aber vielleicht gibts ja hier in der erlauchten Expertenrunde Jemanden> der/die die Geheimnisse des CH340-Treibers kennt? ...
Das hat nichts mit dem CH340-Treiber zu tun, sondern mit der Art und
Weise, wie die Software den COM-Port konfiguriert.
In der Struct, die an SetCommState() übergeben wird, wird auch das
Verhalten von DTR beim Öffnen des Devices festgelegt: High-Pegel,
Low-Pegel oder Nutzung als Handshake-Leitung.
Üblich (aber in diesem Fall ungünstig) ist, DTR beim Öffnen
einzuschalten, eine fallende Flanke kann dann ggf. benutzt werden, um
ein Modem zum Auflegen zu bewegen. Dieses Verhalten hat PuTTY beim
Start, Konfigurationsmöglichkeiten scheint es (abgesehen von DTR als
Handshake-Leitung) nicht zu geben.
HTerm lässt DTR offenbar auf Low-Pegel, sofern man es nicht explizit
anders konfiguriert.
1) Habe gerade HTerm 0.8.5 mit meinem CH340-Modul verbunden: DTR bleibt
unabhängig vom Häkchen bei DTR immer high (inaktiv). Legacy-COM1 DTR
funktioniert.
2) Die Manipulation von DTR über SetCommState hatte bei den CH340-Ports
(im Gegensatz zu Legacy-COM1) bei mir keinen Einfluss.
Wolfgang W. schrieb:> 1) Habe gerade HTerm 0.8.5 mit meinem CH340-Modul verbunden: DTR bleibt> unabhängig vom Häkchen bei DTR immer high (inaktiv). Legacy-COM1 DTR> funktioniert.
Wo machst du da ein Häkchen?
Gerade probiert: Arduino Clone mit CH340G
Mit aktiviertem DTR-Handshake bekommt der Arduino beim Connect mit HTerm
einen Reset, ohne nicht.
Die Funktion lässt sich mit der Taste "DTR" im Bereich "Input Control"
umschalten, allerdings nur, wenn der CH340 connected ist.
Im Disconnect-Zustand lässt sich die DTR-Funktion mit der Taste nicht
umschalten. Bei leuchtender DTR-Taste bekommt der Arduino beim Connect
einen Reset, sonst nicht.
Wolfgang W. schrieb:> Habe gerade HTerm 0.8.5 mit meinem CH340-Modul verbunden: DTR bleibt> unabhängig vom Häkchen bei DTR immer high (inaktiv).
Was passiert bei Dir, wenn Du PuTTY verwendest?
@ Wolfgang (Gast):
Genau an der von Dir markierten Stelle mache ich DTR ON/OFF (natürlich
im connected-Mode). Mein Fehler: natürlich keine Häkchen sondern DTR
ON/OFF!
@ Hmmm:
Bei PuTTY wird der DTR bei allen CH340ern aktiviert, d. h. beim Öffnen
des Ports negative Flanke und beim Schliessen positive Flanke.
Wolfgang W. schrieb:> @ Hmmm:> Bei PuTTY wird der DTR bei allen CH340ern aktiviert, d. h. beim Öffnen> des Ports negative Flanke und beim Schliessen positive Flanke.
Dann ist es allerdings seltsam, dass in Deinem eigenen Code
SetCommState() keinen Einfluss auf DTR hatte. Oder hast Du versucht,
mehrmals SetCommState() aufzurufen, statt EscapeCommFunction() zu
nutzen?
uno.jpg
(89 KB)
