Welche AVRs haben die neue UPDI Schnittstelle? Nur die AVR DA Serie oder gibt es auch welche aus der Atmega Serie?
Hallo, alle neuen Modelle. :-)
1 | 8 Pin | 14 Pin | 20 Pin | 24 Pin |
2 | ___________|____________|____________|_____________ |
3 | ATtiny202 | ATtiny204 | | |
4 | ATtiny402 | ATtiny404 | ATtiny406 | |
5 | | ATtiny804 | ATtiny806 | ATtiny807 |
6 | | ATtiny1604 | ATtiny1606 | ATtiny1607 |
7 | ___________|____________|____________|_____________ |
8 | ATtiny212 | ATtiny214 | | |
9 | ATtiny412 | ATtiny414 | ATtiny416 | ATtiny417 |
10 | | ATtiny814 | ATtiny816 | ATtiny817 |
11 | | ATtiny1614 | ATtiny1616 | ATtiny1617 |
12 | | | ATtiny3216 | ATtiny3217 |
13 | ___________|____________|____________|_____________ |
14 | | ATtiny424 | ATtiny426 | ATtiny427 |
15 | | ATtiny824 | ATtiny826 | ATtiny827 |
16 | | ATtiny1624 | ATtiny1626 | ATtiny1627 |
17 | | ATtiny3224 | ATtiny3226 | ATtiny3227 |
18 | |
19 | |
20 | 28/32 Pin | 48 Pin |
21 | ___________|____________ |
22 | ATmega808 | ATmega809 |
23 | ATmega1608 | ATmega1609 |
24 | ATmega3208 | ATmega3209 |
25 | ATmega4808 | ATmega4809 |
26 | |
27 | |
28 | 28 Pin | 32 Pin | 48 Pin | 64 Pin |
29 | ___________|____________|____________|_____________ |
30 | AVR32DA28 | AVR32DA32 | AVR32DA48 | |
31 | AVR64DA28 | AVR64DA32 | AVR64DA48 | AVR64DA64 |
32 | AVR128DA28 | AVR128DA32 | AVR128DA48 | AVR128DA64 |
33 | ___________|____________|____________|_____________ |
34 | AVR32DB28 | AVR32DB32 | AVR32DB48 | |
35 | AVR64DB28 | AVR64DB32 | AVR64DB48 | AVR64DB64 |
36 | AVR128DB28 | AVR128DB32 | AVR128DB48 | AVR128DB64 |
37 | |
38 | |
39 | 14 Pin | 20 Pin | 28 Pin | 32Pin |
40 | ___________|____________|____________|_____________ |
41 | AVR16DD14 | AVR16DD20 | AVR16DD28 | AVR16DD32 |
42 | AVR32DD14 | AVR32DD20 | AVR32DD28 | AVR32DD32 |
43 | AVR64DD14 | AVR64DD20 | AVR64DD28 | AVR64DD32 |
schade, der Atmega3209 ist als DIL natürlich wieder kaum zu bekommen bei den üblichen Bekannten. Puh ok, den 4809 findet man, das ist dann auch ok:-)
Hallo, nur noch zur Info. Den 480x und AVRxDB kenne ich schon genauer. Die TCB Timer vom ATmega haben leider kein Overflow Flag. Man kann also keinen Zähler programmieren größer 16Bit. Die DB Serie (wahrscheinlich auch andere) hat natürlich das OVF und man kann sie zudem in Hardware zu 32Bit kaskadieren. Alle Messmodi des TCB sind damit in 32Bit möglich auch wenn das Datenblatt in Hardware nur von einer Möglichkeit schreibt. Wenn du das nicht brauchst kannste locker zur megaAVR0 Serie greifen. Ich finde die Dinger jedenfalls cool.
Peter K. schrieb: > schade, der Atmega3209 ist als DIL natürlich wieder kaum zu bekommen > bei den üblichen Bekannten. > Puh ok, den 4809 findet man, das ist dann auch ok:-) Lernt es endlich! DIL ist tot. 5V ist tot.
Microchip verlängert das Sterben. https://www.microchip.com/content/dam/mchp/mrt-dam/ic-images/spdip/28-lead-m3x/AVR64EA28-M3X-Regular.jpg
Beitrag #7213090 wurde von einem Moderator gelöscht.
Ron T. schrieb im Beitrag #7213090: > Beides war, ist und bleibt ein 1A Vorteil. Nix einreden lassen, von wem > auch immer. Redest du vom Ozean und den Bäumen? Ja die hätte man niemals verlassen dürfen.
M. K. schrieb: > Cyblord -. schrieb: >> Lernt es endlich! >> DIL ist tot. >> 5V ist tot. > > Totgesagte leben länger ;) Als Zombie vielleicht. Es ist wie immer: Die abgehängten, wunderlichen, starrsinnigen Foren-Rentner werden für immer drauf hängen bleiben. Aber der Rest der Welt hat sich da längst weiterbewegt.
Beitrag #7213126 wurde von einem Moderator gelöscht.
Ron T. schrieb im Beitrag #7213126: > Es soll aber Leute geben die sich bestimmter > Optionen freiwillig beraubt haben. Immer weniger Optionen haben die arme Schweine die heute immer noch auf DIL und 5V angewiesen sind. Da bekommt man fast nichts modernes mehr her.
Cyblord -. schrieb: >> Cyblord -. schrieb: >>> Lernt es endlich! >>> DIL ist tot. >>> 5V ist tot. ... > der Rest der Welt hat sich da längst weiterbewegt. Klar. Der kauft die µC in einer SMD-Bauform und klatscht sie auf ein Breakout-Board mit Pinheader, damit sie wieder ins Breadboard passen. Toller Fortschritt.
Beitrag #7213143 wurde von einem Moderator gelöscht.
Axel S. schrieb: > Klar. Der kauft die µC in einer SMD-Bauform und klatscht sie auf ein > Breakout-Board mit Pinheader, damit sie wieder ins Breadboard passen. > > Toller Fortschritt. Klar geht das, wenn man mal etwas auf dem Breadboard ausprobieren will. Aber das macht man halt nur genau ein mal pro Baustein und kann den danach immer wieder dafür nutzen. Und wenn man dann zufrieden ist, kann man genau diesen Baustein auf eine fertige Platine bestücken LASSEN. Dann hat man am Ende ein kompaktes und sauberes Design und kann alle modernen Bausteine nutzen. Und kann mit einem Klick mehr davon bestellen. Was hat der DIL Spast am Ende? Ein riesiges hässliches Lochraster. Nicht reproduzierbar und fehleranfällig. Und mit altem Kram bestückt.
:
Bearbeitet durch User
Cyblord -. schrieb: > Lernt es endlich! > DIL ist tot. > 5V ist tot. Was soll das werden? Übrigens, dass weißt du sicherlich nicht, man kann die Teile auch mit 3,3V betreiben. Bevor jetzt kommt "aber max. Takt" und solcher Quatsch, die laufen auch offiziell mit 3V auf maximalen Takt. Sind also universell verwendbar.
Beitrag #7213207 wurde von einem Moderator gelöscht.
Beitrag #7213211 wurde von einem Moderator gelöscht.
Beitrag #7213219 wurde von einem Moderator gelöscht.
Beitrag #7213223 wurde von einem Moderator gelöscht.
Beitrag #7213229 wurde von einem Moderator gelöscht.
Cyblord -. schrieb im Beitrag #7213223: > Wie mir dieser Wichser auf den Sack geht.. schrieb im Beitrag #7213219: >> nimmt er natürlich DIL-Schaltkreise, so lange sie erhältlich >> sind. > > Nimmt er nicht. Weil die tot sind. Tote Pferde sind auch erhältlich. > Will aber fast niemand mehr drauf reiten. Nur die Wunderlichen > vielleicht noch. Du widersprichst dir doch selbst. DIL/DIP ist erhältlich, die Bauform wurde extra noch rausgebracht also kann sie nicht tot sein. Was nicht tot ist kann man kaufen bzw. in deinem Sprachgebrauch reiten. Klar ist doch das kein Entwickler im Beruf DIP in Serie verbaut, aber zum schnellen testen auf dem Schreibtisch oder für den ersten Kontakt damit oder eben für Bastler ist das perfekt. Vielleicht verwechselst du Gebrauchsmuster testen mit späterer Serie. Du solltest allgemein etwas mehr Weitsicht zeigen. Übrigens, bevor du hier völlig deine Energie verschwendest. Wie weit bist du denn mit dem Projekt für Jörg avrdude auf Github zu portieren? Das Pferd kannste reiten.
:
Bearbeitet durch User
Veit D. schrieb: > Übrigens, bevor du hier völlig deine Energie verschwendest. Wie weit > bist du denn mit dem Projekt für Jörg avrdude auf Github zu portieren? Das ist eingestellt. Eine vertrauensvolle Zusammenarbeit ist nicht möglich, wenn dir der Gegenüber ständig deine Beiträge radikal löscht. Das ist aber Off-Topic. Und es ist keine Energieverschwendung auf das Offensichtliche hinzuweisen: DIL IST TOT.
:
Bearbeitet durch User
Beitrag #7213244 wurde von einem Moderator gelöscht.
Beitrag #7213247 wurde vom Autor gelöscht.
Ron T. schrieb im Beitrag #7213211: > Nix ist flexibler und billiger für den Bastler als Lochraster! Wenn der > Aufbau funktioniert kann man für Stückzahlen und Größenminimierung immer > noch eine Platine machen. Stichwort Größe: So ein (schmaler) DIL-AVR ist > als wechselbares System natürlich konkurrenzlos klein und billig. Alles, was Du hier geschrieben hast, ist vollkommen richtig. Aber: Bastler sind wirtschaftlich irrelevant. Ein Randphänomen. Wegen denen wird kein Baustein als DIL aufgelegt. In der richtigen Welt (sprich: in der Welt, in der mit richtiger Arbeit richtiges Geld verdient wird) vermeidet man TH-Bauteile soweit wie irgend möglich. 1. Die Bestückung und der automatisierte Lötprozess ist viel teurer, und zwar nicht um einige %, sondern um Faktoren >>2. 2. TH-Bauteile sind größer. Will man heutzutage eher nicht mehr. 3. TH-Bauteile haben eine höhere Induktivität. Das wird bei schnellen Signalen zu einem echten Problem. Und das gilt nicht nur für die Signale, sondern auch für die Stromversorgung. Im letzten Jahrtausend hat Fairchild 74F-Logikbausteine rausgebracht, bei denen die Stromversorgungspins nicht an den gegenüberliegenden Pins (Corner Pinning), sondern an den mittleren Pins (Center Pinning) lagen, weil hier die Zuleitungen kürzer waren. Inzwischen verzichtet man heute oft auf die Pins ganz (QFN, SON, BGA). 4. TH-Bauteile sind schlechter zu kühlen, weil sie nur die Pins haben, um Wärme abzuleiten. SMD-Bauteile haben großflächige Pads auf der Unterseite, um die Wärme an die Leiterplatte abzugeben. Ein Bereich, wo TH noch seine Berechtigung hat, ist Consumerelektronik und Netzteile. Hier hat man noch einseitige beschichtete Hartpapier-Leiterplatten, weil es billiger ist. Schau mal in Netzteile von Fernsehern, Monitoren, DVD-Playern etc rein - die sind oft so aufgebaut. Dafür gibts dann auch neue Bauteile. Ein anderer Bereich sind Bauteile, die mechanisch stabil sein müssen. Also Steckverbinder, große Elkos und Drosseln. Die macht man aus mechanischen Gründen als TH. Aber ansonsten ist es in der richtigen Welt (mit richtigem Geld) eben so, dass 5V-Systeme und TH-Bauteile in der Bedeutung seit den 90'er Jahren stetig abnehmen. Klar, es gibt sie noch, aber sie werden immer weniger eingesetzt, und es gibt immer weniger Neuentwicklungen. fchk
Das ist ja alles richtig, und Cyblord sei seine Überzeugung (die er wie eine Monstranz vor sich herträgt) ja gegönnt, nur - muss diese Diskussion alle zwei Wochen von neuem geführt werden, so wie 'C contra Assembler'? Es wurde eine ganz andere Frage gestellt, gleich die erste Antwort war erschöpfend - reicht das nicht?
S. Landolt schrieb: > Es wurde eine ganz andere Frage gestellt, gleich die erste Antwort war > erschöpfend - reicht das nicht? Sollte man meinen. Aber dann kam so ein DIL-Rentner und beschwerte sich dass es Zuwenig DIL gibt. Also welche Seite hatte die Diskussion darum nochmal genau angefangen? na?
:
Bearbeitet durch User
Und darauf reagieren Sie dann sofort reflexartig mit geradezu missionarischem Eifer? Lassen wir den Hobbyisten die bedrahteten Bauteile und die 5 Volt-Technik, solange dies erhältlich ist. Mit Ihren Tiraden überzeugen Sie keinen, der sich nicht schon längst durch die rapide schwindenden Lieferoptionen hat abschrecken lassen.
Beitrag #7213429 wurde von einem Moderator gelöscht.
Ron T. schrieb im Beitrag #7213429:
> 5V mag abnehmen so wie der Marktanteil der 8Bitter abnimmt.
Es ging ja um DIL und nicht um 8Bitter. 8Bitter in einem ordentlichen
Gehäuse kann man gut einsetzen. Auf Opas alter Eurokarte in DIL40 mit
angeschlossenem TTL Grab in 2022 wirds dann halt lächerlich. Auch
Bastler dürfen Ansprüche haben.
:
Bearbeitet durch User
Beitrag #7213447 wurde von einem Moderator gelöscht.
Ron T. schrieb im Beitrag #7213090:
> Beides war, ist und bleibt ein 1A Vorteil.
6V6 war auch einmal ein 1A Vorteil. Die Zeiten ändern sich.
Wolfgang schrieb: > Ron T. schrieb im Beitrag #7213090: >> Beides war, ist und bleibt ein 1A Vorteil. > > 6V6 war auch einmal ein 1A Vorteil. Die Zeiten ändern sich. Wie soll man auch bei diesen modernen 5V die alte Laternenbatterie vom Typ Varta Volkssturm aus Opas Wehrmachtsbeständen ordentlich als Stromversorgung einsetzen?
:
Bearbeitet durch User
Beitrag #7213502 wurde von einem Moderator gelöscht.
Beitrag #7213503 wurde von einem Moderator gelöscht.
Cyblord -. schrieb: > Die abgehängten, wunderlichen, starrsinnigen Foren-Rentner schließen ihre Mikrocontroller einfach direkt an Akkus an während die 3,3V Fraktion oft nach Sepic Wandlern mit phantastischer Ruhestromaufnahme sucht. Und jetzt, wo Logic Level MOSFET für 3,3 Volt Mangelware geworden sind ist die 5V Fraktion gleich doppelt im Vorteil. Mit Starrsinn hat das nichts zu tun. Ich nutze beide Arten von Mikrocontrollern gerne. Manchmal sind die alten nicht nur einfacher sondern auch besser.
Peter K. schrieb:
> Nur die AVR DA Serie oder gibt es auch welche aus der Atmega Serie?
Falls da ein Missverständnis bestehen sollte, als Klarstellung, und in
Ergänzung zu Veit D.: Der Unterschied zwischen einem älteren und einem
neuen ('megaAVR® 0-series') ATmega ist wesentlich größer als der
zwischen Letzterem und einem AVRnDx - die Bezeichnungen täuschen. Ein
genauerer Blick auf die 'AVR® Dx Family' könnte sich lohnen.
Cyblord -. schrieb: > Was hat der DIL Spast am Ende? Ein riesiges hässliches Lochraster. Denkst du wirklich, dass ich für eine Fertige Platine nicht auch SMD Bauformen wechsel kann? Wer hinder mich denn daran, etwa das Steckbrett?
Frank K. schrieb: > Aber: Bastler sind wirtschaftlich irrelevant. Ein Randphänomen. Wegen > denen wird kein Baustein als DIL aufgelegt. Warum werden dann immer noch einige neue Modelle in diesem Format auf den Markt gebracht? Wenn Bastler irrelevant sind, dann ist das Format offenbar für die Industrie relevant.
Cyblord -. schrieb: > Wie soll man auch bei diesen modernen 5V die alte Laternenbatterie vom > Typ Varta Volkssturm aus Opas Wehrmachtsbeständen ordentlich als > Stromversorgung einsetzen? Mit einer Diode in Reihe, die zugleich gegen Verpolung schützt.
Typisch Stefan. Keine Ahnung vom Thema, zu spät dazu kommen, aber direkt drei Beiträge raushauen die alle Unsinn sind.
Beitrag #7213764 wurde von einem Moderator gelöscht.
Beitrag #7213778 wurde von einem Moderator gelöscht.
Beitrag #7213821 wurde von einem Moderator gelöscht.
Das bringe ich doch mal den "Arduino NANO Every" ins Spiel. Achtung: Der arbeitet mit 5V und das ist ja tot, hat der Cyberlord gesagt. Achja, meine Schaltungen sind immer bei 0V tot. Glaubt mir, das geht dann Garnichts. Er hat einen ATMega4809 an Board. Zum gluck in SMD, denn DIP ist ja tot, hat der Cyberlord gesagt. Unglücklicherweise ist der UDPI nicht direkt im Zugriff. Überraschenderweise arbeitet der Arduino hier aber nicht mit einen Bootloader. Der USB auf Seriell Wandler geht direkt auf den UDPI. Vieleicht interessant um die neuen AVRs kennen zu lernen.
Beitrag #7215659 wurde von einem Moderator gelöscht.
Cyblord -. schrieb: > Typisch Stefan. Keine Ahnung vom Thema, zu spät dazu kommen, aber direkt > drei Beiträge raushauen die alle Unsinn sind. Das ist mir zu unkonkret. Schau mal nach unten, da wo der Boden ist, da ist auch die Ebene der Fakten. Vielleicht findest du einen Weg, deinen Höhenflug zu beenden.
Noch mal!! Wieso wird der cyklops nicht gesperrt!!!?!?! HAtte nach wenigen Beiträgen keine Lust mehr hier weiter zu lseen weil es nur "Wichser, Spast" etc pp geht. Also bitte Moderatoren, schmeißt diesen Idioten endlich au dem Forum doer sperrt ihn für mehrere Tage wenn er wieder seine geistigen Aussetzer hat!!! bis er sich wieder beruhigt hat. Solche geistigen Tiefflieger die der Cyblord sind für den miesen Ruf dieses Forum verantwortlich!! Schlussendlich dreht es sich in diesem Threat nur noch um diesen Sozial minderbemittelten Menschen. Wieso wurden diese dummen Beiträge nicht gelöscht die hier nur für Stimmung sorgen? Was bitte sehr ist das für eine Moderation?!?!
Peter K. schrieb: > Also bitte Moderatoren, schmeißt diesen Idioten endlich au dem Forum > doer sperrt ihn für mehrere Tage wenn er wieder seine geistigen > Aussetzer hat!!! Du verwechselst da was. > Was bitte sehr ist das für eine Moderation?!?! Du näherst Dich dem eigentlichen Problem.
Uwe K. schrieb: > Überraschenderweise arbeitet der Arduino hier aber nicht mit einen > Bootloader. Doch, das tut es. Der verwendete serielle Bootloader ist halt nur in Hardware gegossen und standardmäßig schon vorhanden. Das haben die Arduino-Entwickler erkannt und sinnvollerweise auch genutzt.
Peter K. schrieb: > HAtte nach wenigen Beiträgen keine Lust mehr hier weiter zu lseen weil > es nur "Wichser, Spast" etc pp geht. Es kann natürlich nicht jeder so kompetent und gleichzeitig so freundlich wie du sein. Das kann uns allen nur als Vorbild dienen.
Beitrag #7223024 wurde von einem Moderator gelöscht.
c-hater schrieb: > Uwe K. schrieb: > >> Überraschenderweise arbeitet der Arduino hier aber nicht mit einen >> Bootloader. > > Doch, das tut es. Der verwendete serielle Bootloader ist halt nur in > Hardware gegossen und standardmäßig schon vorhanden. Das haben die > Arduino-Entwickler erkannt und sinnvollerweise auch genutzt. Sehr verwirrende und falsche Aussage. Der Arduino Nano Every hat keinen Bootloader. Der ATMega4809 wird von Natur aus mit UPDI programmiert. Eine andere Möglichkeit gibt es nicht. Es wird definitiv kein Bootloader in den ATMega geladen. Man kann ihn jederzeit Flashen ohne ihn Booten (reset) zu müssen. Es existiert nicht mal ein RESET Pin. Es ist definitiv kein Bootloader.
Uwe K. schrieb: > Der ATMega4809 wird von Natur aus mit UPDI programmiert Eben, das ist ein serieller Bootloader.
Stefan F. schrieb: > Uwe K. schrieb: >> Der ATMega4809 wird von Natur aus mit UPDI programmiert > > Eben, das ist ein serieller Bootloader. Kein Bootloader. Ein BOOT ist zum LOAD nicht notwendig. Der ISP via SPI auf einem ATMega328P oder ATTiny85 ist doch auch kein Bootloader. Es ist ein Programmier-Interface.
Cyblord -. schrieb: > Es kann natürlich nicht jeder so kompetent und gleichzeitig so > freundlich wie du sein. Das kann uns allen nur als Vorbild dienen. DIR kann JEDER Andere als Vorbild dienen, denn jeder Andere hat ein besseres Benehmen als Du.
Stefan F. schrieb: > Uwe K. schrieb: > >> Der ATMega4809 wird von Natur aus mit UPDI programmiert > > Eben, das ist ein serieller Bootloader. Einfach nur erschreckend soviel Unwissen. Mit sowas im Background diskutieren die Leute dann 🙈
> Eben, das ist ein serieller Bootloader.
Romloader wäre hier der korrekte Begriff.
:
Bearbeitet durch User
Uwe K. schrieb: > Der ISP via SPI > auf einem ATMega328P oder ATTiny85 ist doch auch kein Bootloader Alle ausser Atmel: Programmier-Interface via SPI, SWD, C2 = ICP Bootloader über UART, USB, CAN, Ethernet = ISP
Cyblord -. schrieb: >> Eben, das ist ein serieller Bootloader. > > Romloader wäre hier der korrekte Begriff. Nicht wirklich. ROM-Loader sind welche, deren Programm ganz normal auf der MCU abgearbeitet wird, deren Programm aber in einem ROM liegt. Das ist hier aber nicht der Fall. Das Ding ist eine in Hardware implementierte State-Machine und wird nicht von der MCU abgearbeitet und es gibt kein im ROM liegendes Programm dafür. Nichtsdestotrotz ist es ein serieller Bootloader, denn man kann ein Programm darüber laden und die verwendete Schnittstelle ist eine Halbduplex-UART.
c-hater schrieb: > Nichtsdestotrotz ist es ein serieller Bootloader, Hat eine SD-Karte dann auch einen Bootloader?
c-hater schrieb: > Nicht wirklich. ROM-Loader sind welche, deren Programm ganz normal auf > der MCU abgearbeitet wird, deren Programm aber in einem ROM liegt. Das ist vielleicht deine persönliche Definition. Ich sehe das anders. Ein Romloader ist jede Logik, die in Hardware gegossen, das Programmieren eines Bausteins erlaubt. Deine Variante: Programm im ROM und dann Ausführung durch den MCU, wirst du in diesem Kontext so gut wie nirgends vorfinden.
:
Bearbeitet durch User
c-hater schrieb: > Uwe K. schrieb: > >> Überraschenderweise arbeitet der Arduino hier aber nicht mit einen >> Bootloader. > > Doch, das tut es. Der verwendete serielle Bootloader ist halt nur in > Hardware gegossen und standardmäßig schon vorhanden. Das haben die > Arduino-Entwickler erkannt und sinnvollerweise auch genutzt. Ich bin nicht sicher, ob ich den UPDI-"Prozessor" wirklich als Bootloader im engeren Sinn bezeichnen würde. Aber es gibt ja eine Schnittmege. Ein "klassischer" Bootloader ist UPDI nicht, weil UPDI nicht nur beim Booten arbeitet, sondern immer aktiv ist / bleibt. Der UPDI-Prozessor gibt ggf. einen Reset an den Reset-Controller, der dann tyypischerwiese ein Reset / Boot auslöst. Andererseits löst ein Reset per HW / SW ja nicht (zwingend) ein UPDI-Flash aus, wie bei einem Bootloader (sofern ein Image angeliefert wird). UPDI ist auch fest als eigener Prozessor eingebaut, während ein Bootloader ja User-Code ist. UPDI ist sehr leistungsfähig und den meisten Bootloadern überlegen, hat jedoch m.E. einen Schwachpunkt. Man kann andere Komponenten nicht auf den UPDI-Pin mappen, etwa TX eines USARTs. An dieser Stelle muss man in der HW Hand anlegen und TX(n) und UPDI bei P-Channel MosFet schaltbar verbinden. Dann braucht man von außen auch nur ein (half-duplex) serielle Verbindung.
Beitrag #7224027 wurde von einem Moderator gelöscht.
Cyblord -. schrieb: > Das ist vielleicht deine persönliche Definition. Wohl nicht nur meine... > Ich sehe das anders. > Ein Romloader ist jede Logik, die in Hardware gegossen, das > Programmieren eines Bausteins erlaubt. Davon, dass irgendwas in Hardware gegossen ist, wird es sicher noch nicht zum ROM. Dann wäre auch jeder Zähler, jedes Gatter, jede MCU usw. ein ROM. Das ist doch offensichtlicher Unsinn. > Deine Variante: Programm im ROM und dann Ausführung durch den MCU, wirst > du in diesem Kontext so gut wie nirgends vorfinden. Tatsächlich? Also zwei Gegenbeispiele fallen mir auf Anhieb ein (weil ich aktuell damit zu tun habe): RP2040 und TMS320F28xxx. Aber wenn mich nicht alles täuscht, funktionieren auch sehr viele STM32-Bootloader genau nach diesem Prinzip: Bootloadercode im ROM, wird abgearbeitet vom ganz normalen Core. Eine Liste spare ich mir hier und verweise statt dessen auf: https://www.st.com/resource/en/application_note/cd00167594-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf
Wilhelm M. schrieb: > Ich bin nicht sicher, ob ich den UPDI-"Prozessor" wirklich als > Bootloader im engeren Sinn bezeichnen würde. Aber es gibt ja eine > Schnittmege. Genau. UPDI kann viel mehr als ein üblicher serieller AVR8-Bootloader, aber mindestens auch das, was der kann. > Ein "klassischer" Bootloader ist UPDI nicht, weil UPDI nicht nur beim > Booten arbeitet, sondern immer aktiv ist / bleibt. Nein. Ist nicht mehr aktiv, wenn die Gegenstelle des Bootloaders ordentlich die UPDI-Verbindung logisch trennt, nachdem sie hochgeladen hat, was sie hochladen wollte. > UPDI ist auch fest als eigener Prozessor eingebaut, während ein > Bootloader ja User-Code ist. Wer hat festgelegt, dass ein Bootloader Usercode sein muss? Mir scheint eher, dass Usercode als Bootloader nur eine Krücke ist, die man benutzt, wenn der Hersteller der MCU keinen Bootloader von Hause aus eingebaut hat.
Beitrag #7224152 wurde vom Autor gelöscht.
c-hater schrieb: >> Ein "klassischer" Bootloader ist UPDI nicht, weil UPDI nicht nur beim >> Booten arbeitet, sondern immer aktiv ist / bleibt. > > Nein. Ist nicht mehr aktiv, wenn die Gegenstelle des Bootloaders > ordentlich die UPDI-Verbindung logisch trennt, nachdem sie hochgeladen > hat, was sie hochladen wollte. Doch schon: sobald ein "break"-charcter gesendet wird, ist UPDI wieder aktiv. Das ist ja auch normal so, wenn man der UPDI-geflashed hat, dann läuft der User-Code und dann kann man ja auch nochmal flashen. Also bleibt UPDI aktiv. >> UPDI ist auch fest als eigener Prozessor eingebaut, während ein >> Bootloader ja User-Code ist. > > Wer hat festgelegt, dass ein Bootloader Usercode sein muss? Das war jetzt meine Annahme für die alten AVR (davon reden wir ja). Woanders ist das anders, etwa DFU bei STM. > Mir scheint > eher, dass Usercode als Bootloader nur eine Krücke ist, die man benutzt, > wenn der Hersteller der MCU keinen Bootloader von Hause aus eingebaut > hat. Ja, so sehe ich das auch ... (trotzdem bleiben die Nachteile des UPDI: s.o.)
:
Bearbeitet durch User
Wilhelm M. schrieb: > Doch schon: sobald ein "break"-charcter gesendet wird, ist UPDI wieder > aktiv. Ja klar, dann wird UPDI wieder aktiv. Jedenfalls beim AVR128DBxxx, um den es hier ja geht, reicht das. Dann sendet man halt nur einen Break-Character, wenn man bootloaden will. Wo ist jetzt der prinzipielle Unterschied zwischen "drücke Reset-Taste zum Bootloaden" und "sende Break zum Bootloaden"? Von allein drückt sich keine Reset-Taste und von allein sendet sich genausowenig ein Break. Also ich vermag da jetzt nicht wirklich einen signifikanten Unterschied erkennen.
c-hater schrieb: > Wilhelm M. schrieb: > Von allein drückt sich keine Reset-Taste und von allein sendet sich > genausowenig ein Break. Also ich vermag da jetzt nicht wirklich einen > signifikanten Unterschied erkennen. Naja, der Unterschied ergibt sich schon aus dem Wort "Bootloader": der ist eben immer beim Booten aktiv (und wartet innerhalb eines timeouts auf eine magische Sequenz) und danach geht die Kontrolle an den UserCode. Wenn der UserCode läuft ist der Bootloader typischerweise ohne Reset nicht mehr in Aktion zu versetzen (ich beziehe mich jetzt ausdrücklich nur auf die gängigen AVR Bootloader). UPDI ist immer bereit, aktiviert zu werden (Stichwort: break), egal was der UserCode macht. Und: UPDI läuft deswegen nicht beim Reset direkt an.
Wilhelm M. schrieb: > (ich beziehe mich jetzt > ausdrücklich nur auf die gängigen AVR Bootloader). Genau das ist dein Fehler: Viel zu kleiner Fokus, um eine Begriffsdefinition zu wagen... > UPDI ist immer bereit, aktiviert zu werden Genau wie die typischen AVR8-Bootloader. Nur der "Aktivator" ist halt verschieden. Reset-Taster hier, Break da... Einen prinzipiellen Unterschied gibt es nicht, das ist der Punkt.
Ich bleibe dabei: Der Arduino Nano Every hat keinen Bootloader. Für die Korinthenkacker: Der Arduino Nano Every hat keinen Arduino spezifischen Bootloader der geladen werden muss, wie es beim Arduino Uno der Fall ist, um ihn mit der Arduino Entwicklungsumgebung ansprechen zu können.
Uwe K. schrieb: > Ich bleibe dabei: > > Der Arduino Nano Every hat keinen Bootloader. Doch, hat er. > Für die Korinthenkacker: > > Der Arduino Nano Every hat keinen Arduino spezifischen Bootloader der > geladen werden muss Das passt schon eher... Und der Grund, dass keiner extra geladen werden muss ist simpel: ES IST SCHON EINER AB WERK VORHANDEN. Capisce? Übrigens trifft das in der Arduino-Welt durchaus auf viele Targets zu. Genau genommen sogar auf fast alles (außer eben den Classic-AVR8)...
Uwe K. schrieb: > Ich bleibe dabei: > > Der Arduino Nano Every hat keinen Bootloader. Davon wird es nicht richtiger: auf dem Board ist ein SAM-D11 als USB/serial-bridge für UPDI.
Wilhelm M. schrieb: > Uwe K. schrieb: >> Ich bleibe dabei: >> >> Der Arduino Nano Every hat keinen Bootloader. > > Davon wird es nicht richtiger: auf dem Board ist ein SAM-D11 als > USB/serial-bridge für UPDI. Die Bridge ist nur dafür da, die virtuelle USB-UART auf eine reale UART zu "übersetzen". Mit dem Bootloader und seiner Funktionalität hat das eigentlich rein garnichts zu schaffen.
c-hater schrieb: > Wilhelm M. schrieb: >> Uwe K. schrieb: >>> Ich bleibe dabei: >>> >>> Der Arduino Nano Every hat keinen Bootloader. >> >> Davon wird es nicht richtiger: auf dem Board ist ein SAM-D11 als >> USB/serial-bridge für UPDI. > > Die Bridge ist nur dafür da, die virtuelle USB-UART auf eine reale UART > zu "übersetzen". Mit dem Bootloader und seiner Funktionalität hat das > eigentlich rein garnichts zu schaffen. Sag ich doch: der SAM-D11 ersetzt das, wofür man sonst evtl. einen CP2102 nehmen würde.
Wilhelm M. schrieb: > der SAM-D11 ersetzt das, wofür man sonst evtl. einen > CP2102 nehmen würde. Genau. Oder irgendeinen FTDI oder einen CH340. Reine Bridges, die nur von UART-Kommunikation eine Ahnung haben und diese (mehr oder weniger gut) umsetzen können. Die wissen rein garnix von UPDI oder irgendeinem anderen Bootloader. Und sie brauchen darüber auch nichts zu wissen, um funktionieren zu können.
c-hater schrieb: > Genau wie die typischen AVR8-Bootloader. Nur der "Aktivator" ist halt > verschieden. Reset-Taster hier, Break da... > > Einen prinzipiellen Unterschied gibt es nicht, das ist der Punkt. Doch den gibt es. Ein Bootloader ist nur beim Bootvorgang aktiv, nach einem Reset. Danach liegt der Code brach in der Ecke. Das ist beim UDPI nicht der Fall. Ebenso wenig wie beim Seriellen Programmieren per SPI oder Paralleler Programmierung mit HV. Ein EPROM hat doch auch keinen Bootloader. Die Funktion zum Programmieren wird nach einen Reset nicht ausgeführt. Ein Bootloader wird immer nach einem Reset ausgeführt, egal ob man es benutzt oder nicht. Weil er beim Booten aktiv ist und auch nur dann. Und wenn die Frage aufkommt "Wo kann ich den Arduino Nano Every Bootloader downloaden?" ist die einzig mögliche Antwort: Der Arduino Nano Every hat keinen Bootloader. Da gibt es nichts, was man laden muss. Der ATMega4809 hat keinen integrierten Bootloader.
Uwe K. schrieb: > Ein Bootloader wird immer nach einem Reset ausgeführt, egal ob man es > benutzt oder nicht. Das ist NUR das, was sich effektiv aus der Notlösung ergibt, auf die man angewiesen ist, wenn es keinen eingebauten Bootloader gibt und man Usercode als solchen implantieren muss. Sprich: Du verallgemeinerst hier unzulässig deinen offensichtlich sehr schmalen Kenntnishorizont...
Uwe K. schrieb: > Ein Bootloader ist nur beim Bootvorgang aktiv, nach einem Reset. Danach > liegt der Code brach in der Ecke. Ein Bootloader kann auch einfach aus der Applikation angesprungen werden. Diese Definition taugt nicht.
Wilhelm M. schrieb: > hat jedoch m.E. einen Schwachpunkt. Man kann andere Komponenten nicht > auf den UPDI-Pin mappen, Das ist erstens eine Frage des Controllers denn bei einigen lässt sich der Pin durchaus zumindest als GPIO umwidmen. Das finde ich aber zweitens selber als Schwachpunkt da man sich so versehentlich der Programmierfähigkeit berauben kann. Nein, das ist schon ganz gut so daß der einzige sichere Programmier-Zugang, zumindest bei Typen mit ausreichend vielen Pins, fest fixiert ist!
c-hater schrieb: > Einen prinzipiellen Unterschied gibt es nicht, das ist der Punkt. Selbstverständlich gibt es den. Via UPDI lässt sich unabhängig jeder (fehlerhaften) Programmierung aus jedem Zustand heraus programmieren und debuggen. Mit einem einzigen Pin, was UPDI auch jedem ARM-Programmierinterface gegenüber überlegen macht.
Schau mal hier unter 2.4 Memory Map wo der Bootloader üblicherweise ist: https://www.silabs.com/documents/public/reference-manuals/efm8bb1-rm.pdf
Wir sind noch beim AVR ATMega4809 der ab Werk keinen Bootloader hat? Der STM32 und EFM8 scheint einen Bootloader ab Werk zu haben. Der ATMega4809 aber nicht.
Jan V. schrieb: > Wilhelm M. schrieb: >> hat jedoch m.E. einen Schwachpunkt. Man kann andere Komponenten nicht >> auf den UPDI-Pin mappen, > > Das ist erstens eine Frage des Controllers denn bei einigen lässt sich > der Pin durchaus zumindest als GPIO umwidmen. Wenn Du oben meinen ganzen Satz zitiert hättest, wäre klar, dass ich nicht von einem GPIO sondern einem TX eines der USARTs spreche. > Das finde ich aber > zweitens selber als Schwachpunkt da man sich so versehentlich der > Programmierfähigkeit berauben kann. Nein, das ist schon ganz gut so daß > der einzige sichere Programmier-Zugang, zumindest bei Typen mit > ausreichend vielen Pins, fest fixiert ist! Was ich hier meine ergibt sich doch aus den Anforderungen: der UPDI-Pin behält seine UPDI-Funktion und man legt zusätzlich ein TX darauf. Dann könnte man zusätzlich ein zu UPDI disjunktes Protokoll darüber laufen lassen.
Uwe K. schrieb: > Wir sind noch beim AVR ATMega4809 der ab Werk keinen Bootloader hat? > > Der STM32 und EFM8 scheint einen Bootloader ab Werk zu haben. > > Der ATMega4809 aber nicht. STM32 hat DFU, der megaavr-0/da/db/dd/tiny-1/tiny-2 haben UPDI. Was ist Deiner Meinung nach der prinzipielle Unterschied zwischen DFU und UPDI?
Oft will man aber nicht, daß Hinz und Kunz einfach an den Geräten rumbasteln. Dann braucht man einen Custom-Bootloader mit Verschlüsselung und Authentifizierung. Auch sollte ein Update möglich sein, ohne Eingriff in das Gerät, z.B. über Ethernet oder WLAN. Und für zuverlässige und sicherheitskritische Anwendungen ist es ein absolutes No-Go, wenn mit einem Break auf einem externen Anschluß das Gerät versagt.
Wilhelm M. schrieb: > Wenn Du oben meinen ganzen Satz zitiert hättest, wäre klar, dass ich > nicht von einem GPIO sondern einem TX eines der USARTs spreche. Klar wär es generell wünschenswert beliebige Funktionen auf beliebige Pins legen zu können. Da macht UPDI keine Ausnahme- vorausgesetzt, die Funktion ließe sich wirklich "drüberlegen". Es ist nicht der Fall und deshalb kein Beinbruch, sich vorab über die benötigte Pinzahl so wie über die benötigten Funktionen schlau zu machen. Wilhelm M. schrieb: > Was ist Deiner Meinung nach der prinzipielle Unterschied zwischen DFU > und UPDI? Was ist Deiner Meinung nach der Sinn solcher haarspalterischen Diskussion um des Kaisers Bart? Peter D. schrieb: > Oft will man aber nicht, daß Hinz und Kunz einfach an den Geräten > rumbasteln. Dann braucht man einen Custom-Bootloader mit Verschlüsselung > und Authentifizierung. Dafür steht nach wie vor bei vielen AVRs eine Bootcode Section zur Verfügung. Also nicht Entweder Oder sondern Sowohl als Auch. Peter D. schrieb: > Und für zuverlässige und sicherheitskritische Anwendungen ist es ein > absolutes No-Go, wenn mit einem Break auf einem externen Anschluß das > Gerät versagt. Dann führt man den Pin nicht heraus, ganz einfach. Und Geräte-Versagen an sich lässt sich glaub ich bei jedem Controller-Typen herbeiführen. Ansonsten steht hier wie üblich Einfachheit kontra Sicherheit. Nur braucht die Sicherheit längst nicht jede Anwendung. Ein "Read and write lock" steht übrigens auch noch zur Verfügung.
:
Bearbeitet durch User
Jan V. schrieb: > Wilhelm M. schrieb: >> Was ist Deiner Meinung nach der prinzipielle Unterschied zwischen DFU >> und UPDI? > > Was ist Deiner Meinung nach der Sinn solcher haarspalterischen > Diskussion um des Kaisers Bart? Das musst Du den Uwe fragen, der immer noch behauptet, UPDI seit kein Bootloader. Ich habe ihm eine Brücke gebaut, indem ich vom Bootloader "im engeren" Sinne sprach. Aber er will da wohl nicht drüber. Ist mir aber auch egal. Weil der Uwe offensichtlich DFU und UPDI als unterschiedliche Dinge ansieht, sollte er das auch mal erklären.
Wilhelm M. schrieb: > der immer noch behauptet, UPDI seit kein > Bootloader. UPDI ist wie JTAG und DebugWire sehr viel mehr als ein "Bootloader". Kann man via DFU debuggen?
DerLetzteHugo schrieb: > Kann man via DFU debuggen? Das würde ich nicht als das Kriterium herannehmen. Über debugWIRE kann man debuggen, aber das ist in der Tat ein ROM-Monitor (solche Monitorpgrogramme waren vor Jahrzehnten sehr üblich in Mikrocomputern). Beim AVR sehe ich die wesentliche Unterscheidung darin, was das jeweilige Konzept "anfassen" darf: die Programmierschnittstelle (ISP, JTAG, PDI, TPI, UPDI) darf alles, sie darf auch Fuse- und Lockbits setzen. Alles, was dagegen in "normaler" Firmware läuft (und dazu zählen die dort üblichen Bootloader inklusive auch debugWIRE) darf dagegen Fuses und Lockbits nicht anfassen. Aber am Ende ist die Unterscheidung wohl eine reine Definitionsfrage.
Wilhelm M. schrieb: > Jan V. schrieb: >> Wilhelm M. schrieb: >>> Was ist Deiner Meinung nach der prinzipielle Unterschied zwischen DFU >>> und UPDI? >> >> Was ist Deiner Meinung nach der Sinn solcher haarspalterischen >> Diskussion um des Kaisers Bart? Es geht um das Verständnis, was UDPI bei ATTiny/ATMega eigentlich ist. Ob es interessant ist, kann jeder für sich selbst entscheiden. > Weil der Uwe offensichtlich DFU und UPDI als unterschiedliche Dinge > ansieht, sollte er das auch mal erklären. Erstmal danke für die konstruktive Antwort. Viel besser als: Cyblord -. schrieb: > Du verallgemeinerst hier unzulässig deinen offensichtlich sehr > schmalen Kenntnishorizont... Ich musste mich erst über den STM32 schlau machen, um zu wissen, was man unter DFU versteht. Der STM32 ist schon eine andere Hausnummer als ein ATMega, Respekt. Dann erkläre ich mal: Bei einem DFU handelt es sich um ein im ROM gespeicherten Bootloader. Man steuert definierte Boot-PINs an und startet dann den Prozessor. BOOT and LOAD. Sehr praktisch, keine Frage. Die LOAD-Funktionalität ist dann kurz nach dem BOOT vorhanden. Aber auch nur dann. Stört auch nicht. Der UPDI ist aber all gegenwärtig. Nicht nur beim Boot-Vorgang. Und es ist kein im ROM gespeichertes Programm (Bootloader). Der UPDI ist mit dem JTAG/SWD vergleichbar. Nicht aber mit dem DFU. JTAG/SWD ist doch für das Debuggen? Richtig, aber auch zum Programmieren. Das ist beim UPDI genauso. Er wird zum Debuggen und Programmieren verwendet. Ein JTAG kennt der ATMega4809 nicht. JTAG/SWD ist kein Bootloader, oder? Ist DFU und JTAG/SWD das gleiche? Ich denke nicht. Warum sollte man sonst diese Frage stellen: https://electronics.stackexchange.com/questions/281997/programming-stm32-jtag-swd-vs-bootloader Liege ich so falsch, das UPDI kein Bootloader ist?
JTAG ist ja eigentlich noch was ganz anderes, zumindest vom Ursprung her. Bei den AVRs, die das haben funktioniert es (im Gegensatz bspw. zu MSP430) auch in der ursprünglichen Form – die Programmier- und Debugschnittstelle wurde da nur "huckepack" drauf geflanscht. Habe vor Jahren auch mal zwei AVRs auf einem Board in einer Chain benutzt, auch das geht. Man muss halt dann dem Tool sagen, wie viele Devices und Bits davor und danach zu schieben sind.
Uwe K. schrieb: > Liege ich so falsch, das UPDI kein Bootloader ist? Wie gesagt: ich habe oben versucht eine Brücke zu bauen, dass UPDI kein Bootloader "im engeren Sinne" ist: also, ein Code / interne Maschine, die beim Booten aktiviert wird und dann UserCode flashen kann. UPDI wird nicht durch HW-Rest aktiviert, sondern löst selbst einen Reset aus. Zudem haben die Funktionen von UPDI und Bootloader eine Schnittmenge, sind aber nicht identisch: s.a. Thema Authentifiziertung oder Debuggen. Ich würde sagen: UPDI ist "auch" ein Bootloader. Umfasst also auch die Kernfunktion eines Bootloaders, nämlich UserCode zu laden. Bietet teilweise aber eben mehr bzw. weniger als andere Bootloader, je nachdem, mit was Du es vergleichst.
Wilhelm M. schrieb: > UPDI ist "auch" ein Bootloader. Wenn du das so weit ziehst, fällt in diese Bootloader-Definition allerdings dann so ziemlich alles rein, was den AVR programmieren kann. Oder wo willst du die Unterscheidung zwischen UPDI und PDI und dann ISP machen? (Mal von der unterschiedlichen Pinanzahl abgesehen, aber auch "echte" Bootloader sind nicht alle 1-wire.)
Jörg W. schrieb: > Bootloader-Definition Ich war eigentlich immer der Meinung daß es sich bei Bootloadern um ein Stück Software handelt. Das ist bei Programmier- Interfaces wie UPDI eben gerade nicht der Fall. Die einzige Gemeinsamkeit besteht doch darin, daß beide den Flashspeicher zu programmieren imstande sind. Und mit dieser Funktionalität erbringt ein Bootloader eben nur einen kleinen Teil des Leistungsumfangs eines Hardware- Programmierinterfaces wie UPDI. Als solches ist dieses zudem ständig und nicht nur beim Systemstart aktiv.
:
Bearbeitet durch User
Jan V. schrieb: > Das ist bei Programmier- Interfaces wie UPDI eben gerade nicht der Fall Bei ISP und JTAG bin ich mir da sehr sicher. Inwiefern das bei (U)PDI auch noch so ist, da müsste man die Implementierung sehen … da kann natürlich gut auch ein Mini-Controller mit ROM dahinter stecken. Der AVR-Core selbst wird es nicht sein, das wiederum wäre natürlich schon die Definition eines Bootloaders (schließlich hat sich Münchhausen an den Schnürsenkeln aus dem Sumpf gezogen oder sowas, also "etwas mit sich selbst"). Für den Anwender spielt es keine übermäßig große Rolle.
Braucht man für die UPDI Modelle eigentlich noch einen speziellen Debugger zum Debuggen oder geht ein ganz normaler USB/UART Adapter?
Stefan F. schrieb: > Braucht man für die UPDI Modelle eigentlich noch einen speziellen > Debugger zum Debuggen oder geht ein ganz normaler USB/UART Adapter? Zumindest zum Programmieren geht es auch damit. Debuggen bin ich mir gerade nicht so sicher.
Stefan F. schrieb: > Braucht man für die UPDI Modelle eigentlich noch einen speziellen > Debugger zum Debuggen oder geht ein ganz normaler USB/UART Adapter? Wie das speziell unter Linux laufen kann weiß ich nicht- im Windows Fall bieten sich die kleinen Curiosity nEDBG günstig an.
Jan V. schrieb: > bieten sich die kleinen Curiosity nEDBG günstig an. Das ist aber genau das Gegenteil, als wonach ich gefragt habe.
Beitrag #7225652 wurde vom Autor gelöscht.
Stefan F. schrieb: > Das ist aber genau das Gegenteil, als wonach ich gefragt habe. Auf jeden Fall kannst Du damit am USB Anschluß programmieren UND debuggen. Bessere, einfachere, günstigere Lösungen wüsste ich jetzt unter Windows keine.
Stefan F. schrieb: > Das ist aber genau das Gegenteil, als wonach ich gefragt habe. Wird halt wie immer bei AVR sein: die Schnittstelle selbst ist beschrieben, aber das Debugprotokoll nicht. Das unterscheidet ihn massiv vom Cortex-M.
Jörg W. schrieb: > Wird halt wie immer bei AVR sein: die Schnittstelle selbst ist > beschrieben, aber das Debugprotokoll nicht. Wär mir aber schnuppe Jörg! Möchte keinen Programmieradapter sondern Anwendungen entwickeln. Ist doch toll wenn es ausgereifte, bezahlbare Tools dafür gibt :)
Jan V. schrieb: > Wär mir aber schnuppe Jörg! Es war halt nur nicht Stefans Frage, sondern die bezog sich explizit darauf, ob es auch mit einem einfachen USB-UART-Adapter geht. Programmieren damit geht.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Programmieren damit geht. Magst Du noch verraten womit genau und unter welchem OS?
Jan V. schrieb: > Magst Du noch verraten womit genau und unter welchem OS? AVRDUDE (ab Version 7.0), pymcuprog (direkt von Microchip) Braucht letztlich außer einem USB-Seriell-Adapter (ohne RS232 Levelshifter natürlich) noch einen Widerstand zwischen RxD und TxD, mehr nicht. OS: alle, auf denen AVRDUDE oder Python/pyserial läuft, würde ich mal sagen.
Jörg W. schrieb: > ob es auch mit einem einfachen USB-UART-Adapter geht Damit macht Arduino den Bootloader drauf: https://github.com/SpenceKonde/DxCore#from-a-usb-serial-adapter-with-serialupdi-pyupdi-style---recommended
Ist mir eigentlich schnurz, ob man das Terminologiechaos gezielt steigern möchte, nur wüsste ich gerne von denen, die UPDI gerne als Bootloader bezeichnet wissen: Wie nennt Ihr dann das immer noch mögliche Programmstückchen in der mit UPDI auch immer noch möglichen Bootloader-Sektion? Das ist nicht rausgeflogen, nur weil Arduino es nicht nutzt.
Jan V. schrieb: > Auf jeden Fall kannst Du damit am USB Anschluß programmieren UND > debuggen. Klar. > Einfachere, günstigere Lösungen wüsste ich jetzt > unter Windows keine. Darauf zielte meine Frage ab. Hätte ja sein können dass auch dafür der USB/UART Adapter reicht, aber im Atmel Studio sah es nicht danach aus.
Steve van de Grens schrieb: > aber im Atmel Studio sah es nicht danach aus. Das allein wäre kein Kriterium. ;-) Bei denen wirst du auch keine Unterstützung dafür finden, mit einem FTDI-MPSSE-basierten Dongle einen Cortex-M zu debuggen, obwohl das nun wiederum machbar ist.
Euro schrieb: > Wie nennt Ihr dann das immer noch mögliche Programmstückchen in der mit > UPDI auch immer noch möglichen Bootloader-Sektion? Das ist nicht > rausgeflogen, nur weil Arduino es nicht nutzt. Bootloader
Steve van de Grens schrieb: > Darauf zielte meine Frage ab. Hätte ja sein können dass auch dafür der > USB/UART Adapter reicht, aber im Atmel Studio sah es nicht danach aus. Das war/ist Absicht. Wie will man sonst die völlig überteuerten AtmelICE3 verkaufen?
Euro schrieb: > Wie nennt Ihr dann das immer noch mögliche Programmstückchen in der mit > UPDI auch immer noch möglichen Bootloader-Sektion? Bootloader natürlich. Anders als beim seligen Highlander gilt bei Bootloadern nämlich nicht: "Es kann nur einen geben"...
c-hater schrieb: > Wie will man sonst die völlig überteuerten AtmelICE3 verkaufen? Die hat erst Microchip so völlig überteuert – mehr als das Doppelte des alten Atmel-Preises. Das nackte PCB war anfangs sogar billiger als der seinerzeit sehr beliebte AVR Dragon. (Btw., Atmel-ICE oder ATATMELICE. Das JTAGICE3 war etwas anderes und existierte nur sehr kurz, weil man danach den ARM-Support noch mit rein bringen wollte. Ein "AtmelICE3" gab es nie.) Aber: die preiswerte Alternative wurde oben schon genannt, und die hat nun wirklich nichts mehr mit überteuert zu tun.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > Die hat erst Microchip so völlig überteuert Das stimmt. > Das nackte PCB war anfangs sogar billiger als der > seinerzeit sehr beliebte AVR Dragon. Stimmt auch. > Ein "AtmelICE3" gab > es nie.) Und auch das. Aber: Ein vollwertiger AtmelICE (also mit Gehäuse und und insbesondere auch Kabelsatz) war von Anfang an ziemlich teuer. > Aber: die preiswerte Alternative wurde oben schon genannt, und die hat > nun wirklich nichts mehr mit überteuert zu tun. Kann halt nur nicht zum Debuggen genutzt werden, weil das UPDI-Protokoll nicht vollständig offengelegt ist, sondern nur die Teile davon, die zum reinen Programmieren nötig sind. Aber selbst zum reverse engineering, um den nichtöffentlichen Teil herauszufinden, braucht man halt erstmal so ein AtmelICE. Womit dann allerdings weitgehend die Motivation weg ist, sich weiter damit zu beschäftigen... Ich habe gerade noch so lange durchgehalten, bis ich sicher war, dass auch das gesamte Debug-Gedöhns vollständig im Rahmen dessen abläuft, was als UPDI-Protokoll beschrieben ist. Es fehlen in der Doku ein paar UPDI-Instruktionen und die acht beschriebenen sind nicht wirklich vollständig beschrieben. Letzteres hatte ich allerdings schon als nahezu sicher angenommen, bevor ich da selbst mitgelauscht habe. Viele "reserved" Bits sind bei OpCodes natürlich hochverdächtig...
c-hater schrieb: >> Aber: die preiswerte Alternative wurde oben schon genannt, und die hat >> nun wirklich nichts mehr mit überteuert zu tun. > > Kann halt nur nicht zum Debuggen genutzt werden Die preiswerte Alternative zum Debuggen ist es, den EDBG-Chip eines Devboards zu benutzen (Curiosity Nano zum Beispiel).
Jörg W. schrieb: > Die preiswerte Alternative zum Debuggen ist es, den EDBG-Chip eines > Devboards zu benutzen (Curiosity Nano zum Beispiel). Ach so, das meintest du. Ich dachte, es ginge um die wirklich günstige Hardware. Sprich: für Halbduplex modifizierter USB-Serial-Adapter.
c-hater schrieb: > Ach so, das meintest du. Scheint billig genug zu sein, als dass sich niemand ernsthaft ans reverse engineering des Debugprotokolls selbst gesetzt hat. Wobei letztlich ein MPSSE-fähiger FTDI-Adapter, wie man ihn bei den Cortex-M für SWD benutzen kann, auch nicht für 3 Euro zu haben ist. Die billigen chinesischen Clones dürften allesamt kein MPSSE unterstützen. Da ist der Preisunterschied zu den CNanos dann nicht mehr so groß.
Jörg W. schrieb: > Wobei letztlich ein MPSSE-fähiger FTDI-Adapter, wie man ihn bei den > Cortex-M für SWD benutzen kann, auch nicht für 3 Euro zu haben ist. Die ST-Link/V2 clones für SWD sind aber für unter 10 Euro zu haben. Eher so 6 Eur rum. Und sogar bunt. Wieso braucht man da MPSSE?
:
Bearbeitet durch User
Jörg W. schrieb: > Wobei letztlich ein MPSSE-fähiger FTDI-Adapter, wie man ihn bei den > Cortex-M für SWD benutzen kann, auch nicht für 3 Euro zu haben ist. PicoProbe statt FTDI?
Cyblord -. schrieb: > Die ST-Link/V2 clones für SWD sind aber für unter 10 Euro zu haben. OK, wobei ich die ST-Link immer als etwas hakelig in Erinnerung hatte. Hab die STM dann am Ende lieber mit dem Atmel-ICE debuggt. (Natürlich nur deshalb, weil ich das schon da hatte. Extra dafür eins zu kaufen wäre nicht sinnvoll gewesen.) Aber ja, bei SWD ist das ziemlich egal, was man nimmt. > Wieso braucht man da MPSSE? Bezog sich halt auf die FTDIs. Diejenigen mit MPSSE können von sich aus SWD sprechen.
:
Bearbeitet durch Moderator
Jörg W. schrieb: > OK, wobei ich die ST-Link immer als etwas hakelig in Erinnerung hatte. Nein die funktionieren top. Die kann man sogar mit der offiziellen ST Firmware updaten. Der einzige Nachteil ist die nicht verbundene HW Reset Leitung. Die kann man aber einfach nachziehen. Das lohnt sich immer mehr. Hat man bis vor kurzem noch ein ST-Link/V2 Original für 20-30 Euro bekommen, sind es jetzt 50-60 wenn überhaupt lieferbar. Die bunten Clones sind inzwischen sogar bei Digikey zu bekommen. Ich habe auch noch einen originalen ST-Link/V3MINI hier rumliegen. Trotzdem nutze ich lieber die Clones.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.