AVR Controller mit massig RAM

> ...  16 ... kB RAM

Ist, zugegeben, nicht "massig", aber: ATmega1284 oder AVR128Dx mit 16 
KiB.

Jan schrieb:
> Es soll ja auch Projekte geben, die mal
> 16 oder sogar 32 kB RAM

Meine Erfahrung: Entweder braucht man deutlich weniger und nimmt AVR 
oder deutlich mehr und man nimmt ARM. Meine Frage: Bei welchem 
AVR-Projekt ist einem Projekt des TO der SRAM ausgegangen?

ATxmega384 mit 32 KBytes RAM (und 384 KBytes Flash)

Habe hier ein 80186 Board mit 256k Flash und 4MB RAM. Das ist ein ganz 
schöner Klopper. In etwa wie die alten VLB VGA Karten. Komplett 
vollgestopft.

Das in einen DIP32 quetschen wird lustig...

Egon schrieb:
> Meine Frage: Bei welchem AVR-Projekt ist einem Projekt des TO der SRAM
> ausgegangen?

Ich wills gleich selbst beantworten: Natürlich keinem!
Für die Aufgaben wozu ein AVR gut ist (und das sind nicht wenige) reicht 
Flash wie SRAM nämlich locker. Denn dort programmiert man etwas 
ressourcenschonender als bei dafür weniger berühmten Chips.

Egon schrieb:
> Ich wills gleich selbst beantworten: Natürlich keinem!

Hatte mir früher auch immer eingebildet mit einem AVR riesige
Mengen an RAM zu brauchen - ist nie eingetreten. Ausnahmen
natürlich bei den sehr kleinen Tinies.

viel RAM tut gut bei Anwendungen z.B. mit Ethernet oder Grafik, für 
beides haben die AVR keine Devices auf dem Chip. Und die Quälerei mit 
ENC oder Wiznet will man sich ja wohl auch nicht mehr antun wo es weit 
bessere Lösungen gibt. Zu den AVR würde B.G. wohl auch sagen '16 kB 
sollten für jeden reichen'.

Malte _. schrieb:
> bin ich bin deswegen zu ARM gewechselt. Ein RGB Framebuffer für ein
> kleines LCD braucht einfach ein paar KB.

Derart "pure" GrafikDisplay-Anbindung ist so ein Fall:

Egon schrieb:
> Entweder braucht man deutlich weniger und nimmt AVR oder deutlich mehr
> und man nimmt ARM.

Mit weniger (Nextion) oder mehr (uniTFT) Geld kann man sich aber auch da 
behelfen. Analog Funktions-Auslagerung a'la Wiznet nimmt man hier eben 
ein intelligentes HMI Display.

Egon schrieb:
> Mit weniger (Nextion)

jo, und da ist dann ein kleiner ARM drauf. ARM, ESP32 oder mittlerweile 
auch RP2040 haben reichlich Dampf das all in one zu erledigen. Mit lvgl 
auch mit netter Grafik die Nextion & Co. in nichts nachsteht, Open 
Source ist und wofür es reichlich Beispiele gibt.
Man müsste sich nur mal davon verabschieden jedes Bit beim Namen kennen 
zu wollen und eine Abstraktionsschicht höher erlernen.

Johannes S. schrieb:
> Man müsste

Nix da, niemand muß.
Was langt das langt.
Sonst kommt man schnell vom Hundertsten ins Tausendste ohne echte 
Notwendigkeit.
Hat alles seine Vor- und Nachteile.

Johannes S. schrieb:
> Egon schrieb:
>
>> Mit weniger (Nextion)
>
> jo, und da ist dann ein kleiner ARM drauf

Den passiv zu nutzen da fällt mir wirklich kein Zacken aus der AVR 
Krone. Bis ich etwa mit einem aktuellen RP2040 wirklich alles so locker 
programmieren könnte was ich jetzt mit schlankem AVR (viel flexibler) 
aus dem Ärmel schüttele sind wir schon wieder einige RPxxxx mit wieder 
neuen Eigenheiten Generationen weiter. Über irgendwelche billigen 
Beispielprogramme hinaus wird das Projekt- Gelände da nämlich schnell 
schwer sumpfig.

Egon schrieb:

> Bis ich etwa mit einem aktuellen RP2040 wirklich alles so locker
> programmieren könnte was ich jetzt mit schlankem AVR (viel flexibler)

Der AVR ist (zumindest softwaremäßig oder bezüglich der Peripherie) 
keinesfalls flexibler als ein RP2040. Das Gegenteil ist der Fall.

Die extremen Vorteile des RP2040 gegenüber bezüglich der Rechenleistung 
vergleichbaren ARM-Controllern sind:
-viel mehr verfügbarer RAM
-Echtzeit viel besser als AVR (durch die PIOs)

D.h.: viele ARM-Nachteile wiegen hier längst nicht mehr so schwer, die 
Vorteile können besser genutzt werden, und der Hauptvorteil ist halt im 
Falle des RP2040: extrem viel RAM für so einen kleinen Controller. 
Genug, um sogar einen echten Framebuffer völlig unabhängig von den Cores 
zu betreiben. Wenn auch nur im bescheidenen Ausmaß von maximal ca. 22MHz 
Pixeltakt und 12bpp.

> Über irgendwelche billigen
> Beispielprogramme hinaus wird das Projekt- Gelände da nämlich schnell
> schwer sumpfig.

Ja, wenn die "eigenen" Projekte im Wesentlichen nur C&P fremder 
Leistungen sind, dann mag das wohl so aussehen...

Er ist nur verwirrt. Einfach weiter gehen ohne hinzuschauen, dann 
passiert nichts.

Stefan ⛄ F. schrieb:

> Er ist nur verwirrt. Einfach weiter gehen ohne hinzuschauen, dann
> passiert nichts.

Wie meinen? Wer ist verwirrt?

c-hater schrieb:
> Der AVR ist (zumindest softwaremäßig oder bezüglich der Peripherie)
> keinesfalls flexibler als ein RP2040. Das Gegenteil ist der Fall.

Flexibler meint, Du hast als Bastler die Auswahl unter 
unterschiedlichsten Chips und nicht nur eine fixe Platine. Das 
ermöglicht insbesondere kleinere und funktionell angepasstere Lösungen.

c-hater schrieb:
> viel mehr verfügbarer RAM
> -Echtzeit viel besser als AVR (durch die PIOs)

Das Event-System neuerer AVRs scheint Dir noch kein Begriff zu sein. Daß 
die GPIO Ansteuerung über die neuen PIOs nun noch komplexer geworden ist 
sehe ich eher als schweren Nachteil. Sie braucht sogar eine eigene 
Assembler-Sprache. Gehts noch verrückter?

> Hauptvorteil ist halt im Falle des RP2040: extrem viel RAM für so einen
> kleinen Controller. Genug, um sogar einen echten Framebuffer völlig
> unabhängig von den Cores zu betreiben. Wenn auch nur im bescheidenen
> Ausmaß von maximal ca. 22MHz Pixeltakt und 12bpp.

RAM ist immer von Vorteil, doch wenn ich schon wieder die vorgenommene 
Segmentierung des Speichers sehe... Auch sonst ist das Ding viel zu 
komplex geraten. Damit ist wieder eine Generation Programmierer mit 
Arbeit eingedeckt. Meist für die gleichen Dinge die jetzt und schon 
lange AVRs bewerkstelligen. Danke.

c-hater schrieb:
> Ja, wenn die "eigenen" Projekte im Wesentlichen nur C&P fremder
> Leistungen sind,

Ja, wenn!

Egon schrieb:

> Das Event-System neuerer AVRs scheint Dir noch kein Begriff zu sein.

Doch, natürlich. Aber: was kann ein Eventsystem bei maximal 32Mhz, was 
der RP2040 nicht bei 133MHz können soll...

> die GPIO Ansteuerung über die neuen PIOs nun noch komplexer geworden ist
> sehe ich eher als schweren Nachteil. Sie braucht sogar eine eigene
> Assembler-Sprache.

Du kannst die GPIOs natürlich auch in gemütlichem C ansteuern. Nur halt 
nicht nicht so zeitlich treffgenau, wie es die PIOs können.

> RAM ist immer von Vorteil, doch wenn ich schon wieder die vorgenommene
> Segmentierung des Speichers sehe...

Der ist nicht "segmentiert", jedenfalls nicht so, wie du das verstehst. 
Aus deinem geliebten C-Bullshit heraus kannst du den als plain 
betrachten und auch so darauf zugreifen. Die Segmentierung existiert nur 
dann, wenn es wirklich auf Speed ankommt. Also nur bezüglich des 
möglichen Durchsatzes, nicht bezüglich der Addressierung. Also nur dann, 
wenn man wirklich maximal Performance aus dem Speicher herauskitzeln 
muss/will, muss man sich mit dessen "Segmentierung" befassen.

> Auch sonst ist das Ding viel zu
> komplex geraten.

Maybe, für dich. Nicht für mich.

Also bislang habe ich nur eine Anwendung wo mir der RAM eines AVR 
wirklich störend zu klein ist, als VGA Controller. Aber das war auch 
eher eine Machbarkeitsstudie. Andererseits ging mir dabei auch auf die 
Nerven, dass das SPI ungepuffert ist oder es praktisch nie einen 
komplett nutzbaren Port gibt wo nicht wieder ein anderes Signal drin 
liegt was man auch braucht (Reset, RxD/TxD, XTAL1/2), außer eben bei den 
40/44 Pinnern.

c-hater schrieb:
> Aber: was kann ein Eventsystem bei maximal 32Mhz, was der RP2040 nicht
> bei 133MHz können soll...

Wer braucht eine Echtzeit bei 133MHz wenn (mir) meist schon eine bei 
8MHz in reinem Interruptbetrieb reicht :)

c-hater schrieb:
> Du kannst die GPIOs natürlich auch in gemütlichem C ansteuern. Nur halt
> nicht nicht so zeitlich treffgenau, wie es die PIOs können.

Mir reicht ein kurzes knackiges sbi und cbi, ggf. ergänzt um Interrupts 
bei Flanken-Erkennung.

c-hater schrieb:
> Aus deinem geliebten C-Bullshit

Du solltest hier aufmerksamer lesen.

c-hater schrieb:
> Maybe, für dich. Nicht für mich.

Das freut mich aufrichtig.
Ob Du "den Vorteil" wirklich irgendwobei nutzt oder hier nur wichtig 
daherquakst steht sicher auf einem anderen Blatt.

Tim T. schrieb:
> als VGA Controller

eignen sich sicher andere und 32Bitter besser.

Tim T. schrieb:
> es praktisch nie einen komplett nutzbaren Port gibt wo nicht wieder ein
> anderes Signal drin liegt was man auch braucht (Reset, RxD/TxD,
> XTAL1/2), außer eben bei den 40/44 Pinnern.

Immerhin existieren gerade auch bei den neuen AVRs 
Alternativbelegungungen. Die völlig freie Definierbarkeit der 
Pinfunktion bei gleichzeitig simpler Konfiguration derselben stünde 
auch bei mir auf der Wunschliste. Und noch einiges mehr was heute noch 
in Software zu erledigen ist.

c-hater schrieb:
> Die extremen Vorteile des RP2040 gegenüber bezüglich der Rechenleistung
> vergleichbaren ARM-Controllern sind:
> -viel mehr verfügbarer RAM
> -Echtzeit viel besser als AVR (durch die PIOs)

Sobald man Timer braucht, die schnelle, externe Ereignisse zählen können 
und/oder Capture-Funktion zu diesen Timern, sieht der RP2040 doch total 
alt aus.
Was sich die Entwickler dabei nur gedacht haben?

Bereits die kleinsten STM8 haben 2 kB RAM und sind/waren mindestens
vor der grossen Chipkrise viel billiger als ein stinkender AVR.

Egon schrieb:
> Tim T. schrieb:
>> als VGA Controller
>
> eignen sich sicher andere und 32Bitter besser.

Natürlich, aber es ging mir gerade eben darum nicht einfach einen 
billigen RPi dafür zu nehmen und auch direkt HDMI zu haben sondern das 
Ganze mit einfachsten Mitteln zu bauen.

>
> Tim T. schrieb:
>> es praktisch nie einen komplett nutzbaren Port gibt wo nicht wieder ein
>> anderes Signal drin liegt was man auch braucht (Reset, RxD/TxD,
>> XTAL1/2), außer eben bei den 40/44 Pinnern.
>
> Immerhin existieren gerade auch bei den neuen AVRs
> Alternativbelegungungen. Die völlig freie Definierbarkeit der
> Pinfunktion bei gleichzeitig simpler Konfiguration derselben stünde
> auch bei mir auf der Wunschliste. Und noch einiges mehr was heute noch
> in Software zu erledigen ist.

Finde es einfach schade dass es bei den kleineren AVR praktisch nie eine 
Möglichkeit gibt einen kompletten Port zu nutzen. Beispielsweise bei den 
328ern mussten sie ja unbedingt den XTAL auf PB legen, Reset auf PC 
(wobei der eh nur 7 Pins hat) und die Serielle Schnittstelle auf PD. 
Irgendwie grenzt das doch an Sabotage. Warum konnte man nicht einfach 
Reset, Seriell und XTAL auf den eh schon zu kleinen PC legen?

Egon schrieb:

> Das freut mich aufrichtig.
> Ob Du "den Vorteil" wirklich irgendwobei nutzt oder hier nur wichtig
> daherquakst steht sicher auf einem anderen Blatt.

Nun ich habe mit dem RP2040 z.B. einen Framebuffer für ein 960x160-LCD 
realisiert. Der läuft (einmal initialisiert) völlig unabhängig von den 
beiden M0+-Kernen.

Nur über den Speicherdurchsatz kann man das Ding noch in der Funktion 
beeinträchtigen. Z.B. durch Mem2Mem-DMA ohne Pacing.

However: Das ist jedenfalls weit jenseits der Möglichkeiten eines AVR8. 
Der hat schlicht nicht annähernd genug RAM für sowas.

m.n. schrieb:

> Sobald man Timer braucht, die schnelle, externe Ereignisse zählen können
> und/oder Capture-Funktion zu diesen Timern, sieht der RP2040 doch total
> alt aus.

Nicht, wenn man die PIOs beherrscht...

Ach ja, was meinst du mit neueren AVR? Meinst du die XMegas? Also da 
gehe ich dann doch lieber direkt auf nen ARM. Die XMegas versuchen 
irgendwie eine Lücke zu füllen, die ich weder sehe noch habe.

Harald W. schrieb:
> Stefan will RAM beim µC-Forum sparen und vergisst deshalb,
> vernünftig zu zitieren.

Wie wir sehen hat sich die gemeinte Person dennoch prompt angesprochen 
gefühlt.

Tim T. schrieb:
> Meinst du die XMegas?

Nein. Die neue AVRxxxDx Serie.

c-hater schrieb:
> However: Das ist jedenfalls weit jenseits der Möglichkeiten eines AVR8.
> Der hat schlicht nicht annähernd genug RAM für sowas.

Das hat auch niemand behauptet.