Beim Versuch einen neuen Sketch aus der Arduino-IDE über einen externen FTDI232 hochzuladen, bricht der Upload nach 10 "not in sync" Meldungen ab.
Bis gestern ging das noch problemlos.
Folgendes wurde bereits getestet:
Der FTDI funktioniert. Wenn er am USB-Kabel hängt, nicht mit dem Board verbunden und TX und RX gebrückt sind, kommen eingegebene Meldungen im seriellen Terminal zurück
Ich kann jedoch über den AVRISP einen neuen Bootloader hochladen
Ich kann einen Blink-Sketch über den AVRISP hochladen, die LED blinkt.
Ich kann ein einfaches Programm über den AVRISP hochladen, welches eine Ziffer von der seriellen Schnittstelle entgegennimmt und das doppelte des Wert gleich wieder ausgibt. Bei angeschlossenem FTDI232 funktioniert das wunderbar. Die serielle Kommunikation klappt!
Wenn anstelle des Pololu Boards der Atmega328PB aus dem MCUdude MiniCore (https://github.com/mcudude/minicore) verwendet wird, ändert dies nichts. Selbstverständlich für jedes der Boards den passenden Bootloader per AVRISP hochgeladen. Dabei gibt es auch keine Probleme.
Das Board ist in einer größeren Schaltung integriert und eingelötet. Ein Austausch des Boards als weiterer Test ist nahezu unmöglich.
Was kann ich noch testen? An was kann das liegen?
Der FTDI funktioniert. Kann auch andere Boards wie Arduino Mini Pro problemlos flashen.
Die Schutzdiode auf dem Pololu Board funktioniert, denn wenn ich die Schaltung nur über den FTDI232 mit Power verbinde, laufen alle per AVRISP zuvor hochgeladenen Programme
Die serielle Schnittstelle des µC tut auch, wie die Beispiele zeigen
Ich bin für jeden Hinweis dankbar, was ich noch testen kann.
Der Bootloader vom Arduino Nano/Uno lief früher auf 57600 Baud, wurde auf 115200 Baud geändert. Die IDE unterstützt beide, muss man aber richtig einstellen. Liegt es bei dir vielleicht daran.
Warum sollte das Problem dann erst plötzlich auftreten?
Keine Ahnung, vielleicht passt ja irgendein Takt nicht als Folge von einem ungünstig bedienten Strapping‑Pin. Ich kann immer nur mögliche Anfängerfehler benennen über die ich selbst schon gestolpert bin, wie z.B. ein Board einlöten ohne Trennjumper zum flashen vorgesehen zu haben. Natürlich auf anderen Boards, nicht konkret zum ATmega.
Der Bootloader vom Arduino Nano/Uno lief früher auf 57600 Baud, wurde
auf 115200 Baud geändert. Die IDE unterstützt beide, muss man aber
richtig einstellen. Liegt es bei dir vielleicht daran.
Diesem Problem (alter/neuer urboot/optiboot/...) umgehe ich dadurch, dass ich bei jedem neuen Board zunächst den Bootloader der jeweiligen Konfiguration per AVRISP hochlade. Was ja auch funktioniert. Wenn ich das gemacht habe, habe ich den Bootloader, den das Board für das serielle Hochladen erwartet. Hat zumindest bislang alle Probleme diesbezüglich gelöst.
Das Modul, das auf der Rückseite mit FTDI232 beschriftet ist.
Herr Eckstein bzw. der Hersteller kann das Modul benennen wie er möchte. Entscheidend ist der Chip, der auf dem von dir benutzen Exemplar bestückt ist ;-)
Das Modul, das auf der Rückseite mit FTDI232 beschriftet ist.
Und auf dem Chip auf DEINEM Modul steht was genau?
Herr Eckstein bzw. der Hersteller kann das Modul benennen wie er möchte.
Entscheidend ist der Chip, der da drauf sitzt ;-)
Ist ein FT232RL drauf.
3,3V Signale vom FT232RL, aber ein 5V AVR. Das kann gehen, muss es aber nicht.
Offenbar ist hier irgendwas selbstgebaut worden. Ich würde einfach aus dem hohlen Bauch heraus vermuten, daß die für den Bootloader-Betrieb erforderliche Resetleitung vergessen wurde - das ist üblicherweise die DTR-Leitung des FT232 (oder welche USB-Seriell-Bridge auch immer verwendet wird, beim CH340 isses nicht anders).
Offenbar ist hier irgendwas selbstgebaut worden. Ich würde einfach
aus
dem hohlen Bauch heraus vermuten, daß die für den Bootloader-Betrieb
erforderliche Resetleitung vergessen wurde - das ist üblicherweise die
DTR-Leitung des FT232 (oder welche USB-Seriell-Bridge auch immer
verwendet wird, beim CH340 isses nicht anders).
Du meinst Pin 6 des Upload-Anschlusses seines µC Moduls.
Das wäre natürlich denkbar.
Das Problem kenne ich. Der 328pb hat eine etwas niedrigere RESET Schaltschwelle. Da reicht der FTDI DTR Pegel möglicherweise nicht aus, wenn sein VCCIO auf 3.3V sein sollte. Da liegt man dann gerade an der Grenze.
Dieses Phenomen tritt besonders bei USB Serial Adapter auf die 3.3V Logik Pegel haben.
Ich würde vorschlagen, löte versuchsweise einen Widerstand von RESET nach Masse, bei mir war es 68K (10K nach Vcc) um die Rastspannung etwas zu erniedrigen. Wenn dann der DTR Pin vom FTDI auf Masse geht, um den uC zu resetten, dann wird auch die RESET ImPulse Spannung niedriger, um den 328PB Reset zu erzwingen. Versuchs mal. Oder drücke nach dem Anlauf von AVR Dude gleich den Reset Knopf Deiner Schaltung. Dann müsste der BL auch funktionieren. Du lagst wahrscheinlich gerade an der Grenze solange es noch funktionierte.
Diesen Sachverhalt kannst Du durch Vergleich der 328P und 328PB Datenblätter nachprüfen. Der PB braucht einen etwas niedrigeren Low Impuls für Reset.
Watterott berichtete auf Grund meines Bescheids auch darüber auf seiner Webseite und hat es mir bestätigt, fallst Du mir noch nicht glaubst;-)
Das Modul, das auf der Rückseite mit FTDI232 beschriftet ist.
Und auf dem Chip auf DEINEM Modul steht was genau?
Herr Eckstein bzw. der Hersteller kann das Modul benennen wie er möchte.
Entscheidend ist der Chip, der da drauf sitzt ;-)
Ist ein FT232RL drauf.
3,3V Signale vom FT232RL, aber ein 5V AVR. Das kann gehen, muss es aber
nicht.
Hat einen Schalter drauf, um zwischen 5V und 3,3V umzuschalten!
Das Modul, das auf der Rückseite mit FTDI232 beschriftet ist.
Und auf dem Chip auf DEINEM Modul steht was genau?
Herr Eckstein bzw. der Hersteller kann das Modul benennen wie er möchte.
Entscheidend ist der Chip, der da drauf sitzt ;-)
Ist ein FT232RL drauf.
3,3V Signale vom FT232RL, aber ein 5V AVR. Das kann gehen, muss es aber
nicht.
Hat einen Schalter drauf, um zwischen 5V und 3,3V umzuschalten!
Mike, versuch es gleich noch einmal, ob man durch Drücken des Reset Tasters AVRDude gleich nach seinem Start zum Mitspielen bringen kann.
Offenbar ist hier irgendwas selbstgebaut worden. Ich würde einfach aus
dem hohlen Bauch heraus vermuten, daß die für den Bootloader-Betrieb
erforderliche Resetleitung vergessen wurde - das ist üblicherweise die
DTR-Leitung des FT232 (oder welche USB-Seriell-Bridge auch immer
verwendet wird, beim CH340 isses nicht anders).
Ich werde mal dem Tip von Gerhard O. nachgehen. Einerseits gehe ich zwar davon aus, wenn die Pololu-Leute eigens eine Serie mit dem Atmega328PB auflegen, dass sie da auch einiges probiert haben, aber man kann ja nicht wissen.
Offenbar ist hier irgendwas selbstgebaut worden. Ich würde einfach aus
dem hohlen Bauch heraus vermuten, daß die für den Bootloader-Betrieb
erforderliche Resetleitung vergessen wurde - das ist üblicherweise die
DTR-Leitung des FT232 (oder welche USB-Seriell-Bridge auch immer
verwendet wird, beim CH340 isses nicht anders).
Ich werde mal dem Tip von Gerhard O. nachgehen. Einerseits gehe ich zwar
davon aus, wenn die Pololu-Leute eigens eine Serie mit dem Atmega328PB
auflegen, dass sie da auch einiges probiert haben, aber man kann ja
nicht wissen.
Watterott ist es auch passiert. Wer da mit 3.3V Pegeln arbeitet, geht ein Risiko ein. In Schaltungen die nicht auf Batteriebetrieb optimiert werden müssen, lege ich RESET immer etwas niedriger und habe absolut kein Problem mit 3.3V Adaptern.
Um es zu bestätigen, miss mit dem Oszi genau am Reset pin die Low-Impuls Spannung vom 0.1uF C und vergleiche es mit dem 328BP-Datenblatt Grenzwert. Dann besteht etwas mehr Klarheit. Oder: Drück nach dem Start von AVRDude den Reset Taster. Wenn es dann funktioniert, hast Du die Bestätigung.
ATmega328P and ATmega328PB have different thresholds for reset. This can be a problem when using a 5V power supply for the microcontroller and an USB serial adapter with 3.3V logic level on DTR.
Reset Input Threshold Voltage (read as 0/low):
ATmega328P: 2.1V @ Vcc=5V
ATmega328PB: 1.6V @ Vcc=5V
Bei 3.3V DTR Pegel sieht der 328BP am Reset gerade noch 1.7V oder höher.
wenn die Pololu-Leute eigens eine Serie mit dem Atmega328PB
auflegen, dass sie da auch einiges probiert haben,
Wie es halt so ist bei solchen Maker-Pfuschern... Hat ein paar Mal irgendwie bei 25 °C funktioniert, also wird es verkauft.
Man könnte denken, Arduino ist schon... naja. Aber hier ist der Beweis: es geht noch viel schlimmer. Nur nen kurzen Blick auf das Verdrahtungs-Wimmelbild geworfen, es fehlt z.B. der C an AREF (hat zwar mit dem hiesigen Problem nichts zu tun, aber ist trotzdem Mist für die ADC-Performance).
Man könnte versuchen, R3 (die 10k zwischen Reset und VCC) auf z.B. 47k zu vergößern. Kann aber sein, daß auch das nicht reicht.
Nachtrag: oder besser gleich R3 entfernen und dafür so 150k von Reset nach GND. Das dürfte zusammen mit dem internen Pull-up (ca. 50k IIRC) den Ruhepegel hinreichend nach unten ziehen, damit die 3,3-V-Spitze nach unten unter die 1,6 V kommt.
Nachtrag: oder besser gleich R3 entfernen und dafür so 150k von Reset
nach GND. Das dürfte zusammen mit dem internen Pull-up (ca. 50k IIRC)
den Ruhepegel hinreichend nach unten ziehen, damit die 3,3-V-Spitze nach
unten unter die 1,6 V kommt.
Ja natürlich wäre es Murks, es war auch nur eine Idee für eine Quick-and-dirty-Möglichkeit, das Problem des TO erstmal zu beheben (bis eine bessere Platine beschafft ist).
ATmega328P and ATmega328PB have different thresholds for reset. This can
be a problem when using a 5V power supply for the microcontroller and an
USB serial adapter with 3.3V logic level on DTR.
Reset Input Threshold Voltage (read as 0/low):
ATmega328P: 2.1V @ Vcc=5V
ATmega328PB: 1.6V @ Vcc=5V
Das kann ich nicht ganz nachvollziehen, das Problem wäre doch der nicht erreichte HIGH-Pegel?
Das klingt ähnlich meinem Arduino-ProMini, den ich per externem CH340 programmieren muß. Ich wollte eine galvanische Trennung, die Zielschaltung ist nicht sicher netzgetrennt, und habe etwas mit dem ADUM-1201 gebaut, siehe dort:
Erst später hatte ich eine Anwendung mit abweichender Versorgungsspannung und siehe da, das fängt meine Trennung ab: Am Eingang der PC samt Seriellwandler, auf Seiten des µC laufen die Signale mit dessen Versorgung.
Das kann ich nicht ganz nachvollziehen, das Problem wäre doch der nicht
erreichte HIGH-Pegel?
Nein. Das Problem ist vermutlich, dass die Schwelle zu /low/ knapp nicht erreicht wird (da niedriger als beim 328P) und damit kein Reset ausgelöst wird. Der Reset-Eingang der AVRs ist invertierend.
Siehe den verlinkten Schaltplan. Der DTR-Ausgang des FTDI ist über 100n kapazitiv an den Reset-Eingang des AVRs gekoppelt.
Ja natürlich wäre es Murks, es war auch nur eine Idee für eine
Quick-and-dirty-Möglichkeit, das Problem des TO erstmal zu beheben (bis
eine bessere Platine beschafft ist).
Ich hab dich schon verstanden.
Solche Q&D-Lösungen hab ich sogar professionell gemacht, Produktion musste unbedingt laufen...
Die saubere Lösung war dann aufwändiger, und zum Teil richtig teuer.
Hat mir jetzt doch keine Ruhe gelassen. Der Tip von Gerhard O. ist ein Treffer! Danke Dir!
Der AVRDude zieht leider nur einmal vor dem ersten Versuch Reset für ca. 1 milliSekunde nach Ground, über den Kondensator bleibt die Spannung bei ca. 2,4 Volt. Er versucht es leider bei den folgenden 9 Versuchen nicht nochmal. Das Problem mit Reset-Taster drücken heisst: Bereits drücken, während der Sketch noch kompiliert wird, und dann zum richtigen Zeitpunkt loslassen. Da dieser Zeitpunkt jedoch praktisch nicht zu treffen ist, habe ich jetzt mal den Kondensator gebrückt, und voilà: Der Upload tut.
Hast also tatsächlich damit zu tun, dass der Pegel grenzwertig ist.
Naja. Momentan ist die Ursache des Problem noch ungewiss. Ja. Der 328BP bedarf einer kleinen Anpassung. Polulu oder Watterott BP Varianten weisen dieses Problem auf. Aber es lässt sich leicht beheben, falls es sich auch bei Mike herausstellen sollte, die Ursache seines Problems zu sein.
Naja. Sicher diese Art von uC Elektronik hat seine Schwächen, machen aber keinen professionellen Anspruch. Andrerseits funktionieren die Sachen für die meisten Leute relativ problemlos. Der BP ist diesbezüglich ein "Outlyer", weil kein normaler User darauf kommen würde, den Datenblatt Unterschied zwischen 328Ps und 328BP zu kennen und anfangs ein kniffeliges Problem. Bei mir löste ichdas Problem mit einem 68K nach Masse und gatte niemals wieder ein Problem.
So, ich denke wir sollten nicht unnötig zu hart urteilen und Schwächen zielgerecht angehen, wo es in der Praxis notwendig ist.
Ich würde sogar behaupten wollen, daß Elektronik, durch Wirtschaftsfuchser in den Firmen, der Bevölkerung manchmal durch aggressives Sparen schlechtere Elektronik verscherbelt als es oft die Hobbyisten tun. Also sollte man wirklich nicht gleich den Stab über Hobbyisten ohne Anlass brechen.
Hat mir jetzt doch keine Ruhe gelassen. Der Tip von Gerhard O. ist
ein
Treffer! Danke Dir!
Gern geschehen;-)
Der AVRDude zieht leider nur einmal vor dem ersten Versuch Reset für ca.
1 milliSekunde nach Ground, über den Kondensator bleibt die Spannung bei
ca. 2,4 Volt. Er versucht es leider bei den folgenden 9 Versuchen nicht
nochmal. Das Problem mit Reset-Taster drücken heisst: Bereits drücken,
während der Sketch noch kompiliert wird, und dann zum richtigen
Zeitpunkt loslassen. Da dieser Zeitpunkt jedoch praktisch nicht zu
treffen ist, habe ich jetzt mal den Kondensator gebrückt, und voilà: Der
Upload tut.
1ms kann nicht stimmen. Die DTR Leitung bleibt auf LOW solange der AVRDude den Port belegt. Wenn die Reset Timing wirklich nur 1ms ist, dann ist der Wert des Cs falsch. Der Reset Impulse am Reset pin muss einige hundert ms lang sein.
Hast also tatsächlich damit zu tun, dass der Pegel grenzwertig ist.
Ich würde sogar behaupten wollen, daß Elektronik, durch
Wirtschaftsfuchser in den Firmen, der Bevölkerung manchmal durch
aggressives Sparen schlechtere Elektronik verscherbelt als es oft die
Hobbyisten tun. Also sollte man wirklich nicht gleich den Stab über
Hobbyisten ohne Anlass brechen.
Aber hinter "pololu.com" stecken doch keine Hobbyisten. Das sind Leute, die dieses Zeug /gewerblich/ entwickeln, vermarkten und verkaufen. Zumindest sieht diese Website stark danach aus. Da darf man, finde ich, schon halbwegs ausgereifte und durchdachte Produkte erwarten.
Paßt aber zu den 100n im Schaltplan von "polulu". Die ergeben mit den 10k eine Zeitkonstante von 1 ms (praktisch noch etwas weniger, da der interne Pull-up noch parallel liegt).
Also ist die eingeplante Kapazität auch um den Faktor 100 mal n zu niedrig, wenn es n mal 100 ms sein sollen.
Paßt aber zu den 100n im Schaltplan von "polulu". Die ergeben mit den
10k eine Zeitkonstante von 1 ms (praktisch noch etwas weniger, da der
interne Pull-up noch parallel liegt).
Also ist die eingeplante Kapazität auch um den Faktor 100 mal n zu
niedrig, wenn es n mal 100 ms sein sollen.
Die Zeitkonstante nützt halt nichts wenn der nötige Pegel gar nicht erreicht wird.
Ein Trugschluss. Ich sehe da eher Hobbyisten, die an andere Hobbyisten
verkaufen.
Really?
"Pololu is an electronics manufacturer and online retailer serving education, maker, and professional engineering industries with products ranging from sensors and motion control electronics to motors and wheels to complete robots. We strive to offer well-engineered, quality products that enable our customers to take their own projects from idea to reality."
Ein Trugschluss. Ich sehe da eher Hobbyisten, die an andere Hobbyisten
verkaufen.
Really?
"Pololu is an electronics manufacturer and online retailer serving
education, maker, and professional engineering industries with products
ranging from sensors and motion control electronics to motors and wheels
to complete robots. We strive to offer well-engineered, quality products
that enable our customers to take their own projects from idea to
reality."
1ms kann nicht stimmen. Die DTR Leitung bleibt auf LOW solange der
AVRDude den Port belegt. Wenn die Reset Timing wirklich nur 1ms ist,
dann ist der Wert des Cs falsch. Der Reset Impulse am Reset pin muss
einige hundert ms lang sein.
Nein, mit Oszilloskop getestet!
Hier werden nun Erinnerungen aus der Modemzeit wach!
Der Kondensator ist eine Krücke aus der Ursprungszeit der seriellen Kommunikation. Da wurde beim Öffnen einer seriellen Verbindung (File Open) DTR auf Low gezogen, damit die Datenendeinrichtung (Modem, Teletyper) darüber per High ihre Betriebsbereitschaft anzeigen kann. Das Senden wurde erst begonnen, wenn die Betriebsbereitschaft angezeigt wurde.
Und weil das so war, war es ein Problem für Uploader wie AVRDude&Co. einen Reset zu erzwingen. Wie Du schon schriebst, haben frühere Versionen von der Uploader die Leitung eben solange auf Low gehalten, bis endlich die Gegenstelle ein High meldet. Ein µC auf Low kann aber kein High senden.
Nun aber hat es sich herumgesprochen (und das war auch zu Modemzeiten schon so), dass man die Betriebssystemfunktionen zum Öffnen einer seriellen Verbindung auch verändern kann, indem man den seriellen Baustein direkt programmiert. Seit Version 7.2 zieht z.B. AVRDude die Leitung eben nur noch für die gemessene 1 mSec auf Low, und setzt den Pin danach wieder High.
Eine kurze Recherche hat gezeigt, dass dies zumindest mit FTDIs und CH340 problemlos funktioniert. Daher ist der Kondensator in diesen Fällen überflüssig und kann -wie bei der AVRISP-Schnittstelle- wegfallen!
Konnte noch eine Version 5.11 finden, die hält die Leitung tatsächlich noch dauerhaft offen und braucht den Kondensator.
FTDI steht für "Future Technology Devices Incorporated". Da gibt es vorn kein "E".
Auf dem Chip soll das, was etwas wie ein "E" aussieht, wohl ein Logo sein, oder wie auch immer man das nennt.
FTDI steht für "Future Technology Devices Incorporated". Da gibt es vorn
kein "E".
Auf dem Chip soll das, was etwas wie ein "E" aussieht, wohl ein Logo
sein, oder wie auch immer man das nennt.
@Mike:
"Konnte noch eine Version 5.11 finden, die hält die Leitung tatsächlich
noch dauerhaft offen und braucht den Kondensator."
Danke für Deine Ausführungen. Daß die neueren Versionen sich nun anders verhalten, war mir noch unbekannt. Wenn ich an alten Projekten arbeite verwende ich immer die Original Werkzeug Versionen die bei der Erstentwicklung verfügbar waren und da verhält sich DTR genauso wie auch von mir erwähnt. Gut zu wissen. Es wundert mich, daß dies überhaupt geändert wurde. Alle mir bekannten Arduino Bords weisen den besagten C auf. Man lernt nie aus.
Beim Arduino IDE lässt sich übrigens die Version des Compilers and AVRDude durch entsprechende Wahl der Bord Package Version erzwingen bzw. wählen.
durch entsprechende Wahl der Bord Package Version erzwingen bzw.
wählen.
Damit sind nicht alle möglichen Varianten erreichebar.
Sicher. Aber ich habe am RESET Pin schon lange nicht mehr herumfummeln müssen und ust mir bisher nicht aufgefallen. Dass man beim AVR Arduino so oft an den Rädern dreht, war mir eigentlich unbekannt. Ich sehe ohnehin eigentlich keinen triftigen Grund das Verhalten des DTR Pins in Anbetracht des Arduino AVR Konzepts zu ändern, die den besagten C haben. Man lernt nie aus.
Da verlässt man sich auf Fakten auf die man sich schon längere Zeit stützt und dann wird "hinterrücks" an den Rädern gedreht und stehe dann wie ein Narr da;-)
Aber dann hätte es doch beim TE keine Probleme geben sollen.
Doch, wie beschrieben leider!
Die Abstimmung Kondensator, externer Widerstand nach High und interner Widerstand des ResetPins sind ungenügend.
Zunächst ist der Kondensator ungeladen, weil beide Seiten High, dann wird das Ende am Programmer auf Low gezogen, wodurch der -ungeladene- Kondensator für einen ultrakurzen Zeitpunkt wie ein Kurzschluss wirkt und sofort durch den externen und internen Widerstand des Reset-Pins auf 5V gebracht (egal ob der Programmer mit 3,3V oder 5V läuft, da GND beidseitig GND ist).
Leider ist die Abstimmung ungenügend, weil der vom Atmega328PB erwartete Low-Pegel nicht erreicht wird, der Kondensator ist zu schnell wieder geladen.
Wenn man nun nach diesem Phänomen sucht, findet man zahlreiche Diskussionsbeiträge. Ich hatte das eingangs leider nicht auf dem Schirm, dank Gerhard O. hat es dann aber sofort Klick gemacht!
Die ganzen Tips, die man findet, die Abstimmung durch Hinzufügen weiterer Widerstände zu verschlimmbessern, erzeugen meist weitere Probleme.
Hier ist das Dokument "AVR042: AVR Hardware Design Considerations" (https://ww1.microchip.com/downloads/en/appnotes/atmel-2521-avr-hardware-design-considerations_applicationnote_avr042.pdf)
ein netter Berater. Am Besten fährt man damit, den Kondensator gegen den 330R-Widerstand zu tauschen, den obiges Dokument empfiehlt. Dann wird der Pin durch neuere Programmer (AVRDude ab V7.20) für kurze Zeit zuverlässig auf 0 gezogen und die Krücke Kondensator fällt weg. Mangels SMD-Widerstand habe ich nun den Kondensator entfernt, die Lötpads gebrückt und einen 330R in mein Serial-Programmer-Kabel integriert.
Da verlässt man sich auf Fakten auf die man sich schon längere Zeit
stützt und dann wird "hinterrücks" an den Rädern gedreht und stehe dann
wie ein Narr da;-)
Eben nicht. Das ist ja leider oft das Problem, das man sich einfach euf bestimmte Dinge eingeschossen hat, weil es eben einfach funktioniert. Daher sind ja Foren, wie dieses hier, sehr sinnvoll um aus Denkmustern auszubrechen. Dein Hinweis hat bei mir dann im Langzeitgedächtnis ein paar Dinge getriggert, den Rest ergab dann das Netz.
Warum das geändert wurde, ist mir klar: Damit hat man das Ganze nun sauber implementiert, weil man durch Kontrolle des UART-Chips eben auch DTR beeinflussen kann. Die Änderung ist rückwärtskompatibel und funktioniert mit dem Kondensator auch recht und schlecht (wie Du selbst erfahren hast). Jedoch erlaubt diese nun beim Einsatz neuerer Software, den Kondensator wegzulassen um damit für stabile Verhältnisse zu sorgen.
"Die einzige Konstante in der Welt der Technik ist die Änderung"
Da habe ich wieder Neues erfahren - diese Änderungen waren mir w.g. nicht auf dem Radarschirm, weil ich nie Grund hatte, mich diesbezüglich auf dem Laufenden zu halten. Die Gründe sind ja stichhaltig.
Bisher hielt ich mich auch bei eigenen Designs an den Bootloader Arduino "Standard" und hat immer anstandslos funktioniert. Nur beim Watterott 328BP gab es die erörternden Ungereimtheiten die bei mir durch Level shifting mit dem 68K erzwungen wurden.
Naja. Da haben wir alle davon profitiert, daß dieses Thema frisch angeschnitten wurde.
Man sollte mit der Lösung "Kondensator entfernen / Brücke" beachten, daß es so einige Terminalsoftware wie z. B. Putty gibt, die beim öffnen des Ports DTR auf "Dauerlow" setzt. Dann wäre der AVR im Dauerreset.
Man sollte mit der Lösung "Kondensator entfernen / Brücke" beachten, daß
es so einige Terminalsoftware wie z. B. Putty gibt, die beim öffnen des
Ports DTR auf "Dauerlow" setzt.
Dann nimm HTerm. Da kannst du einstellen, wie sich DTR beim Öffnen der Schnittstelle verhalten soll.
Man sollte mit der Lösung "Kondensator entfernen / Brücke" beachten, daß
es so einige Terminalsoftware wie z. B. Putty gibt, die beim öffnen des
Ports DTR auf "Dauerlow" setzt. Dann wäre der AVR im Dauerreset.
Die Funktion dieser Statusleitung wurde weiter vorne erklärt.
In der Welt der Chinuinos macht man USB-Seriell per CH340 und hat auf den typischen 80ct-Boards DTR nicht auf den Anschluß geführt. Damit kann man trotzdem Software uploaden, indem man kurz nach Start den Reset-Knopf drückt.
Ich würde den C weder entfernen noch brücken, sondern über passende Bauteilewerte nachdenken.
