ATMega Auslaufmodell?

[Stephan R. (Firma: FHK) (nautosteer)]

Hallo!

So etwa vor 24 Jahren habe ich mir bei Conrad die ersten Mikrocontroller 
Module gekauft, dann einen myavr-Koffer für viel Geld und schließlich 
mit dem STK600 viel Freude gehabt. Karl-Heinz Buchegger mit etlichen 
Fragen gelöchert und wunderbare Antworten erhalten.
Seit gut fünf Jahren habe ich dafür keine Zeit mehr und ich verfolge die 
Entwicklung nicht weiter.


Dann stelle ich gerade fest, dass hier im Forum im Jahr 2024 der Begriff 
ATMega 9 mal erwähnt wurde, im letzten Jahr 18 Mal und im Jahr 2022 30 
Mal.. kann es sein dass ATMmega keine Rolle mehr spielt?

Mit herzlichen Grüßen

[Stephan R. (Firma: FHK) (nautosteer)]

Drei Minuten später schreibt jemand etwas zum Atmega 88..

[H. H. (hhinz)]

Stephan R. schrieb:
> Dann stelle ich gerade fest, dass hier im Forum im Jahr 2024 der Begriff
> ATMega 9 mal erwähnt wurde, im letzten Jahr 18 Mal und im Jahr 2022 30
> Mal.. kann es sein dass ATMmega keine Rolle mehr spielt?

Die Suchfunktion ist ziemlich schlecht.

[Stephan R. (Firma: FHK) (nautosteer)]

H. H. schrieb:
> Die Suchfunktion ist ziemlich schlecht.

Denn präzisiere ich mal meine gefühlte Beobachtung: kann es sein, dass 
sich niemand mehr drüber freut dass eine LED blinkt, ein String 
fehlerfrei über die UART gesendet wird oder ein Poti sauber von 0 bis 
255 eingelesen wird?

[H. H. (hhinz)]

Stephan R. schrieb:
> Denn präzisiere ich mal meine gefühlte Beobachtung: kann es sein, dass
> sich niemand mehr drüber freut dass eine LED blinkt, ein String
> fehlerfrei über die UART gesendet wird oder ein Poti sauber von 0 bis
> 255 eingelesen wird?

Die Anfänger bekommen das mittlerweile auch ohne Hilfe des Forums hin.

[Michael B. (laberkopp)]

Stephan R. schrieb:
> kann es sein dass ATMmega keine Rolle mehr spielt?

Na ja, Atmel wurde von Microchip übernommen, es gibt viele neue 
Konkurrenz vom ESP über STM8/STM32 über RP2040 über TeenSy über Padauk, 
also AVR ist weniger wichtig, selbst Arduino entdeckt inzwischen andere 
Prozessoren.

Beim AVR gibt es nur einen mit LCD Treiber, keinen mit LED Treiber, nur 
langsame A/D Wandler, da helfen die inzwischen 286 AVR Modelle nicht 
weiter.

[Arduino F. (Firma: Gast) (arduinof)]

Stephan R. schrieb:
> Denn präzisiere ich mal meine gefühlte Beobachtung: kann es sein, dass
> sich niemand mehr drüber freut dass eine LED blinkt, ein String
> fehlerfrei über die UART gesendet wird oder ein Poti sauber von 0 bis
> 255 eingelesen wird?

Suchst du Arduino?
Die Arduinowelt ist voll mit ATMegas.

[Monk (Gast)]

Stephan R. schrieb:
> Dann stelle ich gerade fest, dass hier im Forum im Jahr 2024 der Begriff
> ATMega 9 mal erwähnt wurde

Kann nicht sein, du hast falsch gezählt.

In den vielen Jahren wurde die Produktion von ein paar ATmega Modellen 
eingestellt, dafür sind neue hinzu gekommen. Über ihre Verfügbarkeit 
muss man sich keine Sorgen machen.

> kann es sein, dass sich niemand mehr drüber freut dass eine LED blinkt?

Den Eindruck hatte ich in der Tat auch.

Hoch komplexe Geräte sind inzwischen einfach zu benutzen, jedes Kind hat 
eins in der Tasche. Im Internet werden ständig komplizierte Basteleien 
als "ganz einfach" präsentiert. Menschen (nicht nur Kinder) 
unterschätzen dadurch die Komplexität und bilden sich ein, sie könnten 
sich "alles" einfach so mal eben aus dem Ärmel schütteln.

In einem Ferienprojekt habe ich allerdings erlebt, wie Pädagogen die 
Kids erfolgreich auf den Boden der Tatsachen herunter geholt haben, so 
dass sie sich doch über einfache Projekte (wie LED Blinker) freuen 
konnten.

[Rolf (rolf22)]

Monk schrieb:
> In einem Ferienprojekt habe ich allerdings erlebt, wie Pädagogen die
> Kids erfolgreich auf den Boden der Tatsachen herunter geholt haben, so
> dass sie sich doch über einfache Projekte (wie LED Blinker) freuen
> konnten.

In einer Jugendeinrichtung hier im Viertel haben welche aus der Gruppe 
der 10- bis 12-Jährigen versucht, antriebslose primitive Spielzeugautos 
zu elektrifizieren. Die haben Batterien oben draufgelegt und mit 
Drahtstücken festgeschnürt. Komischerweise fuhren die Autos trotzdem 
nicht von alleine. :-) Einer kam mit dem Vorschlag, man solle die 
Batterien einfach noch fester draufbinden. "Motor einbauen? Häh??"

Gut, war in einem sozialen Brennpunkt mit Kindern aus bildungsfernen 
Familien. Aber die konnten alle darüber diskutieren, was am neuen iPhone 
so cool ist.

[Chris V. (nagut)]

Stephan R. schrieb:
> kann es sein, dass
> sich niemand mehr drüber freut dass eine LED blinkt, ein String
> fehlerfrei über die UART gesendet wird oder ein Poti sauber von 0 bis
> 255 eingelesen wird?

Ich denke das wird so sein.

Selbst etwas eigentlich sehr cooles, wie z.B. sein eigenes Senso-Spiel ( 
https://de.wikipedia.org/wiki/Senso_(Spiel) ) mit einem Mikrocontroller 
zu programmieren verblasst vor den Möglichkeiten eines heutzutage 
allgegenwärtigen Smartphones.


Monk schrieb:
> In einem Ferienprojekt habe ich allerdings erlebt, wie Pädagogen die
> Kids erfolgreich auf den Boden der Tatsachen herunter geholt haben, so
> dass sie sich doch über einfache Projekte (wie LED Blinker) freuen
> konnten.

Das finde ich sehr interessant! Kannst Du erzählen, wie die das 
geschafft haben?

[Monk (Gast)]

Chris V. schrieb:
> Das finde ich sehr interessant! Kannst Du erzählen, wie die das
> geschafft haben?

Leider nicht (habe den Trick nicht erkannt), aber ich zolle ihnen dafür 
großen Respekt.

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

Stephan R. schrieb:
> Dann stelle ich gerade fest, dass hier im Forum im Jahr 2024 der Begriff
> ATMega 9 mal erwähnt wurde, im letzten Jahr 18 Mal und im Jahr 2022 30
> Mal.. kann es sein dass ATMmega keine Rolle mehr spielt?

Und wayne interessierts? Ob 5 Beiträge zum ATMega oder 100, was spielt 
das für eine Rolle? Und macht das einen µC zum "Auslaufmodell"?

In Foren wird typischerweise der neueste heiße Scheiß bequatscht. Der 
ATMega ist aber alles andere als neu. Wie man damit eine LED zum Blinken 
bringt ist inzwischen in Hunderten Tutorials nachzulesen. Kein Wunder 
daß die Anzahl neuer Threads mal nachläßt.

Oder war das gar keine ernstgemeinte Frage, sondern der 1000ste Versuch, 
einen Flamewar lostzutreten mit der Hypothese vom Sterben der 8-Bit µC?

[Georg M. (g_m)]

Es ist klar, dass die 32-Bit-µCs schon längst auf dem Vormarsch sind.
Neulich habe ich bei Mouser entdeckt:
MSPM0C1104SDSGR
Arm® 32-bit Cortex®-M0+ CPU, 24MHz
8-pin WSON 2x2mm
0,64 € (0,272 € bei 1000 St.)


Die 8-Bit-µCs sind aber nach wie vor völlig ausreichend für kleinere 
Aufgaben, für die Steuerung von kleineren Anlagen, wie z.B.:

https://www.youtube.com/shorts/7zhuq347VmQ

[Frank O. (frank_o)]

Das ist doch eigentlich völlig egal für Hobby.
Bevor ich irgend eine Schaltung baue, um ein Relais unter Verzögerung zu 
schalten oder auf `was auch immer´ zu reagieren, dafür reicht mir immer 
noch ein ATtiny10.
Und wenn etwas mit einem 230MHz Boliden einfacher geht, dann mache ich 
das damit. Es spielt keine Rolle, ob das für dies eine Teil zwei oder 
drei Euro teurer ist.

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

Hat hier irgend jemand gesagt, die AVRs bzw. 8-Bit µCs könnten nichts?

https://www.youtube.com/watch?v=vPZ5ByIxiFM

Und das ist 'nen kleiner ATMega88...

[Gerhard O. (gerhard_)]

Moin,

Mein Wort zum Sonntag:-)

Für viele MSR Aufgaben sind 8-Bit uC nach wie vor gut geeignet. Aber 
vergleichen mit den Anwendungen und Geräten unserer Tage darf man sie 
natürlich nicht.

Jemand, den ich kenne, versuchte eine 320x240 TFT Touch Screen GUI 
Anwendung auf einen Mega2560. Es funktionierte, aber es funktionierte, 
wenn man es mit modernen Sachen vergleicht, ziemlich müde und 
lahmarschig. Ganz klar ein Fall für eine schnelle 32-bit Maschine mit 
Graphik Controller.

Viele Leute wollen es wahrscheinlich mit der Leistung von modernen 
Geräten gleichtun. Nur übersieht man leicht, daß man dazu weitaus 
bessere HW braucht und komplexe SW. Um die GUI Zügigkeit eines 
Smartphones oder Tablet zu erreichen, ist eben ein ganz andere Liga und 
Thema.

Aber Anwendungen, wo ein ATMega und andere 8-Bit uC wie die Sonne 
scheinen, gibt es noch. Zumindest in meinem Leben. In der Firma gibt es 
nur noch 32-Bit Projekte und man gewöhnt sich daran. Aber mehr Spass 
machen die einfacheren uC im Hobby Bereich schon. Trotzdem kommt es auch 
dort auf den Zielbereich an.

Bei einfacheren Projekten, kommt man, sofern man will, mit keinen oder 
nur ein paar Bibliotheken aus. Die komplexen Anwendungen lassen sich 
heutzutage kaum noch komplett selber stricken. Speziell, wenn 
komplizierte Communication Stacks und GUI und RTOS notwendig sind. Dank 
der vielen Beispiele und Bibliotheken findet auch derjenige für solche 
Projekte eine Starthilfe.

Es muß halt jeder selber wissen, inwieweit er sich damit befassen will. 
In meinem Alter bevorzuge ich überschaubare, einfachere Sachen, die 
nicht Monate meines Lebens auffressen. Mir ist die HW Funktion wichtiger 
als der Coolness Faktor.

UC sollten für mich nicht der optische Fokus eines Geräts sein, sondern 
die Implementation, die Verwirklichungen eines Projekts erst möglich 
machen. Wenn sie da ganz tief drinnen zuverlässig werkeln und die 
Anwendung wie eine zufriedene Katze schnurrt, bin ich glücklich und 
zufrieden. Was mich betrifft, bevorzuge ich Bedienungskonzepte wie 
früher, wo jedes Frontplatten Element eine direkte Funktion ausübt.

Es ist ja ganz gut und schön, alles mit Touchscreen und GUI zu 
verwirklichen, um die Kosten verpönten Frontplatten Bedienelemente zu 
ersparen. Andrerseits ist man heutzutage gezwungen mit Auge, Finger, und 
GUI alles zu bedienen. Wenn da irgendein Glied in der Kette mal nicht 
funktioniert, passiert gar nichts, wenn man mal von Sprachsteuerung 
absieht. Mir ist aber Haptik lieber, die man ohne immer hinsehen zu 
müssen, mit Armeslänge noch intuitiv gut bedienen kann.

Autos mit Touchscreen Steuerung vieler traditioneller Funktionen, z.B. 
sind mir ein Greuel. Aber es war ja vorauszusehen, daß ehrgeizige 
Entwickler ohne Vernunft unsere Autos in immer kompliziertere und 
Systemabhängige rollende Computer verwandeln wollten und die Gängelei 
der User auf die Spitze trieben und es noch immer tun. Alles im Namen 
der sogenannten Sicherheitsverbesserung. Ich spreche jetzt nur von 
bestimmten Sachen. Daß man wertvolle Verbesserungen innovierte, wird 
hier nicht kritisiert. Aber wie immer übertreibt man es. Aber so ist der 
Gang der Welt. Die Verdongelung vieler Autobaugruppen, um Reparatur zu 
erschweren, ist nicht unbedingt im Interesse der Kunden. Aber, man hat 
gute technische Gründe dafür, auch wenn es dem Kunden reparaturmässig 
das Leben schwer macht.

Wenn man auch nicht allen Fortschritt bejahen muß. Eines darf man nicht 
übersehen: wir können genau wählen, welche Art der Technik für uns am 
zielführensten ist. Man kann es so einfach wie möglich oder ultra-cool 
kompliziert machen. Ganz wie beliebt.

Und das Beste ist die leichte Zugänglichkeit der Entwicklungs-Werkzeuge 
und die Billigkeit der HW. Wer hätte es in 1980 für möglich gehalten, 
daß man heutzutage einen fähigen kleinen uC unter $1 erstehen kann und 
man vielfach mit freier SW dazu arbeiten kann. Damals, bevor dem PC, war 
da ausser in den Firmen, alles unerschwinglich.  Das ist, in meinen 
Augen der tiefe Hintergrund und Vorteil unseres Zeitalters. Man sollte 
dankbar sein, daß praktisch der ärmste Schüler oder Student, hier mittun 
kann ohne lange Taschengeld dafür sparen zu müssen.

Also freut Euch am ATMEGA. Auch mit dem kann man viele Erfolge feiern 
und tolle Sachen zaubern. Nur vergleicht ihn nicht mit den letzten 
Schreien der Gegenwart. Das wäre nämlich unfair und unpassend.

Duck und weg,
Gerhard

[Markus M. (Firma: EleLa - www.elela.de) (mmvisual)]

Ben B. schrieb:
> Hat hier irgend jemand gesagt, die AVRs bzw. 8-Bit µCs könnten nichts?
>
> https://www.youtube.com/watch?v=vPZ5ByIxiFM
>
> Und das ist 'nen kleiner ATMega88...

Dem muss ich zustimmen. Die 8-Bitter sind durchaus zu was zu gebrauchen.

Vor einigen Jahrzehnte war mein erster Computer ein Schneider CPC6128. 
Mit Diskettenlaufwerk und da war so ziemlich alles machbar:
- Textverarbeitung
- Bildbearbeitung
- Jede Menge Spiele
- CP/M
- Turbopascal
- Drucken
- Basic war im ROM schon drin.
Das war ein Z80 mit 4MHz Takt und 2x 64KB Ram. Wovon der Grafikspeicher 
16KB war.

Ist jetzt zwar kein Atmega, jedoch auch 8 Bit.

[Falk B. (falk)]

Ben B. schrieb:
> https://www.youtube.com/watch?v=vPZ5ByIxiFM
>
> Und das ist 'nen kleiner ATMega88...

Extrem beeindruckend, auch wenn der Kram über 10 Jahre alt ist. Aber 
solche Demos sind Ausnahmen. Normale Anwendungen und die Masse der 
Programmierer, auch gute, kommen dort nicht ran. Müssen sie aber auch 
gar nicht!

[Waldi M. (Gast)]

Axel S. schrieb:
> sondern der 1000ste Versuch, einen Flamewar lostzutreten mit der
> Hypothese vom Sterben der 8-Bit µC?

Wird halt immer wieder versucht :)

Falk B. schrieb:
> Aber solche Demos sind Ausnahmen.

Egal. Sie zeigen was mit 8-Bit möglich war ist bleibt.

Stephan R. schrieb:
> dass hier im Forum im Jahr 2024 der Begriff ATMega 9 mal erwähnt wurde,
> im letzten Jahr 18 Mal und im Jahr 2022 30 Mal.. kann es sein dass
> ATMmega keine Rolle mehr spielt?

Du ziehst falsche Schlussfolgerungen.
Der Foren-Inhalt zum Thema ist unerschöpflich. Muss man das Hundert 
Jahre lang immer wieder neu durchkauen? Was sich vergleichsweise schnell 
erschließt muss auch nicht so oft nachgefragt werden.

[Monk (Gast)]

Obwohl es Bagger gibt bevorzuge ich bei meinen Löchern doch meistens die 
Schaufel. Was nicht heißen soll, daß Bagger sinnlos seien.

[Gerhard O. (gerhard_)]

Falk B. schrieb:
> Ben B. schrieb:
>> https://www.youtube.com/watch?v=vPZ5ByIxiFM
>>
>> Und das ist 'nen kleiner ATMega88...
>
> Extrem beeindruckend, auch wenn der Kram über 10 Jahre alt ist. Aber
> solche Demos sind Ausnahmen. Normale Anwendungen und die Masse der
> Programmierer, auch gute, kommen dort nicht ran. Müssen sie aber auch
> gar nicht!

Jetzt liege ich zerschmettert und zerstört am Boden! Ich glaube, ich 
gebe es besser auf, das uC Werkeln...

[Yalu X. (yalu) (Moderator)]

Gerhard O. schrieb:
> Jemand, den ich kenne, versuchte eine 320x240 TFT Touch Screen GUI
> Anwendung auf einen Mega2560. Es funktionierte, aber es funktionierte,
> wenn man es mit modernen Sachen vergleicht, ziemlich müde und
> lahmarschig. Ganz klar ein Fall für eine schnelle 32-bit Maschine mit
> Graphik Controller.

Zumal man zum Preis eines nackten ATmega2560 beim Chinesen schon das
komplette 320×240-Touchdisplay inkl. ESP32, viel RAM, viel Flash, WLAN,
Bluetooth, Sound und SD-Kartenleser fertig aufgebaut bekommt, so dass
man sich direkt der Softwareentwicklung zuwenden kann.

Dank LVGL lässt sich sich mit sehr überschaubarem Aufwand ein GUI
zusammenpappen, dass sich hinsichtlich Look-and-Feel kaum hinter
"modernen" Produkten zu verstecken braucht.

Hier sind ein paar interaktive Demos dazu:

  https://lvgl.io/demos

Ich habe noch einen Vorrat verschiedener AVRs herumliegen und werde
diese auch nach und nach für irgendwelche Spaßprojekte aufbrauchen.
Angesichts der Tatsache, dass man zum Preis eines ATtiny13 ein fertig
aufgebautes RP2040-Modul in Briefmarkengröße bekommt, werde ich den
AVR-Vorrat aber nicht wieder auffüllen.

[Gerhard O. (gerhard_)]

Yalu X. schrieb:
> Gerhard O. schrieb:
>> Jemand, den ich kenne, versuchte eine 320x240 TFT Touch Screen GUI
>> Anwendung auf einen Mega2560. Es funktionierte, aber es funktionierte,
>> wenn man es mit modernen Sachen vergleicht, ziemlich müde und
>> lahmarschig. Ganz klar ein Fall für eine schnelle 32-bit Maschine mit
>> Graphik Controller.
>
> Zumal man zum Preis eines nackten ATmega2560 beim Chinesen schon das
> komplette 320×240-Touchdisplay inkl. ESP32, viel RAM, viel Flash, WLAN,
> Bluetooth, Sound und SD-Kartenleser fertig aufgebaut bekommt, so dass
> man sich direkt der Softwareentwicklung zuwenden kann.
>
> Dank LVGL lässt sich sich mit sehr überschaubarem Aufwand ein GUI
> zusammenpappen, dass sich hinsichtlich Look-and-Feel kaum hinter
> "modernen" Produkten zu verstecken braucht.
>
> Hier sind ein paar interaktive Demos dazu:
>
>   https://lvgl.io/demos
>
> Ich habe noch einen Vorrat verschiedener AVRs herumliegen und werde
> diese auch nach und nach für irgendwelche Spaßprojekte aufbrauchen.
> Angesichts der Tatsache, dass man zum Preis eines ATtiny13 ein fertig
> aufgebautes RP2040-Modul in Briefmarkengröße bekommt, werde ich den
> AVR-Vorrat aber nicht wieder auffüllen.

Naja, es kommt halt drauf an, was man verwirklichen möchte. Bei mir 
liegt der Schwerpunkt meiner Interessen im tief "embedded" Bereich, wie 
MSR und Steueraufgaben, wo ein GUI Bildschirm nicht unbedingt vorhanden 
ist und alles meist vom PC parametrisiert wird. Ein Charakter Display 
und ein paar Tasten oder Encoder ist da eher alles was dann vorhanden 
ist. Ich bin da eher ein "Outlyer" und nicht unbedingt Mainstream. Bei 
mir ist meist eine Menge an Peripherie Schaltung um den uC herum.

Ich sehe für mich durchaus noch ein Aufgabenfeld für 8-Bitter aller Art. 
32-bit, nur wo es zwingend notwendig oder zweckmässig ist. Aber das kann 
ja jeder halten so wie er will. Auswahl an "most appropriate" Technik 
gibt es ja mehr als genug.

[H. H. (hhinz)]

Und 6502 ist ja eh viel besser...

[Falk B. (falk)]

Waldi M. schrieb:
> Wird halt immer wieder versucht :)
>
> Falk B. schrieb:
>> Aber solche Demos sind Ausnahmen.
>
> Egal. Sie zeigen was mit 8-Bit möglich war ist bleibt.

Ja und? So wie ein Tauchgang in Apnoe auf 214m oder ein Evel Knievel 
Stunt! Sehr praxisrelevant!

[Falk B. (falk)]

Gerhard O. schrieb:
> Jetzt liege ich zerschmettert und zerstört am Boden! Ich glaube, ich
> gebe es besser auf, das uC Werkeln...

Wirf dich in den Staub, du Unwürdiger!

https://www.youtube.com/watch?v=hTid2cExqbs

Man muss schon alt sein, um das noch zu kennen und witzig zu finden 
;-)))

[Falk B. (falk)]

Gerhard O. schrieb:
> ist. Ich bin da eher ein "Outlyer" und nicht unbedingt Mainstream.

Solang du kein "outliar" bist, ist alles OK! ;-)

> Ich sehe für mich durchaus noch ein Aufgabenfeld für 8-Bitter aller Art.
> 32-bit, nur wo es zwingend notwendig oder zweckmässig ist.

32 Bitter sind heute praktisch so einfach nutzbar wie 8 Bitter. Klar 
macht man da nicht mehr mit Assembler rum sondern nutzt viele Frameworks 
und Libs. Das ist aber voll OK und auch sinnvoll.

[Falk B. (falk)]

H. H. schrieb:
> Und 6502 ist ja eh viel besser...

4004!!!!

[Jochen D. (joe_d1)]

Ich gebe mal meinen Senf aus der Sicht eines Hobbyisten:

Stephan R. schrieb:
> kann es sein dass ATMmega keine Rolle mehr spielt?

Kommt drauf an was Du kannst, welches Equipment Du hast und was Du 
machen möchtest. Wenn ich z.B. wie 2006 ausschließlich mit DIP hantieren 
würde, so würde ein Atmega (für mich) auch heute noch eine Rolle 
spielen. Leider könnte ich dann 99% von dem was ich heute mache gar 
nicht umsetzen...

Zwischenzeitlich ist es aber so das sehr viele von mir verwendeten 
externen Baugruppen ausschließlich in SMD erhältlich sind. Anfangs habe 
ich verzweifelt versucht abgekündigte DIP-Bauteile noch zu erhalten die 
sich dann schlussendlich als nutzlose China-Fakes herausstellten. 
Heutzutage kommt (bei mir) DIP nur noch dort vor wo es Sinn macht 
(manche Steckverbinder, teilweise Elkos) - der Rest ist SMD.

In meinem nächsten Projekt benötige ich z.B. einen 12-Bit ADC und ein 
CAN-Businterface. Optional noch einen USB-Port. Gefunden habe ich da 
inzwischen was bei STM32 - sogar mit allen 3 Schnittstellen in einer 
48-Pin MCU. Die gibt es aber weder mit 5V noch in DIP ;)

Sowas hab ich nicht bei AVR gefunden... und obwohl ich alles für das 
"AVR-Universum" habe - funktionierende Bibliotheken für UART, I2C, 
Modbus - werde ich als Nächstes einen STM32 verwenden. Und je nachdem 
wie mir das gefällt kann es sogar sein das der ATMega bald für mich 
keine Rolle mehr spielt ;)

[Christoph M. (mchris)]

Das Craft Demo ist tatsächlich das beeindruckendste, was auf einem 
Atmega88 möglich ist.
Es ist aber wirklich nicht praxisrelevant, weil Linus Akesson ( 
https://www.linusakesson.net/ ) viele Tricks aus der Demo-Szene 
angewandt hat und für das Projekt einen eigenen Compiler geschrieben 
hat.
Der Video-Speicher mit 1KB ist eigentlich viel zu klein zum speichern 
eines VGA-Bildes, deshalb wird alles in Echtzeit erzeugt und mit 
Wiederholungen gearbeitet.

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

> 4004!!!!
Der kann nur 4 Bit, Du bist raus!

;)

[Frank O. (frank_o)]

Yalu X. schrieb:
> Angesichts der Tatsache, dass man zum Preis eines ATtiny13 ein fertig
> aufgebautes RP2040-Modul in Briefmarkengröße bekommt, werde ich den
> AVR-Vorrat aber nicht wieder auffüllen.

By the way: Wir haben, so glaube ich, alle den Hang zu zu viel Vorrat.
Ich habe heute Badartikel (Seife, Duschgel ....) aussortiert. Ungefähr 
25 Liter Volumen. Ich möchte gar nicht erst wissen wie viel Geld das 
war.
Irgendwann hieß es, dass es bald keine Tiny10 mehr gibt. Na ratet mal 
wie viel ich habe ...

[Christoph M. (mchris)]

Ben B. (Firma: Funkenflug Industries) (stromkraft)
>Der kann nur 4 Bit, Du bist raus!

Nein, er kann viele Bits:
https://hackaday.com/2024/09/21/theres-no-lower-spec-linux-machine-than-this-one/

[Gerhard O. (gerhard_)]

Falk B. schrieb:
> Gerhard O. schrieb:
>> Jetzt liege ich zerschmettert und zerstört am Boden! Ich glaube, ich
>> gebe es besser auf, das uC Werkeln...
>
> Wirf dich in den Staub, du Unwürdiger!
>
> https://www.youtube.com/watch?v=hTid2cExqbs
>
> Man muss schon alt sein, um das noch zu kennen und witzig zu finden
> ;-)))

Das erinnert an hier:

https://www.vulture.com/2011/12/wayne-shuster-canadian-comedy-cornball-supergods.html

[Georg M. (g_m)]

Stephan R. schrieb:
> Seit gut fünf Jahren habe ich dafür keine Zeit mehr und ich verfolge die
> Entwicklung nicht weiter.

Atmel wurde 2016 von Microchip gekauft, und die neueren 
8-Bit-AVR-Mikrocontroller heißen nicht mehr ATmega, sondern AVRxxxxxx, 
z.B. AVR64DB48, AVR32DD32.

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

Georg M. schrieb:

> Atmel wurde 2016 von Microchip gekauft, und die neueren
> 8-Bit-AVR-Mikrocontroller heißen nicht mehr ATmega, sondern AVRxxxxxx,
> z.B. AVR64DB48, AVR32DD32.

Es gibt auch etliche ATmega mit der "neuen" Architektur. Siehe:

https://ww1.microchip.com/downloads/en/DeviceDoc/megaAVR0-series-Family-Data-Sheet-DS40002015B.pdf

Aber tatsächlich wurden einerseits die AVR-Dx immer weiter geschrinkt 
und andererseits die neuen ATtiny immer weiter aufgeblasen, so dass 
eigentlich keine Lücke dazwischen mehr verbleibt, in die neue ATmega 
noch zielen könnten. Könnte also wirklich gut sein, dass da nix mehr 
kommt.

Aber letztlich ist es ja auch egal, wie die Dinger nun genau heißen.

[Manfred P. (pruckelfred)]

Gerhard O. schrieb:
> Jemand, den ich kenne, versuchte eine 320x240 TFT Touch Screen GUI
> Anwendung auf einen Mega2560.

Das Problem kommt, wenn der µC noch mehr zu tun hat. Ein Arduino mit 
AT328 und kleinem OLED 128x64 funktioniert. SD-Karte ist auch kein 
Problem, ebenso das Messen von Spannungen. Ich bin dann aufs Maul 
gefallen, weil seine Ressourcen nicht genügen, alles gemeinsam 
auszuführen.

Mein Akutester liegt bei 99% Programmspeicher, nachdem ich stundenlang 
Code optimiert habe, um ihn überhaupt noch rein zu bekommen.

Gerhard O. schrieb:
> Naja, es kommt halt drauf an, was man verwirklichen möchte. Bei mir
> liegt der Schwerpunkt meiner Interessen im tief "embedded" Bereich, wie
> MSR und Steueraufgaben, wo ein GUI Bildschirm nicht unbedingt vorhanden
> ist und alles meist vom PC parametrisiert wird. Ein Charakter Display
> und ein paar Tasten oder Encoder ist da eher alles was dann vorhanden
> ist.

In dem Bereich spiele ich auch, Messen und protokollieren. Da ist ein 
Textdisplay mit eigenem Zeichensatz problemlos, Chinese 1602 oder 2004. 
Hat er leider nicht mit kleineren Abmessungen und zu Akkubetrieb passen 
die auch nicht gut.

[M.A. S. (mse2)]

Gerhard O. schrieb:
> Duck und weg,
brauchst Du gar nicht, hast Du gut gesagt!
Beileibe nicht jede Anwendung hat ein Display mit GUI.

[Pandur S. (jetztnicht)]

Gibt's eigentlich eine 32bit Familie, welche auf Bare-Metal betrieben 
werden kann ? Also ohne Betriebssystem, ohne Treiber ? Und mit welchen 
Tools ?
Was ich mir bisher anschaute war eher duenn, wenn man die Register 
beschrieben haben wollte. Deren zugriff muesste dann auch von der 
toolchain unterstuetzt werden.

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

Pandur S. schrieb:
> Gibt's eigentlich eine 32bit Familie, welche auf Bare-Metal betrieben
> werden kann ?

Natürlich kannst du prinzipiell erstmal alles bare metal betreiben.

Gerade bei den diversen Cortex-M ist das kein Problem. Ist dann nur eine 
Frage, ab irgendeiner Komplexität der MCU hat es durchaus Sinn, sich 
bereits vorgefertigter Blöcke zu bedienen.

Also für einen Cortex-M0 ist das immer noch deutlich praktikabler als 
für einen Cortex-M7, und Cortex-A willst du sicher nicht mehr komplett 
von der Pike auf selbst bearbeiten – könnte sein, dass deine Lebenszeit 
sonst abgelaufen ist, bevor du etwas Sinnvolles damit angestellt hast.

[Tim T. (tim_taylor)]

Falk B. schrieb:
> Gerhard O. schrieb:
>> ist. Ich bin da eher ein "Outlyer" und nicht unbedingt Mainstream.
>
> Solang du kein "outliar" bist, ist alles OK! ;-)
>
>> Ich sehe für mich durchaus noch ein Aufgabenfeld für 8-Bitter aller Art.
>> 32-bit, nur wo es zwingend notwendig oder zweckmässig ist.
>
> 32 Bitter sind heute praktisch so einfach nutzbar wie 8 Bitter. Klar
> macht man da nicht mehr mit Assembler rum sondern nutzt viele Frameworks
> und Libs. Das ist aber voll OK und auch sinnvoll.

Jop, genau das war auch meine Erkenntnis, nachdem ich es mit Assembler 
und Übertakten auf 25,175 MHz endlich geschafft hatte, auf einem AtMega 
mit voller VGA Auflösung von 640x480 Pixeln einen Text auszugeben. Das 
gleiche Spiel auf einem STM32, ein paar Jahre später, war dagegen nur 
eine kleine Fingerübung, nicht zuletzt wegen dem DMA-Transfer auf die 
SPI-Schnittstelle. Seitdem nutze ich eigentlich von Atmel nur noch die 
Tiny13A oder einen Mega328P in einem Arduino Uno wegen der einfachen 
Verfügbarkeit für einfache LED Spielereien und wegen der 5V Toleranz. 
Für alles Andere einfach einen STM32 mit der HAL in der CubeIDE.

[Frank O. (frank_o)]

Tim T. schrieb:
> Für alles Andere einfach einen STM32 mit der HAL in der CubeIDE.

Und das geht mittlerweile gut?

[Georg M. (g_m)]

Tim T. schrieb:
> Seitdem nutze ich eigentlich von Atmel nur noch die Tiny13A

Der kann fast nichts. Zum Vergleich ein anderer 8-Pin AVR:

ATtiny412

● Two-cycle hardware multiplier
. . . . . 
. . . . .
● 16-bit Timer/Counter type A (TCA) with a dedicated period register and three compare channels
● 16-bit Timer/Counter type B (TCB) with input capture
● 12-bit Timer/Counter type D (TCD) optimized for control applications
● 16-bit Real-Time Counter (RTC) running from an external crystal, external clock, or internal RC oscillator
. . . . .
. . . . .
● USART with fractional baud rate generator, auto-baud, and start-of-frame detection
● host/client Serial Peripheral Interface (SPI)
● Two-Wire Interface (TWI) with dual address match, Philips I2C compatible
. . . . . 
. . . . .
● 8-bit Digital-to-Analog Converter (DAC)
● Multiple voltage references
● Event System (EVSYS) for CPU independent and predictable inter-peripheral signaling
● External interrupt on all general purpose pins

https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/ATtiny212-214-412-414-416-DataSheet-DS40002287A.pdf

[Mi N. (msx)]

Pandur S. schrieb:
> Gibt's eigentlich eine 32bit Familie, welche auf Bare-Metal betrieben
> werden kann ? Also ohne Betriebssystem, ohne Treiber ?

Deine Frage finde ich etwas erschreckend. Selber programmiere ich die 
STM32 und RP2040 grundsätzlich mit direkten Registerzugriffen. Das geht 
recht einfach und man weiß, was man tut. Zudem sind die Register im 
Ref.-Manual gut beschrieben.
Gut, ich bin zu faul mir die Doku zu HAL durchzulesen ;-)

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Frank O. schrieb:
> Tim T. schrieb:
>> Für alles Andere einfach einen STM32 mit der HAL in der CubeIDE.
>
> Und das geht mittlerweile gut?

Ja, mittlerweile ist STM32CubeMX zur Erzeugung der Grundstruktur ganz 
brauchbar, auch wenn es natürlich - wie jede halbwegs komplexe Software 
- ein paar kleine Bugs hat.

[Chris V. (nagut)]

Mi N. schrieb:
> Pandur S. schrieb:
>> Gibt's eigentlich eine 32bit Familie, welche auf Bare-Metal betrieben
>> werden kann ? Also ohne Betriebssystem, ohne Treiber ?
>
> Deine Frage finde ich etwas erschreckend.

So eine Frage kommt auf, wenn man den Erstkontakt z.B. mit einem ESP32 
hatte.

WLAN, Bluetooth, Netzwerk ... Wenn man das Bare-Metal machen wollen 
würde, wäre man in vielleicht einem Jahr Vollzeit fertig aber wäre dann 
auch ein hochspezialisierter Experte. :)

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Mi N. schrieb:
> Deine Frage finde ich etwas erschreckend. Selber programmiere ich die
> STM32 und RP2040 grundsätzlich mit direkten Registerzugriffen. Das geht
> recht einfach und man weiß, was man tut. Zudem sind die Register im
> Ref.-Manual gut beschrieben.

Bei nur etwas größeren STM32 (genauso natürlich auch bei äquivalenten 
Serien anderer Hersteller) übersieht man aber sehr schnell die 
Abhängigkeiten zwischen verschiedenen Funktionsblöcken. Bei der Arbeit 
mit STM32CubeMX ist es äußerst ratsam, sich (mit Hilfe eines 
Versionskontrollsystems o.ä.) genau anzuschauen, welche 
Konfigurationsänderungen zu welchen Quellcodeänderungen führen. Bei 
händischer Programmierung hätte man definitiv nicht alles im Überblick, 
insbesondere was irgendwelche Parameter bei der Taktgenerierung und 
Verteilung angeht. Und auch beim Wechsel des Prozessormodells sieht zwar 
der Großteil der Codes gleich aus, aber es gibt halt doch wichtige, 
subtile Änderungen.

Im Codegenerator sind auch Unmengen an Workarounds für spezifische 
Maskenversionen einzelner Bausteine enthalten, die man sich sonst auch 
nur äußerst mühsam anhand von Errata Sheets usw. zusammensuchen müsste.

Allein schon bei der Schaltungsentwicklung und dem Layout hilft 
STM32CubeMX ganz ungemein, eine konsistente Pinbelegung zu finden, da 
man beim Pintausch auch sofort die Auswirkungen sieht.

> Gut, ich bin zu faul mir die Doku zu HAL durchzulesen ;-)

Das mache ich auch nur im konkreten Fall anhand der ausführlichen 
Beschreibungen in den zugehörigen Quelltexten. Und ja, es gibt durchaus 
einige HAL-Funktionalität, die unnötig wie ein Kropf ist, z.B. für 
Speicherzugriffe auf FMC-Speicher wie z.B. SDRAM.

[Arduino F. (Firma: Gast) (arduinof)]

Chris V. schrieb:
> WLAN, Bluetooth, Netzwerk ... Wenn man das Bare-Metal machen wollen
> würde, wäre man in vielleicht einem Jahr Vollzeit fertig aber wäre dann
> auch ein hochspezialisierter Experte. :)
Kaum....

Gerade dort sind die Register und ihre Funktion eher geheim.
Basiert auf vorkompilierten Objektdateien.

Closed Code.

Für normale Menschen: Doku unerreichbar.

[Frank O. (frank_o)]

Andreas S. schrieb:
>> Gut, ich bin zu faul mir die Doku zu HAL durchzulesen ;-)

Damals, als der Hype anfing (vor ca. 14 Jahren?) hatte ich auch ein paar 
dieser Boards gekauft. Aber über 1000 Seiten Datenblatt, war mir alles 
zu mächtig. Wenn ich kleine "Helferlein" brauche, reicht ganz oft ein 
Attiny10. Nur damit klar wird, wieso mir das zu viel war.
Cube hatte ich immer etwas am Rande betrachtet und grundsätzlich ist es 
das, was ich eigentlich als die Zukunft der µC-Programmierung sehe.

[Peter D. (peda)]

Seit Microchip die AVRs übernommen hat, gibt es ja nicht nur ATmega und 
ATtiny, sondern Unmengen an neuer Typen. Und die werden sie ja wohl 
nicht rausgebracht haben, wenn der AVR am Ende wäre.
Es sind ja inzwischen soviele, daß keiner mehr den Überblick hat, was 
konkret die Unterschiede sind:
- tinyAVR0
- tinyAVR1
- tinyAVR2
- megaAVR0
- AVR EA
- AVR EB
- AVR DA
- AVR DB
- AVR DD
- AVR DU

Interessant wäre für meine Anwendungen, ob überhaupt und welche davon 
mit (wieviel) CAN sind.

[Mi N. (msx)]

Andreas S. schrieb:
> Bei nur etwas größeren STM32 (genauso natürlich auch bei äquivalenten
> Serien anderer Hersteller) übersieht man aber sehr schnell die
> Abhängigkeiten zwischen verschiedenen Funktionsblöcken. Bei der Arbeit
> mit STM32CubeMX ist es äußerst ratsam, sich (mit Hilfe eines
> Versionskontrollsystems o.ä.) genau anzuschauen, welche
> Konfigurationsänderungen zu welchen Quellcodeänderungen führen.

Da bin ich ein wenig im Vorteil, da ich nicht zehn unterschiedliche 
Controller für ein Projekt nehme, sondern immer nur einen. Im Datenblatt 
steht genau drin, welche Pins welche alternativen Funktionen bieten. 
Danach lege ich die Pinbelegung und den Schaltplan fest. Das geht 
übrigens ganz gut mit Papier und Bleistift.
Bei der Programmierung der Takterzeugung z. B. im H7xx kann STM32CubeMX 
nur ein statisches Basisgerüst liefern. Wenn die PLLs zur Laufzeit 
umprogrammiert werden müssen, braucht man dann doch das Ref.-Manual. 
Allein schon, wenn HSE ausfallen kann und man den Takt neu 'aufbauen' 
muß.

Arduino F. schrieb:
> Gerade dort (Annmerkung: ESP32) sind die Register und ihre Funktion eher
> geheim. Basiert auf vorkompilierten Objektdateien.
>
> Closed Code.
>
> Für normale Menschen: Doku unerreichbar.

... und damit für Anwendungen ungeeignet, die über Spielereien 
hinausgehen. Darum habe ich den ESP32 nie angefasst - so billig er auch 
sein möge.

Zurück zum Thema:
Bei AVR schätze ich die Einfachheit und den direkten Betrieb an einer 
LiIon-Zelle. Auch ein ATtiny13 (oder 25/45/85, 24/44/84, 2313 ...) ist 
ein kleines Teil, mit dem man viele einfache Sachen schnell erledigt 
bekommt. Einziger Nachteil: Preis/Leistung stimmen nicht mehr. Die 
Nachfolger (genannter ..412) sind nett aber von der Struktur doch 
deutlich abweichend (kein Timer ist wie der andere). Allein der 
Befehlssatz ist geblieben.

Ein STM32 im 8-pol. Gehäuse löst bei mir allerdings Magenkrämpfe aus. 
Abhilfe: wegklicken.
Derzeit spiele ich mit einem G031 im TSSOP20, was richtig Spaß macht. 
Klein, fein, schnell mit viel Speicher für wenig Geld und hinreichend 
Pins (LQFP32), um einen ATmega328 alt aussehen zu lassen.
Hauptvorteil auch für kleinere Anwendungen: SWD zum Programmieren und 
Debuggen.

[Michael B. (laberkopp)]

Peter D. schrieb:
> Interessant wäre für meine Anwendungen, ob überhaupt und welche davon
> mit (wieviel) CAN sind.

Ja, Überblick und Vergleichbarkeit ist nicht im Interesse des 
Herstellers.

Einfach eine Tabelle mit Spalten der Special Functions in der jedes! 
Modell gelistet wird ist denen zu viel.

Lieber produziert man noch 10 neue Prozessoren.

Peter D. schrieb:
> Es sind ja inzwischen soviele, daß keiner mehr den Überblick hat, was
> konkret die Unterschiede sind.

[Falk B. (falk)]

Michael B. schrieb:
> Ja, Überblick und Vergleichbarkeit ist nicht im Interesse des
> Herstellers.
>
> Einfach eine Tabelle mit Spalten der Special Functions in der jedes!
> Modell gelistet wird ist denen zu viel.
>
> Lieber produziert man noch 10 neue Prozessoren.

Jaja, unser Laberkopp enttäuscht nie, wenn es um seine Kernkompetenz 
geht.

https://www.microchip.com/en-us/parametric-search.html/716?filters=JTdCJTIyY2F0ZWdvcnlkcm9wZG93biUyMiUzQSU1QiUyMk1pY3JvY29udHJvbGxlcnMlMjBhbmQlMjBNaWNyb3Byb2Nlc3NvcnMlMjIlMkMlMjIlMjIlMkMlMjIlMjIlNUQlN0Q=

Oben recht gibt es einen download Button. Was der wohl macht?

[Peter D. (peda)]

Falk B. schrieb:
> 
https://www.microchip.com/en-us/parametric-search.html/716?filters=JTdCJTIyY2F0ZWdvcnlkcm9wZG93biUyMiUzQSU1QiUyMk1pY3JvY29udHJvbGxlcnMlMjBhbmQlMjBNaWNyb3Byb2Nlc3NvcnMlMjIlMkMlMjIlMjIlMkMlMjIlMjIlNUQlN0Q=

Schade, nur die beiden bisherigen Typen mit nur einem CAN (AT90CAN*, 
ATmega*M1).

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Mi N. schrieb:
> Da bin ich ein wenig im Vorteil, da ich nicht zehn unterschiedliche
> Controller für ein Projekt nehme, sondern immer nur einen.

Genau. Und Du glaubst doch nicht wirklich, dass man bei einem Moloch wie 
dem H7 schon von vornherein en detail jede Einstellung festlegt und 
anschließend nie wieder anfasst?

> Im Datenblatt
> steht genau drin, welche Pins welche alternativen Funktionen bieten.
> Danach lege ich die Pinbelegung und den Schaltplan fest. Das geht
> übrigens ganz gut mit Papier und Bleistift.

Du hast also noch nie ein Projekt mit ernsthafter Komplexität 
realisiert. Bei Werkzeugen wie z.B. STM32CubeMX besteht ja gerade die 
Stärke darin, schnell Pins zu tauschen und zu schauen, welche 
Auswirkungen auf andere prozessorinternen Blöcke das hat.

Dann zeige doch mal ein Projekt, in dem Du an einem H7 sowohl SDRAM, 
Ethernet, eMMC, USB ULPI, USB FS, fünf SPI-Kanäle, drei I2C, fünf UARTs, 
CAN und haufenweise GPIO erfolgreich angeschlossen hast. Natürlich alle 
o.a. Schnittstellen gleichzeitig und unter Berücksichtigung der 
Impedanz- und Längenausgleichsanforderungen. Es reicht völlig aus, wenn 
Du den Layoutausschnitt mit dem entsprechenden BGA-Fanout zeigst.

> Bei der Programmierung der Takterzeugung z. B. im H7xx kann STM32CubeMX
> nur ein statisches Basisgerüst liefern. Wenn die PLLs zur Laufzeit
> umprogrammiert werden müssen, braucht man dann doch das Ref.-Manual.

Das bestreitet niemand. Das Grundgerüst ist aber schon extrem wichtig, 
um den Stromlaufplan und das Layout konfliktfrei zu realisieren.

> Allein schon, wenn HSE ausfallen kann und man den Takt neu 'aufbauen'
> muß.

Niemand behauptet, dass mit HAL/STM32CubeIrgendwas ein bereits 
vollständiges System vorliegt. Natürlich muss man anschließend noch 
weiterarbeiten. An einigen Stellen legt einem das System dann auch ein 
paar Stolpersteine in den Weg, die man erst beseitigen muss. Gerade bei 
Verwendung der "Middleware and Software Packs" bedeutet das auch, dass 
man einige von denen genauso schnell wieder hinauswirft wie man sie 
aktiviert hat.

Bei einigen dieser Pakete ist es durchaus sinnvoll, sie nicht über 
STM32CubeMX ins Projekt zu ziehen, sondern sie aus dem jeweiligen 
Git-Repository von STM zu ziehen und dann selbst zu integrieren.

[Georg M. (g_m)]

Georg M. schrieb:
>

> ● 16-bit Real-Time Counter (RTC) running from an external crystal, 
> external clock, or internal RC oscillator
>

Ich muss mich leicht korrigieren:
die tinyAVR® 1-series mit 8 Pins haben keine Anschlüsse für den 
Uhrenquarz.
Ab 14 Pins ist diese Funktion verfügbar.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Michael B. schrieb:
> Ja, Überblick und Vergleichbarkeit ist nicht im Interesse des
> Herstellers.

Unsinn. Der Überblick ist sogar das wichtigste.

> Einfach eine Tabelle mit Spalten der Special Functions in der jedes!
> Modell gelistet wird ist denen zu viel.

Das funktioniert bei den heutigen Microcontrollern nicht mehr, da viele 
Pins und auch andere Ressourcen mehrfach belegt sind. Und in einem 
Werkzeug wie z.B. STM32CubeMX gibt es genau diese Funktionalität, d.h. 
man filtert die ganzen Produkte nach den jeweils benötigten 
Schnittstellen und erhält dann direkt die verbleibende Auswahl mit 
direkter Verlinkung der Datenblätter und der Möglichkeit, ein Projekt zu 
generieren. Einfacher und transparenter geht es nun wirklich nicht mehr.

> Lieber produziert man noch 10 neue Prozessoren.

Du hast keine Ahnung, wie teuer es ist, einen weiteren Maskensatz 
aufzulegen, usw.. Daher geht man sogar häufig den entgegengesetzten Weg, 
nämlich Universalcontroller aufzulegen, bei denen dann in den meisten 
Kundenapplikationen große Teil ungenutzt bleiben.

Die vielen verschiedenen Gehäusevarianten werden auch nicht aus Jux und 
Dollerei angeboten, sondern weil die Kunden sehr unterschiedliche 
Anforderungen bezüglich der kompatiblen Leiterplattentechnologien, des 
Platzes und insbesondere der Kosten haben.

[Andreas R. (noobsen)]

Michael B. schrieb:
> Einfach eine Tabelle mit Spalten der Special Functions in der jedes!
> Modell gelistet wird ist denen zu viel.

Für die 8-Bit Typen gab es frühers schon Listen/PDFs, die natürlich 
etwas in die Jahre gekommen sind. Aber für ein Bastelprojekt immer noch 
brauchbar.

https://ww1.microchip.com/downloads/en/DeviceDoc/30010135E.pdf

[Peter D. (peda)]

Früher hatte Atmel noch Migration Notes mit den Unterschieden 
rausgebracht:
- AVR080: ATmega103 Replaced by ATmega128
- AVR094: Replacing ATmega8 by ATmega88
- AVR097: Migration between ATmega128 and ATmega1281/ATmega2561
- AVR504: Migrating from ATtiny26 to ATtiny261/461/861
- AVR505: Migration between ATmega16/32 and ATmega164P/324P/644P
- AVR533: Migrating from ATtiny2313 to ATtiny2313A

[Mi N. (msx)]

Andreas S. schrieb:
> Dann zeige doch mal ein Projekt, in dem Du an einem H7 sowohl SDRAM,
> Ethernet, eMMC, USB ULPI, USB FS, fünf SPI-Kanäle, drei I2C, fünf UARTs,
> CAN und haufenweise GPIO erfolgreich angeschlossen hast.

Du hast einen Denkfehler: man kann das alles gleichzeitig anschließen - 
muss es aber nicht!
:-)

[Michael O. (michaelor)]

Andreas S. schrieb:
> Dann zeige doch mal ein Projekt, in dem Du an einem H7 sowohl SDRAM,
> Ethernet, eMMC, USB ULPI, USB FS, fünf SPI-Kanäle, drei I2C, fünf UARTs,
> CAN und haufenweise GPIO erfolgreich angeschlossen hast. Natürlich alle
> o.a. Schnittstellen gleichzeitig und unter Berücksichtigung der
> Impedanz- und Längenausgleichsanforderungen. Es reicht völlig aus, wenn
> Du den Layoutausschnitt mit dem entsprechenden BGA-Fanout zeigst.

In etwas anderer Konstellation mit nem H743... 32-bit SDRAM, 24-bit 
LTDC, I2S in/out mit Masterclock, eMMC/QSPI, drei SPI, vier I2C, vier 
UART und diverse GPIOs.... geht alles noch mit dem 208-pinnigen 
LQFP-Gehäuse.

[Monk (Gast)]

Pandur S. schrieb:
> Gibt's eigentlich eine 32bit Familie, welche auf Bare-Metal betrieben
> werden kann ?

Zum Beispiel vermutlich alle STM32
http://stefanfrings.de/stm32/index.html

Frank O. schrieb:
>> Für alles Andere einfach einen STM32 mit der HAL in der CubeIDE.
> Und das geht mittlerweile gut?

Ja, tut es. Mit und ohne HAL.

[Frank K. (fchk)]

Pandur S. schrieb:
> Gibt's eigentlich eine 32bit Familie, welche auf Bare-Metal betrieben
> werden kann ? Also ohne Betriebssystem, ohne Treiber ? Und mit welchen
> Tools ?

Ich bin von AVR auf PIC24 und dsPIC33 gegangen. Das sind jetzt 16 Bit 
CPUs mit 24 Bit Adressraum, aber die lassen sich wie 8 Bit CPUs 
programmieren, haben viel bessere und flexiblere Peripherie als die 
klassischen AVRs (z.B. inkl. CAN-FD), sie gehen bis 100 MHz Dual-Core 
hoch, und die sie automotive-qualifiziert bis 150°C. Wie beim AVR hast 
Du da immer noch getrennte Adressräume für Code und Daten, aber mit dem 
C-Compiler brauchst Du Dich darum kaum noch zu kümmern. Und: Es gibt 
auch 5V-Typen, wenn man die braucht.

Damit kommt man schon ziemlich weit.

fchk

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Mi N. schrieb:
> Andreas S. schrieb:
>> Dann zeige doch mal ein Projekt, in dem Du an einem H7 sowohl SDRAM,
>> Ethernet, eMMC, USB ULPI, USB FS, fünf SPI-Kanäle, drei I2C, fünf UARTs,
>> CAN und haufenweise GPIO erfolgreich angeschlossen hast.
>
> Du hast einen Denkfehler: man kann das alles gleichzeitig anschließen -
> muss es aber nicht!
> :-)

Die obige Aufstellung stammt aus einem meiner aktuellen Projekte. Ich 
habe allein fürs Routing des halben Backblechs (12 Lagen, Stacked 
Microvias) rund vier Monate benötigt; das Fanout des H7 war dabei der 
mit Abstand schwerste Einzelbrocken, bei dem ich etliche Male Pins 
umsortieren musste.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Michael O. schrieb:
> In etwas anderer Konstellation mit nem H743... 32-bit SDRAM, 24-bit
> LTDC, I2S in/out mit Masterclock, eMMC/QSPI, drei SPI, vier I2C, vier
> UART und diverse GPIOs.... geht alles noch mit dem 208-pinnigen
> LQFP-Gehäuse.

Also ohne ULPI und Ethernet. Und vermutlich hast Du auch STM32CubeMX 
zumindest als Planungshilfe verwendet. Oder hast Du tatsächlich alles 
nur mit Papier und Bleistift zugeordnet und anschließend ohne HAL usw. 
programmiert?

[Niklas G. (erlkoenig)]

Jörg W. schrieb:
> Cortex-A willst du sicher nicht mehr komplett
> von der Pike auf selbst bearbeiten – könnte sein, dass deine Lebenszeit
> sonst abgelaufen ist, bevor du etwas Sinnvolles damit angestellt hast.

Geht aber tatsächlich, z.B. die TI Sitara kann man durchaus bare metal 
programmieren. Ist gar nicht so viel schlimmer als ein Cortex-M, nur das 
initiale Setup (u.a. der MMU) und die Interrupt-Präambel sind etwas 
fummelig weil das nur in Assembler geht.

[Crazy Harry (crazy_h)]

Gerhard O. schrieb:
> Jemand, den ich kenne, versuchte eine 320x240 TFT Touch Screen GUI
> Anwendung auf einen Mega2560.

Oh ich hab einen XMega an einem 800x480 hängen. Mit RA8875- oder 
FT8xx-Controllern geht das ganz gut 🙂

[Mi N. (msx)]

Andreas S. schrieb:
> Die obige Aufstellung stammt aus einem meiner aktuellen Projekte. Ich
> habe allein fürs Routing des halben Backblechs (12 Lagen, Stacked
> Microvias) rund vier Monate benötigt;

Ja und?
Nur weil Du das so machst, ist das noch lange nicht allgemeingültig, 
meine Vorgehensweise ja auch nicht.
Wie man sieht, machst Du das ja auch nicht jeden Tag, sondern maximal 
dreimal im Jahr. Wobei das 'Routing' garnicht Aufgabe vom CubeMX ist.
Gute Dinge brauchen auch mal ein wenig länger - dürfen sie auch ;-)

[Rahul D. (rahul)]

Wieso eigentlich "Auslaufmodell"?
Bisher dachte ich, alle ICs würden mit magischem Rauch betrieben, und 
wenn der entweicht, funktioniert das IC nicht mehr.
Auslaufen habe ich nur bei Batterien und Elkos beobachtet.

SCNR

[Michael O. (michaelor)]

Andreas S. schrieb:
>> In etwas anderer Konstellation mit nem H743... 32-bit SDRAM, 24-bit
>> LTDC, I2S in/out mit Masterclock, eMMC/QSPI, drei SPI, vier I2C, vier
>> UART und diverse GPIOs.... geht alles noch mit dem 208-pinnigen
>> LQFP-Gehäuse.
>
> Also ohne ULPI und Ethernet. Und vermutlich hast Du auch STM32CubeMX
> zumindest als Planungshilfe verwendet. Oder hast Du tatsächlich alles
> nur mit Papier und Bleistift zugeordnet und anschließend ohne HAL usw.
> programmiert?

Ja, ohne Ethernet. Das geht dann mit dem 208-Pinner nicht mehr alles 
gleichzeitig.

Zur Planung habe ich Cube genommen, logisch. Ich hab auch eimal den 
Init-Code von Cube erstellen lassen, aber dann im Laufe der Zeit die HAL 
weitestgehend durch eigenen Code ersetzt.

>Die obige Aufstellung stammt aus einem meiner aktuellen Projekte. Ich
>habe allein fürs Routing des halben Backblechs (12 Lagen, Stacked
>Microvias) rund vier Monate benötigt; das Fanout des H7 war dabei der
>mit Abstand schwerste Einzelbrocken, bei dem ich etliche Male Pins
>umsortieren musste.

Hm, der größte H7 kommt im TFBGA mit 240+25 Pins im 0,8mm Pitch. Das 
läßt sich noch locker auf 6 Lagen machen. Ein Kollege "durfte" seit 
einiger Zeit um ein Layout mit einem SM32MP1 im 448-pinnigen LFBGA 
kümmern. Daswar dann schon arg anspruchsvoll, ging aber letztendlich 
auch mit 6 Lagen gerade noch so.