Hallo zusammen, ich habe folgendes Problem: Beim Einsatz eines Pololu AStar 328PB (https://www.pololu.com/category/239/a-star-328pb-micro) kommt es plötzlich zu folgendem Problem: 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.
Mike schrieb: > Beim Einsatz eines Pololu AStar 328PB > (https://www.pololu.com/category/239/a-star-328pb-micro) " The A-Star 328PB Micro is available in four logic voltage and resonator frequency combinations: 5 V, 16 MHz (blue power LED) 5 V, 20 MHz (red power LED) Note: See item-specific page for speed warning. 3.3 V, 8 MHz (green power LED) 3.3 V, 12 MHz (yellow power LED) " Welche Version verwendest du? > FTDI232 Die Chips heißen FT232... Welche Version verwendest du?
Mike schrieb: > Das Board ist in einer größeren Schaltung integriert und eingelötet. Da wird wohl ein Pin belegt sein.
Alexander schrieb: > Da wird wohl ein Pin belegt sein. Warum sollte das Problem dann erst plötzlich auftreten? Mike schrieb: > Bis gestern ging das noch problemlos. Man könnte natürlich fragen, was geändert wurde, bevor es nun plötzlich zu dem Problem kommt.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Rainer W. schrieb: > 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.
:
Bearbeitet durch User
Sorry, kann leider erst nach 30 min antworten ... H. H. schrieb: > Welche Version verwendest du? Das gängige mit blauer LED. 5V, 16MHz Sollte aber für das Problem keine Rolle spielen. > > Die Chips heißen FT232... > > Welche Version verwendest du? Das Modul, das auf der Rückseite mit FTDI232 beschriftet ist. https://eckstein-shop.de/FTDIFT232RL33V5VBasicProgrammerDownloaderUSBtoTTLforArduino
Hans W. schrieb: > 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.
Mike schrieb: > 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 ;-)
:
Bearbeitet durch User
Rainer W. schrieb: > Mike schrieb: >> 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.
Das ist kein E, sondern ein Hamburger Menü. Wer da drauf drückt, wacht im Wunderland auf.
Ernsthaft Freundchen tief durchatmen innehalten.
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).
Harald K. schrieb: > 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.
Moin, 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;-) Gerhard
H. H. schrieb: > Rainer W. schrieb: >> Mike schrieb: >>> 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 schrieb: > H. H. schrieb: >> Rainer W. schrieb: >>> Mike schrieb: >>>> 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.
:
Bearbeitet durch User
Harald K. schrieb: > 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). Das Board ist nicht selbstgebaut, sondern von Pololu, wie eingangs beschrieben. Die Reset-Beschaltung hat einen 10k Widerstand nach Vcc und einen 0,1µ Kondensator nach DTR. Siehe: https://www.pololu.com/file/0J1463/a-star-328pb-micro-schematic.pdf 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.
Mike schrieb: > Hat einen Schalter drauf, um zwischen 5V und 3,3V umzuschalten! Der verändert aber nicht die Signalspannungen.
Mike schrieb: > Harald K. schrieb: >> 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). > > Das Board ist nicht selbstgebaut, sondern von Pololu, wie eingangs > beschrieben. Die Reset-Beschaltung hat einen 10k Widerstand nach Vcc und > einen 0,1µ Kondensator nach DTR. Siehe: > https://www.pololu.com/file/0J1463/a-star-328pb-micro-schematic.pdf > > 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.
Alexander schrieb: > Mike schrieb: >> Das Board ist in einer größeren Schaltung integriert und eingelötet. > > Da wird wohl ein Pin belegt sein. Rainer W. schrieb: > Mike schrieb: >> Bis gestern ging das noch problemlos. > > Man könnte natürlich fragen, was geändert wurde, bevor es nun plötzlich > zu dem Problem kommt. Und wieder: Fragen über Fragen - aber keine Antworten... Gruss Chregu
Christian M. schrieb: > Und wieder: Fragen über Fragen - aber keine Antworten... Der TE hat sich gerade erst angemeldet, da darf er nur eingeschränkt posten.
Von der letzten Watterott Link: Reset 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.
:
Bearbeitet durch User
Mike schrieb: > 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.
:
Bearbeitet durch User
Johannes F. schrieb: > 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. Wäre aber ebenfalls Maker-Murks.
H. H. schrieb: > Wäre aber ebenfalls Maker-Murks. 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).
Gerhard O. schrieb: > 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: Beitrag "Re: Arduino ProMini galvanisch getrennt" 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.
Manfred P. schrieb: > 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.
:
Bearbeitet durch User
Johannes F. schrieb: > H. H. schrieb: >> Wäre aber ebenfalls Maker-Murks. > > 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. Danke an alle für Hinweise und Mitdenken! Mike
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.
:
Bearbeitet durch User
Mike schrieb: > 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. > > Danke an alle für Hinweise und Mitdenken! > > Mike ...
Gerhard O. schrieb: > 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.
Gerhard O. schrieb: > Also sollte man wirklich nicht gleich den Stab über > Hobbyisten ohne Anlass brechen. Völlig richtig. Leider gabs/gibts solchen Murks auch in teurer Industrieelektronik, von Profis verbrochen.
Gerhard O. schrieb: > 1ms kann nicht stimmen. 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.
Johannes F. schrieb: > Da darf man, finde ich, schon halbwegs ausgereifte und durchdachte > Produkte erwarten. so wie den UNO
Johannes F. schrieb: > Gerhard O. schrieb: >> 1ms kann nicht stimmen. > > 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.
Alexander schrieb: > Johannes F. schrieb: >> Da darf man, finde ich, schon halbwegs ausgereifte und durchdachte >> Produkte erwarten. > > so wie den UNO Das Original hat einen USB/UART mit 5V Ausgangspegel.
Johannes F. schrieb: > Aber hinter "pololu.com" stecken doch keine Hobbyisten. Ein Trugschluss. Ich sehe da eher Hobbyisten, die an andere Hobbyisten verkaufen.
H. H. schrieb: > Das Original hat einen USB/UART mit 5V Ausgangspegel. War ja auch genug Platz.
:
Bearbeitet durch User
Alexander schrieb: > H. H. schrieb: >> Das Original hat einen USB/UART mit 5V Ausgangspegel. > > War ja auch genug Platz. Du hast ja so viel von keine Ahnung. Halt einfach die Finger still.
H. H. schrieb: > 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." Auszug von https://www.pololu.com/about
Johannes F. schrieb: > H. H. schrieb: >> 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." > > Auszug von https://www.pololu.com/about Selbstüberschätzung, IMHO.
H. H. schrieb: > Du hast ja so viel von keine Ahnung. Halt einfach die Finger still. EFTDI. Für USB/UART war auf dem Pololu einfach nicht genug Platz.
Alexander schrieb: > EFTDI. Für USB/UART war auf dem Pololu einfach nicht genug Platz. Deine sinnlosen Provokationen werden echt immer nerviger.
Ja, weil es berechtigt ist. Was du hier tust, ist das provozierende Wiederholen offensichtlich falscher oder sinnloser Aussagen.
Beitrag #8047714 wurde vom Autor gelöscht.
Gerhard O. schrieb: > 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.
Alexander schrieb: > Das Akronym ist weiter oben erklärt. 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.
Angehängte Dateien:
-
FTDI.PNG
5,1 KB
Johannes F. schrieb: > Alexander schrieb: >> Das Akronym ist weiter oben erklärt. > > 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. Da muss man 25 Jahre zurück gehen...
:
Bearbeitet durch User
H. H. schrieb: > Mike schrieb: >> Hat einen Schalter drauf, um zwischen 5V und 3,3V umzuschalten! > > Der verändert aber nicht die Signalspannungen. Der Schalter schaltet VCCIO zwischen 3,3V oder 5V um und das verändert natürlich die Signalspannungen.
hätts dir erklärt doch dann machst Du auf Beef Digga https://www.mikrocontroller.net/topic/goto_post/8047640
Angehängte Dateien:
-
FT232R.PNG
11 KB
Sn60pb38cu2 schrieb: > H. H. schrieb: >> Mike schrieb: >>> Hat einen Schalter drauf, um zwischen 5V und 3,3V umzuschalten! >> >> Der verändert aber nicht die Signalspannungen. > > Der Schalter schaltet VCCIO zwischen 3,3V oder 5V um und das verändert > natürlich die Signalspannungen. In der Tat. Aber dann hätte es doch beim TE keine Probleme geben sollen.
Johannes F. schrieb: > Auf dem Chip soll das, was etwas wie ein "E" aussieht, wohl ein Logo > sein, kein Scheiß man, jeder weiß man
@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. Gerhard
Gerhard O. schrieb: > durch entsprechende Wahl der Bord Package Version erzwingen bzw. > wählen. Damit sind nicht alle möglichen Varianten erreichebar. z.B. gibt es keine Version mit dem AVR-GCC 15.x
:
Bearbeitet durch User
Arduino F. schrieb: > Gerhard O. schrieb: >> 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;-)
Angehängte Dateien:
H. H. schrieb: > In der Tat. > > 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.
Gerhard O. schrieb: > 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.
Gerhard O. schrieb: > Dass man beim AVR Arduino > so oft an den Rädern dreht, war mir eigentlich unbekannt. Soweit mir bekannt, gibt es keinen Arduino mit einem ATMega328PB Arduino ist hier also unschuldig und hat auch nichts geändert.
Mike schrieb: > Leider ist die Abstimmung ungenügend, weil der vom Atmega328PB erwartete > Low-Pegel nicht erreicht wird, der Kondensator ist zu schnell wieder > geladen. Sogar bei 5V vom USB/UART. Dann ist das wahrlich ganz schlecht abgestimmt, und war schon beim älteren AVR hart an der Kante.
"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. Gerhard
Arduino F. schrieb: > Gerhard O. schrieb: >> Dass man beim AVR Arduino >> so oft an den Rädern dreht, war mir eigentlich unbekannt. > > Soweit mir bekannt, gibt es keinen Arduino mit einem ATMega328PB > Arduino ist hier also unschuldig und hat auch nichts geändert. Stimmt;-)
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.
Sn60pb38cu2 schrieb: > 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.
Sn60pb38cu2 schrieb: > 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.
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.