Moderne AVR (Nachfolger Atmega und Attiny)

[Achim S. (achims)]

Hallo
Wenn ich die Liste der neuen ICs von Atmega und Attiny bzw. Nachfolger 
des Herstellers so anschaue gibt es viele neue Sachen. Gerade die AVR0 
und AVR1 Serie (heissen die so?) sind ja sehr vielfältig. Es gibt auch 
die passenden kleinen Boards oder Arduino dazu. Für mich bleibt die 
Frage, für was soll am sich entscheiden? Welchen AVR, welche 
Programmierung oder doch den RP2040 oder doch lieber den RP2340 (noch 
mit Fehler?).
Wie ist eure Meinung dazu?

[Axel S. (a-za-z0-9)]

Achim S. schrieb:
> Für mich bleibt die Frage, für was soll am sich entscheiden?

Die Frage stellt sich doch immer. Du nimmst

* was genug Resourcen hat, dein Problem zu lösen

* wofür du die Werkzeuge schon hast (Toolchain, Programmer, etc)

* wofür du Hilfe bekommen kannst (vulgo: was die anderen nehmen)

* was dir persönlich gefällt

[Jörg W. (dl8dtl) (Moderator)]

Achim S. schrieb:
> Wie ist eure Meinung dazu?

Nimm das, was für deine Aufgabe, deinen Kenntnisstand und deine 
Werkzeuge am besten passt.

Wenn du irgendwas batteriebetriebenes machen willst, was sich die meiste 
Zeit schlafen legen soll, dann schau auf den Ruhestrom. Wenn du 
numbercrunching machen willst (FFT oder so), dann schau auf die 
Rechenleistung. Wenn du etwas direkt aus einer LiPo-Zelle betreiben 
willst, dann schau, dass du etwas findest, das am besten ohne weiteren 
Spannungsregler (der nur eigene Verluste und kompliziertere Schaltung 
mit sich bringt) an 4 V betreibbar ist. Wenn du viele GPIOs brauchst … 
die Liste ließe sich endlos fortsetzen.

Auf jeden Fall ist es gut für die Diversität, dass Microchip nach dem 
Auffressen von Atmel die AVRs wertgeschätzt und weiterentwickelt hat, 
statt sie zugunsten der PICs einfach einzustampfen.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Achim S. schrieb:
> Wie ist eure Meinung dazu?
Man nimmt den µC, der die Aufgabe effizient und zuverlässig löst. Zur 
Effizienz zählen Zeit, verfügbares Wissen und die durch die Toolchain 
und den Materialaufwand entstehenden Kosten.

Und wenn das Ganze als Hobby ausgeübt wird, kommen persönliche Vorlieben 
ganz weit nach vorne.

[Georg M. (g_m)]

Achim S. schrieb:
> Für mich bleibt die
> Frage, für was soll am sich entscheiden? Welchen AVR, welche
> Programmierung oder doch den RP2040 oder doch lieber den RP2340 (noch
> mit Fehler?).

Man kann Äpfel mit Birnen vergleichen, aber nicht 8-Bit-Architektur mit 
32-Bit-Architektur.

Für kleine einfache Steuerungen sind 8-Bit-Mikrocontroller ausreichend.
Wenn aber viel mit 32-Bit-Zahlen/Variablen gearbeitet wird, dann nimmt 
man selbstverständlich einen 32-Bit-Mikrocontroller.

[Ralph S. (jjflash)]

Jörg W. schrieb:
> Auf jeden Fall ist es gut für die Diversität, dass Microchip nach dem
> Auffressen von Atmel die AVRs wertgeschätzt und weiterentwickelt hat,
> statt sie zugunsten der PICs einfach einzustampfen.

Dafür Daumen hoch für Jörg und Atmel ... äh, ich meinte Microchip. 
Wirklich erwartet hatte ich nicht, dass AVR dann weiterentwickelt worden 
ist.

Flashen mittels UPDI ist gar nicht so verkehrt (benötigt halt anderen 
Programmer), aber die in Fleisch und Blut übergegangene Sache mit den 
Fuses, die jetzt komplett anderst sind, mußte man sich erst gewöhnen.

Lothar M. schrieb:
> Und wenn das Ganze als Hobby ausgeübt wird, kommen persönliche Vorlieben
> ganz weit nach vorne.

aber sowas von weit !

[Ben B. (Firma: Funkenflug Industries) (stromkraft)]

Falls Dich meine Meinung zu dem Thema interessiert, ich würde als diesen 
"Nachfolger" die ARM Cortex M0/M0+ oder M3 sehen, aber den AVRs noch 
lange nicht ihren Platz absprechen. Irgendwelche Lampensteuerungen mit 
etwas Zeitschalter und Logikfunktion braucht man immer und dafür reicht 
ein AVR in 100 Jahren noch.

Die ARM Cortex sind inzwischen so preiswert, daß sie in der Industrie 
gerne für fast alles eingesetzt werden. Bei Elektroscootern z.B. ist 
alles voll mit STM32Fxxx oder deren Klonen. Also wenn mir irgendwann der 
ATMega nicht mehr reicht, dann nehme ich ziemlich sicher sowas.

[Johannes F. (jofe)]

Achim S. schrieb:
> Welchen AVR,

Was AVR betrifft, empfehle ich den Umstieg auf die neueren Typen mit 
UPDI. Gründe: deutlich flexiblere und umfangreichere Peripherie sowie 
mehr Speicher, und das bei gleichzeitig wesentlich günstigerem Preis.

Der Umstiegsaufwand hält sich in Grenzen, mit dem Mplab Snap ist ein 
sehr günstiges Tool zum UPDI Flashen und Debuggen erhältlich. 
Programmiertechnisch gibt es zwar einige Änderungen und potentielle 
Fallstricke, die aber bekannt und schnell umgesetzt bzw. umgangen sind.

[Peter D. (peda)]

Achim S. schrieb:
> Wenn ich die Liste der neuen ICs von Atmega und Attiny bzw. Nachfolger
> des Herstellers so anschaue gibt es viele neue Sachen.

Die Frage ist doch erstmal, benötigst Du die neuen Bells & Whistles 
überhaupt?
Und willst Du dafür alle Deine bereits entwickelten Libs komplett 
umstellen?
Z.B. die Timer und andere Hardware sind ja deutlich unterschiedlich zu 
den klassischen ATMega/Tiny.

Will man einen Bootloader benutzen, ist das mit den neuen Typen deutlich 
komplizierter, da der Bootloader nun an 0x0000 stehen muß.
Der Bootloader muß daher wissen, wo die Applikation startet.
Und die Applikation muß wissen, daß überhaupt ein Bootloader verwendet 
wird und wo dieser endet.
Das alte Konzept mit Bootloader am Ende ist daher deutlich universeller.

[Frank K. (fchk)]

Der Grund, mich von AVR zu verabschieben, war die etwas spärliche 
Peripherie bei den alten Typen: nur ein UART, nur ein I2C, nur ein SPI, 
und das alles auf festen Pins. Hier konnten die PICs einfach mehr. Zudem 
gibts in der PIC-Welt PPS: Programmable Pin Select. Damit kann man 
Peripheriefunktionen sehr flexibel auf Portpins verteilen, die 
vorhandene Peripherie besser ausnutzen und das Layout vereinfachen.

Sehr praktisch ist auch das PSV-Feature (Program Space Visibility) bei 
PIC24 und dsPIC33. Hierbei wird ein Teil des Programm-Flashes in den 
Datenadressraum eingeblendet. Somit muss man nicht mehr mit tblrd 
((E)LPM in der AVR-Welt) arbeiten, sondern kann direkt drauf zugreifen. 
Die neuen AVRs haben ein ähnliches Feature.

Ein weiterer Fortschritt bei den neuen AVRs: voller Prozessortakt auch 
bei 3.3V. Microchip hat das ja schon länger so gemacht, dass der Core 
nur mit 1.8 oder 2.5V lief und nur der IO-Ring mit VCC betrieben wurde. 
Niedrigere Spannung → kleinere Transistoren → höhere Geschwindigkeit. 
Atmel war da gefühlt etwas schnarchnasig gewesen.

fchk

[Ben B. (Firma: Funkenflug Industries) (stromkraft)]

> nur ein UART
Zumindest der ATMega1284 hat davon schon mal zwei.

Mich stört an der Austattung solcher Controller immer der ADC. Der ist 
zwar eigentlich nicht verkehrt und liefert gute Ergebnisse, aber er 
könnte ruhig 16 Bit haben. Selbst wenn die unteren zwei Bit bei einem 
integrierten ADC evtl. durch den Core stark rauschen. 12 Bit sind auch 
schon wieder etwas wenig, wenn schon mehr als 10, dann bitte gleich 16 
Bit.

Der Takt könnte auch manchmal etwas höher sein. Manche AVRs können 
zumindest für die Timer eine PLL mit 64Mhz oder so, aber leider nicht 
alle.

[Jochen D. (joe_d1)]

Frank K. schrieb:
> Der Grund, mich von AVR zu verabschieben, war die etwas spärliche
> Peripherie bei den alten Typen: nur ein UART, nur ein I2C, nur ein SPI,
> und das alles auf festen Pins.

Das mit den festen Pins ist richtig, aber ich habe schon öfters privat 
den Atmega324PB verwendet, der hat 3xUSART, 2xI2C, 2xSPI ...

Bei den neuen AVR gefällt mir das manche Typen für USART wohl keinen 
externen Quarz mehr brauchen und fürs Programmieren mit UPDI nur noch 
einen Pin "verschwenden". Der ADC kann nun wohl 12Bit. Ein AVR16EB28 
liegt hier noch unbenutzt herum.

Auf der anderen Seite sieht es mit Tutorials, bewährten Bibliotheken und 
dergleichen super-mau aus. Da gibt es gefühlt gar nichts, maximal Links 
zu Microchip selbst. Kein Vergleich mit Atmega328PB oder Attiny2313 oder 
oder oder ...

[Johannes F. (jofe)]

Jochen D. schrieb:
> Bei den neuen AVR gefällt mir das manche Typen für USART wohl keinen
> externen Quarz mehr brauchen

Das ist richtig, bei AFAIK allen Typen mit UPDI ist der interne 
HF-Oszillator nun ausreichend genau für UART (zumindest bei 
Zimmertemperatur).

Jochen D. schrieb:
> Tutorials

Ich hatte mal überlegt, hier im Wiki ein Tutorial zu einem der neuen 
AVRs (vielleicht 128DB28 oder 64EA28) zu beginnen, nach dem Vorbild des 
alten ATmega8-Tutorials, also mit Assembler. Mache ich vielleicht mal, 
wenn ich Zeit habe.

[Georg M. (g_m)]

Jochen D. schrieb:
> Auf der anderen Seite sieht es mit Tutorials, bewährten Bibliotheken und
> dergleichen super-mau aus. Da gibt es gefühlt gar nichts, maximal Links
> zu Microchip selbst.

Ich finde die Datenblätter mit vielen Diagrammen schon ziemlich 
verständlich.

[Johann L. (gjlayde)]

Frank K. schrieb:
> Sehr praktisch ist auch das PSV-Feature (Program Space Visibility) bei
> PIC24 und dsPIC33. Hierbei wird ein Teil des Programm-Flashes in den
> Datenadressraum eingeblendet. Somit muss man nicht mehr mit tblrd
> ((E)LPM in der AVR-Welt) arbeiten, sondern kann direkt drauf zugreifen.
> Die neuen AVRs haben ein ähnliches Feature.

Linearen Adressraum, in dem der Programmspeicher sichtbar ist, haben 
neueren AVRs aber auch:

0-Series: ATtiny202, ATtiny204, ATtiny402, ATtiny404, ATtiny406, 
ATtiny804, ATtiny806, ATtiny807, ATtiny1604, ATtiny1606, ATtiny1607, 
ATmega808, ATmega809, ATmega1608, ATmega1609, ATmega3208, ATmega3209, 
ATmega4808, ATmega4809,

1-Series: ATtiny212, ATtiny214, ATtiny412, ATtiny414, ATtiny416, 
ATtiny416auto, ATtiny417, ATtiny814, ATtiny816, ATtiny817, ATtiny1614, 
ATtiny1616, ATtiny1617, ATtiny3214, ATtiny3216, ATtiny3217.

2-Series: ATtiny424, ATtiny426, ATtiny427, ATtiny824, ATtiny826, 
ATtiny827, ATtiny1624, ATtiny1626, ATtiny1627, ATtiny3224, ATtiny3226, 
ATtiny3227.

AVRrc: ATtiny4, ATtiny5, ATtiny9, ATtiny10, ATtiny102, ATtiny104, 
ATtiny20, ATtiny40.

AVR-Dx: AVR16DD14, AVR16DD20, AVR16DD28, AVR16DD32, AVR16DU14, 
AVR16DU20, AVR16DU28, AVR16DU32, AVR32DA28, AVR32DA32, AVR32DA48, 
AVR32DB28, AVR32DB32, AVR32DB48, AVR32DD14, AVR32DD20, AVR32DD28, 
AVR32DD32, AVR32DU14, AVR32DU20, AVR32DU28, AVR32DU32.

AVR-Ex: AVR16EA28, AVR16EA32, AVR16EA48, AVR16EB14, AVR16EB20, 
AVR16EB28, AVR16EB32, AVR32EA28, AVR32EA32, AVR32EA48.

AVR-SD: AVR32SD20, AVR32SD28, AVR32SD32.

Bei den größeren AVR-Dx und AVR-Ex Teilen mit ≥ 64KiB Programmspeicher 
ist immerhin ein 32KiB Segment im SRAM-Adressraum zu sehen.  Welches, 
kann man in den GNU Tools per Kommandozeilen-Option auswählen:

AVR64DA28, AVR64DA32, AVR64DA48, AVR64DA64, AVR64DB28, AVR64DB32, 
AVR64DB48, AVR64DB64, AVR64DD14, AVR64DD20, AVR64DD28, AVR64DD32, 
AVR64DU28, AVR64DU32, AVR64EA28, AVR64EA32, AVR64EA48, AVR64SD28, 
AVR64SD32, AVR64SD48, AVR128DA28, AVR128DA32, AVR128DA48, AVR128DA64, 
AVR128DB28, AVR128DB32, AVR128DB48, AVR128DB64.

Zum Beispiel wählt -Wl,--defsym,__flamp=1 den 2ten 32KiB Block aus, und 
Binutils, Startup-Code und Compiler kümmern sich um den Rest. (Default 
ist der letzte 32KiB Block).

Falls man aus irgendwelchen Gründen .rodata im SRAM bevorzugt, kann man 
mit -mrodata-in-ram compilieren.

[Peter D. (peda)]

Johannes F. schrieb:
> Ich hatte mal überlegt, hier im Wiki ein Tutorial zu einem der neuen
> AVRs (vielleicht 128DB28 oder 64EA28) zu beginnen

Ja, es ist sehr schwer, unter den vielen neuen AVRs was auszuwählen.
Inzwischen sind es 10 Familien:
- tinyAVR® 0
- tinyAVR® 1
- tinyAVR® 2
- megaAVR® 0
- AVR® DA
- AVR® DB
- AVR® DD
- AVR® EA
- AVR® EB
- AVR® SD

Vermutlich gab es mal hohe Prämien für jede neue Familie.

[Johannes F. (jofe)]

Peter D. schrieb:
> Vermutlich gab es mal hohe Prämien für jede neue Familie.

Ja stimmt, das dachte ich mir auch noch schon oft. Bei den mittlerweile 
sehr vielen Typen ist es schon recht schwer, einen Überblick zu 
behalten.

Etwas erleichternd ist zumindest bei den AVRs, dass die Benennung der 
neuen Familien einem Schema folgt (Flashgröße, Familie, Pinzahl). Die 
PICs dagegen haben soweit ich weiß vollkommen willkürliche Nummern, bei 
mindestens ebenso vielen Typen.

[Jochen D. (joe_d1)]

Georg M. schrieb:
> Jochen D. schrieb:
>> Auf der anderen Seite sieht es mit Tutorials, bewährten Bibliotheken und
>> dergleichen super-mau aus. Da gibt es gefühlt gar nichts, maximal Links
>> zu Microchip selbst.
> Ich finde die Datenblätter mit vielen Diagrammen schon ziemlich
> verständlich.

Und? Was hat die Verständlichkeit der Datenblätter (der ich gar nicht 
widerspreche!) mit der (Nicht-)Verfügbarkeit von bewährten Bibliotheken 
(wie z.B. Fleurys UART Lib, yaMBSiavr, async TWI-Lib) und Tutorials für 
neue AVR-Familien zu tun?

Kann natürlich jeder anhand der Datenblätter eigens für sein jeweiliges 
Projekt an den ausgewählten Prozessor anpassen. In den Anfangszeiten war 
ich immer ein bisschen froh wenn wenigstens ein Teil der Software 
verlässlich funktional war und ich mich dann "nur" um die Bugs in 
"meinen" Funktionen oder Beschaltung kümmern konnte / musste...

[Sherlock 🕵🏽‍♂️ (rubbel-die-katz)]

Achim S. schrieb:
> für was soll am sich entscheiden

Für das, was für dich sinnvoll ist. Dazu hast du keine Angaben gemacht.

[Sherlock 🕵🏽‍♂️ (rubbel-die-katz)]

Ben B. schrieb:
> der ADC ... könnte ruhig 16 Bit haben.

Gibt's halt nicht, und zwar aus gutem Grund. Hast du sonst noch 
unrealistische Wünsche, die man dir ausreden sollte?

[Johann L. (gjlayde)]

Johannes F. schrieb:
> Ich hatte mal überlegt, hier im Wiki ein Tutorial zu einem der neuen
> AVRs (vielleicht 128DB28 oder 64EA28) zu beginnen, nach dem Vorbild des
> alten ATmega8-Tutorials, also mit Assembler.

Aber wozu in Assembler???

An der Assembler-Programmierung / Assembler-Befehlen hat sich doch 
überhaupt nix geändert.

In C/C++ hingegenschon, weil die neueren[tm] Device-Header nicht mehr 
einfache C-Makros verwenden sondern Typedefs und Enums; und die sind in 
Assembler nicht verfügbar.  (Was kein Problem des Assembler ist sondern 
wie die Device-Header erzeugt werden).

[Johannes F. (jofe)]

Johann L. schrieb:
> Aber wozu in Assembler???

Ja ich weiß, darüber streiten sich die Geister. Es gibt jedenfalls 
vereinzelt im Forum immer noch Interessenten dafür, die AVRs in 
Assembler programmieren wollen.

Johann L. schrieb:
> An der Assembler-Programmierung / Assembler-Befehlen hat sich doch
> überhaupt nix geändert.

Am Befehlssatz zwar nur marginal, aber seit dem ATmega8 hat sich sehr 
viel im Bereich der Peripherie und anderen Aspekten getan, die es in 
einem Einstiegstutorial abzudecken gilt. Das AVR-Tutorial für den 
ATmega8 umfasste ja auch Timer, ADC, UART, SPI etc. Meine Absicht 
war/ist, ein ähnliches Tutorial mit ebendiesen Themen für einen neuen 
AVR zu beginnen.

[Ob S. (Firma: 1984now) (observer)]

Peter D. schrieb:

> Will man einen Bootloader benutzen, ist das mit den neuen Typen deutlich
> komplizierter, da der Bootloader nun an 0x0000 stehen muß.
> Der Bootloader muß daher wissen, wo die Applikation startet.
> Und die Applikation muß wissen, daß überhaupt ein Bootloader verwendet
> wird und wo dieser endet.
> Das alte Konzept mit Bootloader am Ende ist daher deutlich universeller.

Kannst du heute immer noch haben. Einfach indem du NICHT in 
Bootloader- und App-Bereich segmentierst. Dann hast du einen einzigen 
großen Bootloaderbereich über den gesamten Flash, also exakt die gleiche 
Situation wie bei den Classic-Tinys. Und dementsprechend kannst du das 
dann auch genau so lösen, wie das bei den Classic-Tinys gelöst wurde. 
Bootloader am Ende, App immer ab 0, Bootloader patcht App beim Flashen 
(den einen Sprungbefehl auf dem Reset-Vektor).

Der Vorteil ist: Die App selber muss vom Bootlader garnix wissen, der 
Linker muss nur wissen, dass der verfügbare Flash halt um das Stückchen 
kleiner ist, was der Bootloader belegt. Im Notfall geht es aber selbst 
ohne dieses Linker-Wissen. Dann muss halt der Bootloader darauf achten, 
dass er sich nicht selbst überschreibt (das sollte er ja sowieso). Dann 
führt eine zu große App halt nur dazu, dass das Bootloading fehlschlägt 
und nach dem Reset wieder der Bootloader startet.

Der Nachteil dieser Lösung sollte in diesem Zshg. natürlich auch erwähnt 
werden: Der Sicherheitsgewinn, den die Segmentierung in Bootloader- und 
App-Bereich bietet, den verliert man so natürlich.

Ja, die Lösung der Classic-ATMega war da schon deutlich eleganter. 
Insbesondere auch deshalb, weil die auch noch RWW konnten. Das können 
die neuen wohl leider garnicht mehr, wodurch Bootloading über bestimmte 
zeitkritische Bussysteme de facto unmöglich wird.

[Veit D. (devil-elec)]

Peter D. schrieb:
>
> Ja, es ist sehr schwer, unter den vielen neuen AVRs was auszuwählen.
> Inzwischen sind es 10 Familien:
> - tinyAVR® 0
> - tinyAVR® 1
> - tinyAVR® 2
> - megaAVR® 0
> - AVR® DA
> - AVR® DB
> - AVR® DD
> - AVR® EA
> - AVR® EB
> - AVR® SD

Das ist nichts im Vergleich zu anderen.

> Vermutlich gab es mal hohe Prämien für jede neue Familie.

Hast du irgendeine Allergie gegen moderne Controllerserien?
Du meckerst jedesmal gegen die neue Architektur. Das fällt auf. ;-)

[Ob S. (Firma: 1984now) (observer)]

Johann L. schrieb:

> Aber wozu in Assembler???
>
> An der Assembler-Programmierung / Assembler-Befehlen hat sich doch
> überhaupt nix geändert.

Nicht viel, aber einiges schon. Insbesondere bezüglich der Laufzeiten.

> In C/C++ hingegenschon, weil die neueren[tm] Device-Header nicht mehr
> einfache C-Makros verwenden sondern Typedefs und Enums; und die sind in
> Assembler nicht verfügbar.  (Was kein Problem des Assembler ist sondern
> wie die Device-Header erzeugt werden).

Also ich kann die Dinger wunderbar in Assembler programmieren. Mir wäre 
nicht aufgefallen, dass in den Device-Includes irgendwas fehlen würde. 
Enums sind natürlich zu defines umgerubelt und type-Gedöhns spielt in 
Asm zuwieso keinerlei Rolle, kann also problemlos und ersatzlos 
entfallen.

[Vanye R. (vanye_rijan)]

> Gibt's halt nicht, und zwar aus gutem Grund. Hast du sonst noch
> unrealistische Wünsche, die man dir ausreden sollte?

Stimmt nicht. AnalogDevices hatte mal Controller (MCS51 basiert) mit 
16Bit ADC. Aber halt zu entsprechenden Preisen. Vielleicht haben sie da 
ja einfach einen ihrer ADC mit in den Chip gebondet. :)

Vanye

[Jörg W. (dl8dtl) (Moderator)]

Vanye R. schrieb:
> Vielleicht haben sie da ja einfach einen ihrer ADC mit in den Chip
> gebondet. :)

Gut möglich, warum nicht? Also nicht in den Chip, sondern daneben 
natürlich, ggf. auch darüber. Der wäre dann zumindest weit genug weg von 
all den Störungen, die sonst der Digitalteil der MCU verursacht. 
Inbesondere könnte er seine eigene separate Masseführung bekommen.

[Achim S. (achims)]

Bei den ganzen neuen Typen habe ich wohl den überblick verloren.
Mit was kann ich den Atmega 128 und den Attiny 841 am besten ersetzen?
Mit diesen beiden Typen habe ich viel gemacht, wird aber auch Zeit für 
was neues.

[Johannes F. (jofe)]

Achim S. schrieb:
> Mit was kann ich den Atmega 128 und den Attiny 841 am besten ersetzen?

Evtl. AVR128DB64 bzw. ATtiny814/824 oder AVR16EB14

[Achim S. (achims)]

Den AVR128 DA 64 habe ich auf meiner Liste. Was ist der Unterschied zu 
DB? Und dann habe ich den Attiny 1616 oder 1606 oder 3216. Ist der 
Attiny 814 nicht ein "alter" Typ?

[Johannes F. (jofe)]

Achim S. schrieb:
> Den AVR128 DA 64 habe ich auf meiner Liste. Was ist der Unterschied zu
> DB?

Vergleiche einfach mal die Datenblätter. Die DA-Familie hatte AFAIR noch 
ziemlich viele Silicon Errata, DB war dann besser. Die genauen 
Unterschiede weiß ich aber gerade nicht.

Achim S. schrieb:
> Und dann habe ich den Attiny 1616 oder 1606 oder 3216.

Die tiny0-Serie ist eine abgespeckte Low-Cost-Version der 1-Serie, 
letztere hat z.B. einen 8-bit-DAC und 10-bit-ADC, die 2-Serie hat statt 
des DAC einen 12-bit-ADC. Gibt sicher noch mehr Unterschiede, darüber 
geben die Datenblätter Auskunft.

Achim S. schrieb:
> Ist der
> Attiny 814 nicht ein "alter" Typ?

Nö, das ist ein Vertreter der "neuen" tiny1-Serie mit UPDI. Der tiny841 
dagegen ist ein "alter" mit ISP.

[Roland F. (rhf)]

Hallo,
Johann L. schrieb:
> In C/C++ hingegenschon, weil die neueren[tm] Device-Header nicht mehr
> einfache C-Makros verwenden sondern Typedefs und Enums; und die sind in
> Assembler nicht verfügbar.

In den alten Datenblättern gab es Bespiele in C wie man die Peripherie 
der Controller anspricht.
Gibt es denn irgend wo eine Einführung wie das bei den neueren Typen in 
C/C++ funktioniert?

rhf

[Georg M. (g_m)]

Roland F. schrieb:
> In den alten Datenblättern gab es Bespiele in C wie man die Peripherie
> der Controller anspricht.
> Gibt es denn irgend wo eine Einführung wie das bei den neueren Typen in
> C/C++ funktioniert?

Jetzt ist alles viel verständlicher.

Z.B.:

CLKSEL bedeutet Clock Select
SINGLESLOPE bedeutet Single-Slope PWM
CMP0EN bedeutet Compare Channel 0 Enable
SAMPDUR bedeutet Sample Duration
ADC_START_IMMEDIATE bedeutet ADC Start Immediate
RUNSTDBY bedeutet Run in Standby
INPUT_DISABLE bedeutet Input Disable

usw.

[Maxim B. (max182)]

Da man sowieso am besten die Zahl von verwendeten Typen begrenzen sollte 
(nur so kann man in Hobby die ausreichend kennenlernen), habe ich in AVR 
für mich schon lange zwei gewählt: ATMega1284 und AVR128DB. Erste paßt 
für alle "durchschnittlichen" Aufgaben. Zweite scheint für Kleinaufgaben 
konzipiert zu sein, dafür mehrere USARTs und zwei SPI, reiche 
Pin-Remapping.

Nun überlege ich, mit STM32 zu beginnen. F103 scheint schon verältert, 
H7 haben 64 bit FPU, aber für Anfang wohl etwas zu kompliziert. Z.Z. 
denke ich von F4. F407 oder F429. Außer 32 bit FPU sind für mich 32 bit 
Timer interessant: für Aufgaben wie Frequenzmessen aller Art (z.B. ein 
Stimmgerät) sind die bequemer als gewöhnlichen 16 bit Timer. Es gibt 
auch viele andere interessante Sachen.

Es gibt zwar "Nucleo" und "Discovery". Aber ich denke, am besten kann 
man MC kennenlernen, wenn man auch Platine selbst macht.

[Sherlock 🕵🏽‍♂️ (rubbel-die-katz)]

Fen ATmega1284 hätte ich auch empfohlen. Er ist vom Design her noch nahe 
am ATmega128, hat aber schon Debugwire.

Ich habe für mich beschlossen, die neueren Serien links liegen zu lassen 
und mich stattdessen mit ARM Cortex M basierten Controllern zu 
beschäftigen. Man kann nicht alles gleichzeitig lernen, macht im Hobby 
auch wenig Sinn.

[Veit D. (devil-elec)]

Roland F. schrieb:

> Gibt es denn irgend wo eine Einführung wie das bei den neueren Typen in
> C/C++ funktioniert?

Von Microchip gibt es App Notes "Getting Started". Die findet man auf 
den Controller Seiten unter Dokumente, dort wo man auch das Controller 
Manual findet. Es lohnt sich quer über alle verwandten Serien zu 
schauen. In den App Notes gibt es auch Links zu GitHub Microchip.

Einen kleinen Einstieg gibt es auch hier.
https://forum.arduino.cc/t/nano-every-atmega4809-am-anfang-stand-der-anfang/701185
Das Verständnis kann man auf alle Verwandten übertragen.

[Maxim B. (max182)]

Sherlock 🕵🏽‍♂️ schrieb:
> Fen ATmega1284 hätte ich auch empfohlen. Er ist vom Design her noch nahe
> am ATmega128, hat aber schon Debugwire.

JTAG ist interessanter als Debugwire. Damit bekommt man zwar ein MC mit 
nur 28 freien Pins, aber JTAG ist bequemer in Arbeit.
ATmega2560 noch als Variante: auch JTAG und deutlich mehr Pins, 4x 
USARTs. Aber die sind letzte Zeit unverhältnismäßig teuer. Trotzdem 
haben die fehlende bei auch neueren AVR128DB64 Interface für externe 
SRAM, deshalb halte ich AVR128DB eher für kleinere Sachen konzipiert. 
Aber auch wie bei STM32 muß man 0,5 mm Pins löten können.

Vorteil von alten AVRs ist bessere Code-Verständlichkeit. 
Selbstverständlich wenn man MC ohne Arduino benutzt :)

[Johannes F. (jofe)]

Maxim B. schrieb:
> fehlende bei auch neueren AVR128DB64 Interface für externe
> SRAM

Hmmm... ich denke, die Zeiten von MCUs mit extern dran gepapptem RAM 
sind vorbei. Wenn viel RAM (mehr als 16 KiB) benötigt wird, sind dann 
doch wirklich 32-bitter à la Cortex M0+ aufwärts angesagt.

[Veit D. (devil-elec)]

Maxim B. schrieb:
> Trotzdem
> haben die fehlende bei auch neueren AVR128DB64 Interface für externe
> SRAM, deshalb halte ich AVR128DB eher für kleinere Sachen konzipiert.
Bis 16k SRAM, 128k Flash, bis 64 Pins. Für kleinere Sachen?
Das Ding steuert meine Modelleisenbahn. Zudem man gar nicht so viele 
Pins der MCU verwendet, man nutzt dennoch I2C und SPI Bus.

> Vorteil von alten AVRs ist bessere Code-Verständlichkeit.
Verstehe ich nicht. Insgesamte eine seltsame Logik für mich.

[Maxim B. (max182)]

Johannes F. schrieb:
> ich denke, die Zeiten von MCUs mit extern dran gepapptem RAM
> sind vorbei.

Trotzdem findet man bei STM32 sehr reiche Auswahl von solch 
Schnitstellen.

Veit D. schrieb:
> Bis 16k SRAM, 128k Flash, bis 64 Pins. Für kleinere Sachen?
und statt 10 000 Umprogrammierungen nur 1000. Auch 1000 nicht immer 
(zwar bei AVR128DA, laut Fehlerbeschreibung).

16k SRAM, 128k Flash hat auch ATmega1284

[Johannes F. (jofe)]

Veit D. schrieb:
>> Vorteil von alten AVRs ist bessere Code-Verständlichkeit.
> Verstehe ich nicht. Insgesamte eine seltsame Logik für mich.

Dito, verstehe die Aussage auch nicht. Ich finde den Code für die 
"neueren" Peripheriemodule wesentlich einfacher verständlich und 
nachvollziehbar, allein schon wegen der "sprechenderen" Symbole auch der 
Assembler-Include-Files.

Wenn man mal an URSEL u.a. "Krücken" der alten mega8-UART zurückdenkt, 
die damals noch notwendig waren wegen der Mehrfachnutzung mancher 
Register-Adressen...

[Johannes F. (jofe)]

Maxim B. schrieb:
> und statt 10 000 Umprogrammierungen nur 1000

Das ist mir auch aufgefallen – da wurde offenbar in den meisten neuen 
Serien an irgendeinem Prozess gespart. Würde mich mal interessieren, was 
genau dafür entscheidend ist, wie oft ein Flash geschrieben werden kann.

Allein bei der EA-Serie werden noch 10.000 Schreibzyklen im Datenblatt 
garantiert, ebenso bei den neuen ATtinys. Das ist tatsächlich ein Grund 
für mich, AVR-EA und tiny1/2 gegenüber den anderen zu bevorzugen.

[Maxim B. (max182)]

Einziges, was bei alten Megas eindeutig schlecher ist, das ist I2C. Auch 
USART, falls man gleichzeitig mehrere nicht gewöhnlichen Baudraten 
braucht, paßt bei AVR128 besser. Aber um eine Ordnung schlechtere 
Ressource von Flash...

[Johannes F. (jofe)]

Maxim B. schrieb:
> Aber um eine Ordnung schlechtere
> Ressource von Flash...

Wie sieht es mit den Flash-Zyklen eigentlich bei den PICs aus, da machen 
die Datenblätter nämlich gar keine Angabe dazu?

[Maxim B. (max182)]

Johannes F. schrieb:
> Allein bei der EA-Serie werden noch 10.000 Schreibzyklen im Datenblatt
> garantiert
Bei AT90USB1286/87 steht sogar 100 000 write/erase cycles
Je weiter, umso schlechter alles...

[Veit D. (devil-elec)]

Maxim B. schrieb:
> Veit D. schrieb:
>> Bis 16k SRAM, 128k Flash, bis 64 Pins. Für kleinere Sachen?
> und statt 10 000 Umprogrammierungen nur 1000. Auch 1000 nicht immer
> (zwar bei AVR128DA, laut Fehlerbeschreibung).
>
> 16k SRAM, 128k Flash hat auch ATmega1284

Was hat die Flash Anzahl mit kleinen Sachen zu tun?
Man kann locker mehr wie 1000x flashen.
Hast du schon eine MCU tot geflasht?
Im Produktivsystem nimmt man sowieso nicht seinen 
Entwicklungscontroller.
Ein ATmega1284 hat andere Hardwareinheiten. Äpfel vs. Birnen.
Mir ist grundsätzlich egal welchen Controller du oder irgendjemand 
verwendet. Nur gehen mit die Vergleiche auf den Sack die hinten und 
vorne nicht stimmen. Untermauert mit an den Haaren herbeigezogenen 
Scheinschutzbehauptungen.

[Maxim B. (max182)]

Veit D. schrieb:
> Mir ist grundsätzlich egal welchen Controller du oder irgendjemand
> verwendet.

Mir ist auch egal, welchen COntroller du verwendest.

[Frank K. (fchk)]

Johannes F. schrieb:
> Maxim B. schrieb:
>> Aber um eine Ordnung schlechtere
>> Ressource von Flash...
>
> Wie sieht es mit den Flash-Zyklen eigentlich bei den PICs aus, da machen
> die Datenblätter nämlich gar keine Angabe dazu?

"die" PICs. gibts nicht. Bei den 8-Bittern wie dem 16LF19176, den ich 
gerade vor mir habe, sind es 10k Zyklen. Wie es bei 300MHz MIPS PIC32 
Typen aussieht, weiß ich nicht - da müsste ich nachschauen. Und "da 
machen die Datenblätter nämlich gar keine Angabe dazu" stimmt auch 
nicht, das steht da schon drin.

fchk

[Johannes F. (jofe)]

Frank K. schrieb:
> Und "da
> machen die Datenblätter nämlich gar keine Angabe dazu" stimmt auch
> nicht, das steht da schon drin.

Ah, stimmt, gerade nochmal beim PIC18F57Q43 gesucht:
https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/PIC18F27-47-57Q43-Microcontroller-Data-Sheet-XLP-DS40002147.pdf
Seite 897, Table 47-5. Memory Programming.

Dieser Typ hat auch nur 1.000 garantiert.

Bei den AVRs steht es immer direkt am Anfang unter Features, deshalb 
hatte ich es bisher bei den PICs nicht gefunden.

[Mi N. (msx)]

Veit D. schrieb:
> Man kann locker mehr wie 1000x flashen.
> Hast du schon eine MCU tot geflasht?
> Im Produktivsystem nimmt man sowieso nicht seinen
> Entwicklungscontroller.

Das sehe ich auch so. Vor vielen Jahren gab es diese Einschränkungen bei 
Renesas, wo GLYN (?) das mal getestet hatte und (wenn ich mich richtig 
erinnere) nach >= 20000 Programmierzyklen keine Probleme feststellen 
konnte. Einzig bei Raumfahrtanwendungen sollte man sich strickt an 1000 
halten ;-)

Bei den neueren AVRs haben mich immer die Timer abgeschreckt - etwas 
schräg, wenn man zuvor die einfachen Timer kannte, die für meine 
Anwendungen völlig ausreichten. Vorteil der AVRs ist immer noch der 
große Versorgungsspannungbereich bis 5 V und der rel. kleine Preis.
Wenn man etwas "Neues" zum Spielen sucht, würde ich zu Cortex-M0 raten 
aber nicht unbedingt zum o.g. RP2040, sondern eher STM32G031/431 mit 
verschiedenen Gehäusetypen von extrem sparsam bis sehr leistungsfähig.

[Johannes F. (jofe)]

Mi N. schrieb:
> Bei den neueren AVRs haben mich immer die Timer abgeschreckt - etwas
> schräg, wenn man zuvor die einfachen Timer kannte, die für meine
> Anwendungen völlig ausreichten.

Ich finde die neuen Timer grundsätzlich besser, auch wenn man sich 
natürlich erstmal umgewöhnen muss, aber sie können halt wesentlich mehr. 
Zugegebenermaßen habe ich von den neuen Features auch noch keinen 
Gebrauch gemacht, aber es gibt ja allein schon wesentlich mehr 
Ressourcen in Form von mehr 16-bit breiten Timern und mehr 
gleichzeitigen Clear-on-Compare-Match-Möglichkeiten (da ja auch von 
vornherein die Periodendauer in dedizierten Registern festgelegt wird 
und nicht mehr per default bis 2^n gezählt wird wie bei den alten 
Timern). Insgesamt finde ich die Nutzung daher bequemer. Nur die teils 
inkonsistente Benennung von Flags etc. zwischen den verschiedenen 
Timertypen ist etwas verwirrend.

[Achim S. (achims)]

Habe mir eure Meinung dazu gründlich durchgelesen.
Zum Attiny1616:
Ein 8 Bit reicht für die meisten Anwendungen aus. Wenn man mehr machen 
will kann man ja immer noch einen 32 Bit nehmen.
Für die meisten Anwendungen reichen auch ca. bis zu 16 GPIO zuzüglich 2x 
I2C Bus. SPI sei mal vernachlässigt. ADC und DAC sind auch dabei. 
Betriebsspannung 5V oder 3,3V mit Pegelwandler. Bauform SOIC 20 Pins.
Etwas grösser: der Attiny 3216 mit gleicher Belegung und gleiche 
Bauform.
Hauptrechner z.B. RP2040, abgester Prozessor für einzelne Teilaufgaben 
Attiny 1616.
Sehe ich das so richtig?

[Darius (dariusd)]

Hallo

Axel S. schrieb:
> * wofür du die Werkzeuge schon hast (Toolchain, Programmer, etc)
>
> * wofür du Hilfe bekommen kannst (vulgo: was die anderen nehmen)

Volle Zustimmung, es gibt, zumindest im Hobbybereich und für "normale 
Anwender, nicht dümmeres, irgendwelche nicht breit durch andere 
Hobbyisten, Modellbauer, Funkamateure,... genutzte und mit Programmen 
und "Schichten" unterstützte µC zu nutzen.

Auch wenn mich einige jetzt steinigen werden:
Der µC (fertige Boards) muss vom Arduinouniversum unterstützt werden 
(also auch die IDE) auch via Aliexpress als Board (Jehova, er hat Jehova 
gesagt...) als Clone beschaffbar sein und einfach (als Board aber auch 
als Chip) problemlos "überall" ohne Wartezeiten durch (mal wieder 
irgendwo ein Sack Reis umgefallen...) den Hersteller zu beziehen

Dadurch ergibt sich automatisch auch das, der µC Preiswert ist und zu 
einer großen Familie gehört - der Preis hat ja erstaunlich wenig mit der 
"Rechenleistung" und den Schnittstellen zu tun.
Ein PIC 16F84 aber auch ein ATMega 8  ist als Chip z.B. mittlerweile oft 
teurer als ein ESP32 Board das ja unvergleichlich mehr an Leistung und 
Schnittstellen bietet.

Andererseits:
So einen PIC16F84, einen ATMega8 usw. bekommt man auch heute noch quasi 
neu (NOS) problemfrei (halt zu Freudenhauspreisen, aber man bekommt 
sie...).
Eben weil sie einstmals weit verbreitet auch in Hobbykreisen waren und 
zumindest was den ATMega8 angeht immer noch durch das Arduiniunversum 
unterstützt wird und auch alle Anwenderinfos (durch andere Anwender) und 
Projekte im Netz vorhanden sind.

[Jörg W. (dl8dtl) (Moderator)]

Johannes F. schrieb:
> Würde mich mal interessieren, was genau dafür entscheidend ist, wie oft
> ein Flash geschrieben werden kann.

Könnte an kleineren Strukturen liegen. Dadurch sind sie ja insgesamt 
billiger – die alten AVRs wurden noch auf vergleichsweise 
grobschlächtigen Prozessen hergestellt.

[Johannes F. (jofe)]

Achim S. schrieb:
> Hauptrechner z.B. RP2040, abgester Prozessor für einzelne Teilaufgaben
> Attiny 1616.
> Sehe ich das so richtig?

Ergibt wenig Sinn. AFAIK ist es kaum üblich, "für einzelne Teilaufgaben" 
extra getrennte MCUs zu verwenden. Es sei denn, räumliche Entfernung 
legt das nahe.

[Johannes F. (jofe)]

Darius schrieb:
> einen ATMega8 usw. bekommt man auch heute noch quasi
> neu (NOS) problemfrei (halt zu Freudenhauspreisen, aber man bekommt
> sie...).

Der ATmega8 wird sogar noch hergestellt (bei Microchip.com als "active" 
gekennzeichnet). Jedoch vermutlich nur in kleinen Stückzahlen und 
deshalb so teuer. Kann mir kaum vorstellen, dass der gewerblich noch für 
Neuentwicklungen eingesetzt wird, weil Preis und Ausstattung inzwischen 
in keinem akzeptablen Verhältnis mehr stehen, wenn man mit neueren Typen 
bzw. 32-bit vergleicht.

[Georg M. (g_m)]

Ich bräuchte den AVR16EA14 - gibt es leider nicht. :(

[Falk B. (falk)]

Jörg W. schrieb:
> Könnte an kleineren Strukturen liegen. Dadurch sind sie ja insgesamt
> billiger – die alten AVRs wurden noch auf vergleichsweise
> grobschlächtigen Prozessen hergestellt.

Da wurden die einzelnen Bits noch mit Ziegeln gemauert! Deutsche 
Wertarbeit!
Ach nee, waren ja Norwerger . . . ;-)

Naja, 1000 Schreibzyklen ist für einen einen Controller auf dem 
Testboard schon eher wenig, ne Null dahinter wäre OK. Aber wenn's nicht 
gerade ein BGA ist, kann man so ein Ding meistens mit Heißluft schnell 
wechseln und dann geht's weiter.

[Falk B. (falk)]

Georg M. schrieb:
> Ich bräuchte den AVR16EA14 - gibt es leider nicht. :(

Klar. Je größer und unüberschaubarer das Angebot, umso mehr "braucht" 
man nicht verfügbare Exoten . . .

[Norbert (der_norbert)]

Die Diskussion um Schreibzyklen erinnert schon ein wenig an die stets 
unterschwellig vorhandene (Reichweiten-)Panik bei SSDs.

Die wenigen, welche tatsächlich mal einen Datenverlust hatten, hatten 
natürlich in all den Jahrzehnten zuvor nie einen Festplattencrash zu 
beklagen.

Ich selbst habe in meinem Leben schon einige µController zerlegt, 
praktisch immer aus Unachtsamkeit. Niemals wegen zu geringer 
Schreibzyklen. Und angenommene täglich fünfzig Schreibvorgänge bei 200 
Arbeitstagen verursachen mir jetzt auch keine schlaflosen Nächte.

Die letzten Bauteile die diesbezüglich mal versagt hatten, waren 
2708/2716 irgendwann in den Achtzigern. (Ja, die mit den 
Quarzglasfenstern und dem Faible für Sonnenbänke)

[Veit D. (devil-elec)]

Mi N. schrieb:

> Bei den neueren AVRs haben mich immer die Timer abgeschreckt - etwas
> schräg, wenn man zuvor die einfachen Timer kannte, die für meine
> Anwendungen völlig ausreichten.

Schrecken dich die Timer immer noch ab? Glaube ich doch nicht bei dir. 
Oder hatten sie dich abgeschreckt? Die alten Timer sind sozusagen 
Multi-Kulti. Die neuen Timer sind spezialisierter. Man hat das Gefühl 
man hätte davon immer zu wenig. Das Einzigste was mich etwas stört ist 
der eingeschränkte Prescaler von TCA. Dafür ist die Handhabung einfacher 
gewurden, wenn man es im Gesamten betrachtet. Man muss bspw. keinen 
Overload mehr beachten, man kaskadiert den nächsten TCB dazu, bis der 
Zählumfang für einen passt. Die TCBs sind die perfekten "Mess-Timer" für 
alles. Für deinen präzisen Frequenzzähler kann man wie bei anderen den 
Komparator davor schalten usw..

Eigentlich benötige ich nur einen AVR128DB oder einen AVR64EA. Letzterer 
hat immer 4x TCB dabei und hat seltsamerweise 10.000 Flash cycles im 
Datenblatt stehen. Vielleicht hat auch jemand bei den 1.000er eine Null 
vergessen. Kann alles sein. :-)

[Veit D. (devil-elec)]

Georg M. schrieb:
> Ich bräuchte den AVR16EA14 - gibt es leider nicht. :(

Schneidet man paar Pins ab, dann passt das.

[Jörg W. (dl8dtl) (Moderator)]

Falk B. schrieb:
> Naja, 1000 Schreibzyklen ist für einen einen Controller auf dem
> Testboard schon eher wenig, ne Null dahinter wäre OK.

Man darf nicht vergessen: diese Haltbarkeiten sind die Garantiezeiten 
unter Extrembedingungen, also bei Tmax. Für reinen Laborbetrieb kannst 
du da problemlos noch eine Null dranhängen. Allerdings würde ich 
natürlich einen Controller, der in der Entwicklung schon einige hundert 
Zyklen hinter sich hat, nicht danach produktiv in einem Gerät einsetzen.

[Michael S. (smtschmidt)]

Johann L. schrieb:
> 0-Series: ATtiny202, ATtiny204, ATtiny402, ATtiny404, ATtiny406,
> ATtiny804, ATtiny806, ATtiny807, ATtiny1604, ATtiny1606, ATtiny1607,
> ATmega808, ATmega809, ATmega1608, ATmega1609, ATmega3208, ATmega3209,
> ATmega4808, ATmega4809,
>
> 1-Series: ATtiny212, ATtiny214, ATtiny412, ATtiny414, ATtiny416,
> ATtiny416auto, ATtiny417, ATtiny814, ATtiny816, ATtiny817, ATtiny1614,
> ATtiny1616, ATtiny1617, ATtiny3214, ATtiny3216, ATtiny3217.
>
> 2-Series: ATtiny424, ATtiny426, ATtiny427, ATtiny824, ATtiny826,
> ATtiny827, ATtiny1624, ATtiny1626, ATtiny1627, ATtiny3224, ATtiny3226,
> ATtiny3227.
>
> AVRrc: ATtiny4, ATtiny5, ATtiny9, ATtiny10, ATtiny102, ATtiny104,
> ATtiny20, ATtiny40.
>
> AVR-Dx: AVR16DD14, AVR16DD20, AVR16DD28, AVR16DD32, AVR16DU14,
> AVR16DU20, AVR16DU28, AVR16DU32, AVR32DA28, AVR32DA32, AVR32DA48,
> AVR32DB28, AVR32DB32, AVR32DB48, AVR32DD14, AVR32DD20, AVR32DD28,
> AVR32DD32, AVR32DU14, AVR32DU20, AVR32DU28, AVR32DU32.
>
> AVR-Ex: AVR16EA28, AVR16EA32, AVR16EA48, AVR16EB14, AVR16EB20,
> AVR16EB28, AVR16EB32, AVR32EA28, AVR32EA32, AVR32EA48.
>
> AVR-SD: AVR32SD20, AVR32SD28, AVR32SD32.
>
> Bei den größeren AVR-Dx und AVR-Ex Teilen mit ≥ 64KiB Programmspeicher
> ist immerhin ein 32KiB Segment im SRAM-Adressraum zu sehen.  Welches,
> kann man in den GNU Tools per Kommandozeilen-Option auswählen:
>
> AVR64DA28, AVR64DA32, AVR64DA48, AVR64DA64, AVR64DB28, AVR64DB32,
> AVR64DB48, AVR64DB64, AVR64DD14, AVR64DD20, AVR64DD28, AVR64DD32,
> AVR64DU28, AVR64DU32, AVR64EA28, AVR64EA32, AVR64EA48, AVR64SD28,
> AVR64SD32, AVR64SD48, AVR128DA28, AVR128DA32, AVR128DA48, AVR128DA64,
> AVR128DB28, AVR128DB32, AVR128DB48, AVR128DB64.

Mich würde mal interessieren, woher ihr die übersichtlichen 
Darstellungen habt. Wahrscheinlich bin ich einfach zu blöd, aber bei 
Microchip finde ich nichts dazu.

Auch so eine Darstellung wir hier:
Beitrag "Re: Moderne AVR (Nachfolger Atmega und Attiny)"
hatte ich bisher nicht gefunden.

Auf der Webseite von MC gibt es gar keinen Hinweis, das so etwas wie die 
Mega0-Serie existiert.

Danke im Voraus!

[Peter D. (peda)]

Veit D. schrieb:
> Hast du irgendeine Allergie gegen moderne Controllerserien?
> Du meckerst jedesmal gegen die neue Architektur. Das fällt auf. ;-)

Aber nicht gegen neue Features an sich, sondern gegen die 
Unübersichtlichkeit und die ständig neuen Namensgebungen.
Die Bezeichnung AVR32 war doch schon belegt und nun gibt es zusätzlich 
AVR32, die gar keine 32Bitter sind. Warum ist es nur so schwer, sich 
endlich mal an eine gewählte Namensgebung zu halten.

Die Unterschiede der neuen Familien untereinander muß man oft mit der 
Lupe suchen, so gering sind sie. Wenn man da einfach beim Pflichtenheft 
ein wenig mehr zusammengearbeitet hätte, würde man bequem mit unter 20% 
der Typenvielfalt auskommen.
Man bekommt den Eindruck, da sitzen viele verschiedene Teams in jeweils 
ihrem eigenen Elfenbeinturm und schauen weder links noch rechts.

[Falk B. (falk)]

Peter D. schrieb:
> Man bekommt den Eindruck, da sitzen viele verschiedene Teams in jeweils
> ihrem eigenen Elfenbeinturm und schauen weder links noch rechts.

Ich glaube eher, den Leuten ist langweilig und man bläst die 
Produktpalette einfach nur auf ;-)

[Johann L. (gjlayde)]

Michael S. schrieb:
> Johann L. schrieb:
>> 0-Series: ATtiny202, ATtiny204, ATtiny402, ATtiny404, ATtiny406,
>> ATtiny804, ATtiny806, ATtiny807, ATtiny1604, ATtiny1606, ATtiny1607,
>> ATmega808, ATmega809, ATmega1608, ATmega1609, ATmega3208, ATmega3209,
>> ATmega4808, ATmega4809,
>>
>> 1-Series: ATtiny212, ATtiny214, ATtiny412, ATtiny414, ATtiny416,
>> ATtiny416auto, ATtiny417, ATtiny814, ATtiny816, ATtiny817, ATtiny1614,
>> ATtiny1616, ATtiny1617, ATtiny3214, ATtiny3216, ATtiny3217.
>>
>> 2-Series: ATtiny424, ATtiny426, ATtiny427, ATtiny824, ATtiny826,
>> ATtiny827, ATtiny1624, ATtiny1626, ATtiny1627, ATtiny3224, ATtiny3226,
>> ATtiny3227.
>>
>> AVRrc: ATtiny4, ATtiny5, ATtiny9, ATtiny10, ATtiny102, ATtiny104,
>> ATtiny20, ATtiny40.
>>
>> AVR-Dx: AVR16DD14, AVR16DD20, AVR16DD28, AVR16DD32, AVR16DU14,
>> AVR16DU20, AVR16DU28, AVR16DU32, AVR32DA28, AVR32DA32, AVR32DA48,
>> AVR32DB28, AVR32DB32, AVR32DB48, AVR32DD14, AVR32DD20, AVR32DD28,
>> AVR32DD32, AVR32DU14, AVR32DU20, AVR32DU28, AVR32DU32.
>>
>> AVR-Ex: AVR16EA28, AVR16EA32, AVR16EA48, AVR16EB14, AVR16EB20,
>> AVR16EB28, AVR16EB32, AVR32EA28, AVR32EA32, AVR32EA48.
>>
>> AVR-SD: AVR32SD20, AVR32SD28, AVR32SD32.
>>
>> Bei den größeren AVR-Dx und AVR-Ex Teilen mit ≥ 64KiB Programmspeicher
>> ist immerhin ein 32KiB Segment im SRAM-Adressraum zu sehen.  Welches,
>> kann man in den GNU Tools per Kommandozeilen-Option auswählen:
>>
>> AVR64DA28, AVR64DA32, AVR64DA48, AVR64DA64, AVR64DB28, AVR64DB32,
>> AVR64DB48, AVR64DB64, AVR64DD14, AVR64DD20, AVR64DD28, AVR64DD32,
>> AVR64DU28, AVR64DU32, AVR64EA28, AVR64EA32, AVR64EA48, AVR64SD28,
>> AVR64SD32, AVR64SD48, AVR128DA28, AVR128DA32, AVR128DA48, AVR128DA64,
>> AVR128DB28, AVR128DB32, AVR128DB48, AVR128DB64.
>
> Mich würde mal interessieren, woher ihr die übersichtlichen
> Darstellungen habt.

Naja, ich weiß halt, welche Device-Familie welche Eigenschaft hat: Flash 
im RAM-Space haben avrtiny (alle), avrxmega3 (alle), avrxmega2 (nur 
AVR*) und avrxmega4 (nur AVR*).  Dann hab ich die entsprechenden Devices 
kopiert von

https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html

und nach Serie sortiert.  Von Hand :-)

.

[Ob S. (Firma: 1984now) (observer)]

Johannes F. schrieb:

> Wenn man mal an URSEL u.a. "Krücken" der alten mega8-UART zurückdenkt,
> die damals noch notwendig waren wegen der Mehrfachnutzung mancher
> Register-Adressen...

Oder das bis zum bitteren Ende konsequent durchgeschleppte Fehldesign 
von ADCSR(n)...

[Ob S. (Firma: 1984now) (observer)]

Peter D. schrieb:

> Die Bezeichnung AVR32 war doch schon belegt und nun gibt es zusätzlich
> AVR32, die gar keine 32Bitter sind.

Nein, gibt es nicht. Was es jetzt tatsächlich zusätzlich gibt, sind 
AVR32D...

> Warum ist es nur so schwer, sich
> endlich mal an eine gewählte Namensgebung zu halten.

Weil es halt unbedingt ein neues Namensschema sein sollte. Seien wir 
froh, dass es wenigstens ein nachvollziehbares Schema geworden ist. 
Hätte ja auch völliger Wildwuchs wie bei den PICs entstehen können.

> Die Unterschiede der neuen Familien untereinander muß man oft mit der
> Lupe suchen, so gering sind sie.

Das allerdings ist leider wahr. Hat allerdings den Vorteil, dass es oft 
sehr einfach ist, ein replacement part zu bestimmen, was mit minimalsten 
oder sogar ohne jegliche Änderungen in ein bestehendes Design paßt. Wenn 
die Liefersituation oder die Preisgestaltung das wünschenswert 
erscheinen lassen.

[Veit D. (devil-elec)]

Peter D. schrieb:
> Veit D. schrieb:
>> Hast du irgendeine Allergie gegen moderne Controllerserien?
>> Du meckerst jedesmal gegen die neue Architektur. Das fällt auf. ;-)
>
> Aber nicht gegen neue Features an sich, sondern gegen die
> Unübersichtlichkeit und die ständig neuen Namensgebungen.
> Die Bezeichnung AVR32 war doch schon belegt und nun gibt es zusätzlich
> AVR32, die gar keine 32Bitter sind. Warum ist es nur so schwer, sich
> endlich mal an eine gewählte Namensgebung zu halten.

Naja, du unterschlägst die nachfolgende Bezeichnung des Schemas. Das ist 
glasklar. AVR + Flashgröße + Serie + Pinanzahl. Die 32 jetzt nichts mit 
32Bit zu tun. Es ist die Flashgröße. An dieser Stelle stehen auch andere 
Zahlen für andere Flashgrößen. Welches Namenschema hättest du erdacht?

> Die Unterschiede der neuen Familien untereinander muß man oft mit der
> Lupe suchen, so gering sind sie. Wenn man da einfach beim Pflichtenheft
> ein wenig mehr zusammengearbeitet hätte, würde man bequem mit unter 20%
> der Typenvielfalt auskommen.

In meinen Augen ist das eine Erhöhung der Ausbeute. Ist bei anderen 
Firmen und Controllerfamilien nicht anders.

[Veit D. (devil-elec)]

Michael S. schrieb:

> Auf der Webseite von MC gibt es gar keinen Hinweis, das so etwas wie die
> Mega0-Serie existiert.

Zur Mega0 Serie zählt zum Bsp. ein ATmega4809, als größter Typ der 
Serie. Die Serie wird scheinbar nicht weiter ausgebaut. Ich denke mit 
den neuen ATtiny und AVR Serien ist alles abgedeckt. Die Mega0 Serie war 
laut meines Wissens die Erste mit der neuen Architektur. Kann man gut zu 
den Alten unterscheiden, alles was UPDI als Programmierschnittstelle 
hat, hat die neue Architektur.

[Yalu X. (yalu) (Moderator)]

Achim S. schrieb:
> Welchen AVR

Achim S. schrieb:
> Bei den ganzen neuen Typen habe ich wohl den überblick verloren.

Dann vielleicht

Achim S. schrieb:
> doch den RP2040

Dieser Controller und seine Brüder machen es einem leicht, den Überblick
zu bewahren ;-)

Zudem kostet er fast nichts.

[Johannes F. (jofe)]

Yalu X. schrieb:
> Achim S. schrieb:
>> doch den RP2040
>
> Dieser Controller und seine Brüder machen es einem leicht, den Überblick
> zu bewahren ;-)

Immerhin hat man aktuell wohl noch die Qual der Wahl zwischen entweder 
(1) nur eingeschränkt brauchbarem ADC oder (2) dauerhaft/irreversibel 
aktivierten Pull-Downs an einigen Pins. :D

[Norbert (der_norbert)]

Johannes F. schrieb:
> dauerhaft/irreversibel
> aktivierten Pull-Downs an einigen Pins.

Quelle?

Oder macht's einfach nur Spaß so etwas von sich zu geben?

[Johannes F. (jofe)]

Norbert schrieb:
> Johannes F. schrieb:
>> dauerhaft/irreversibel
>> aktivierten Pull-Downs an einigen Pins.
>
> Quelle?
>
> Oder macht's einfach nur Spaß so etwas von sich zu geben?

Beitrag "Pico2 RP2350 GPIO Fehler"

[Norbert (der_norbert)]

Sollte sich das etwa auf den einzigen offiziellen GPIO Eintrag RP2350-E9 
beziehen?

Da geht's um etwas völlig anderes. Nämlich dass ein offener, extrem 
hochohmiger, schwebender Eingang nicht wieder automagisch auf Low fällt 
wenn ein zuvor angelegtes High weggenommen wird.

Das kann man mit einem externen Pull-Down von ca. 8kΩ…9kΩ beheben.
Was nur dann eventuell zu einem Problem werden könnte, wenn man 
dynamisch zwischen I und O umschalten möchte. Aber auch das Problem 
lässt sich im Normalfall vermeiden und lösen.

Außer - und das ist der einzige mir bekannte Fall - wenn das Ganze 
ausschließlich im Rahmen eines PIO Programms stattfinden soll.

Also bitte, demnächst dann richtig kommentieren.

[Johannes F. (jofe)]

Norbert schrieb:
> Nämlich dass ein offener, extrem
> hochohmiger, schwebender Eingang nicht wieder automagisch auf Low fällt
> wenn ein zuvor angelegtes High weggenommen wird.

OK, also quasi ein dauerhafter interner Pull-Up statt -Down, hatte ich 
wohl verwechselt.

Norbert schrieb:
> Das kann man mit einem externen Pull-Down von ca. 8kΩ…9kΩ beheben.

"8…9 kΩ" sind für mich aber nicht "extrem hochohmig". Insofern ist das 
schon ein relativ schwerwiegender Silicon Bug, finde ich.

[Norbert (der_norbert)]

Johannes F. schrieb:
> Norbert schrieb:
>> Nämlich dass ein offener, extrem
>> hochohmiger, schwebender Eingang nicht wieder automagisch auf Low fällt
>> wenn ein zuvor angelegtes High weggenommen wird.
>
> OK, also quasi ein dauerhafter interner Pull-Up statt -Down, hatte ich
> wohl verwechselt.

Nein, es bedeutet dass sich ein frei *schwebender* Eingang im Megaohm 
Bereich anders verhält als beim 2040.
Er verhält sich eher wie ein nicht mehr zurück schnappender 
Schmitt-Trigger.
Wie gesagt, frei in der Luft schwebend (oder wenn sehr hochohmig 
angesteuert)

> Norbert schrieb:
>> Das kann man mit einem externen Pull-Down von ca. 8kΩ…9kΩ beheben.
>
> "8…9 kΩ" sind für mich aber nicht "extrem hochohmig".

Das habe ich so auch nicht geschrieben.

> Insofern ist das
> schon ein relativ schwerwiegender Silicon Bug, finde ich.

Das sei dir unbenommen. Ein offen in der Luft baumelnder Draht kann dann 
Probleme verursachen.

Allerdings, wenn der Eingang von irgend etwas im wenige µA Bereich 
angesteuert wird, ist das Problem verschwunden.

[Georg M. (g_m)]

Für erhöhte Sicherheitsanforderungen (also nicht für Bastler):

The AVR® SD Family

https://www.microchip.com/en-us/products/microcontrollers-and-microprocessors/8-bit-mcus/avr-mcus/avr-sd