Hi! Das übliche Verhältnis bei AVR Controllern zwischen RAM und Flash ist anscheinend fast immer 1 zu 16. Die Ausrede, man muss sich ja mal für irgendwas entscheiden, zieht hier aber nicht. Es gibt immerhin eine extreme Auswahl von µCs, die sich auch nur marginal voneinander unterscheiden. Da frage ich mich einfach, warum es kein Modell gibt, der z.B. mal ein 1:1 Verhältnis hat. Es soll ja auch Projekte geben, die mal 16 oder sogar 32 kB RAM (omg!!!) brauchen, ohne dass man gleich ein EBI anbinden will... Oder habe ich da was übersehen, was es schon längst gibt?
RAM braucht viel Platz auf dem Die. Siehe z.B. hier: Beitrag "Anzahl Transitoren eines ATMega8"
:
Bearbeitet durch User
Jan schrieb: > Oder habe ich da was übersehen, was es schon längst gibt? Ja. Andere Controller-Familie verwenden. Bei AVRs gibts etwas RAM intern, notfalls EBI, und das wars. Die sind nicht für Aufgaben mit hoher RAM-Kapazität gebaut.
:
Bearbeitet durch User
> ... 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?
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...
Jan schrieb: > Es soll ja auch Projekte geben, die mal > 16 oder sogar 32 kB RAM (omg!!!) brauchen, ohne dass man gleich ein EBI > anbinden will... Um den AVR als Datacenter zu betreiben, empfiehlt sich der Einsatz seriellen RAMs oder einer SD-Karte. Irgendwo willst Du mit den Daten ja auch hin ... Ich bezweifele, dass die Menge an Daten für einen derart 'kleinen' Prozessor in einem sinnvollen Verhältnis steht. (Auch wenn ich solche Konstrukte hin und wieder selbst auch gerne mal aufstelle.) Sonst z.B. AT32UC3A3256 Gruß Jobst
Keiler schrieb: > 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... Stimmt. Meist sind solche Systeme inzwischen kleiner. Siehe NXP RT600. Benötigt allerdings noch eine SD-Karte oder eMMC zum booten. Gruß Jobst
alter Thread von 2014: Beitrag "Viel RAM am kleinen Controller" Kurzes googeln: Scheint keinen einzigen AVR(32) der DDR-RAM unterstützt. Nur bereits hier genannten SDRAM und SRAM.
Ein STM32H7B0 könnte einen AVR mit 1MB RAM und 4KB EEPROM emulieren. Der Chip hat zusätzlich noch 128KB Flash und 128+128+64+32KB RAM und kommt im LQFP-64. Und von wegen RAM braucht viel Chipfläche: angekündigt ist ein 4.6x4.4mm Gehäuse (WLCSP-132). Zum Ausgleich kommt er dann mit 2MB Flash.
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.
N. B. schrieb: > alter Thread von 2014: Beitrag "Viel RAM am kleinen Controller" > > Kurzes googeln: Scheint keinen einzigen AVR(32) der DDR-RAM unterstützt. > Nur bereits hier genannten SDRAM und SRAM. Das will man auch an einem AVR mit DDR-RAM? Das macht erst ab ARM mit mehr als 500MHz Sinn.
:
Bearbeitet durch User
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'.
Johannes S. schrieb: > Wiznet will man sich ja wohl auch nicht mehr antun wo es weit > bessere Lösungen gibt Wiznet kann schon noch Sinn ergeben, besonders wenn man bestehende Software mit z.B. serieller Kommunikation auf Ethernet umstellen will. Man verlagert die sonst in Form zusätzlich einzubauender TCP/IP-Software in einen leicht zu initialisierenden Chip und das wars.
Das ist leider eine leere Menge. Und nach diversen RAM-sparen-Versuchen wie 3 Bit pro Pixel für ein LCD etc... bin ich bin deswegen zu ARM gewechselt. Ein RGB Framebuffer für ein kleines LCD braucht einfach ein paar KB. Von der Rechenzeit her würde das auf einem AVR eigentlich noch gut gehen. Blöd nur, dass die Verfügbarkeit der STM jetzt schlechter ist als bei den AVRs...
:
Bearbeitet durch User
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.
Jan schrieb: > Da frage ich mich einfach, warum es kein Modell gibt, der > z.B. mal ein 1:1 Verhältnis hat. Weil das die Masse der zahlenden Kunden nicht braucht. Und in diesem Markt geht es um jeden Cent. Die paar zehntausend Bastler sind nebensächlich, die Milliardenumsätze bringen die Industriekunden. > Es soll ja auch Projekte geben, die mal > 16 oder sogar 32 kB RAM (omg!!!) brauchen, Dann nimm externen S(D)RAM. > ohne dass man gleich ein EBI > anbinden will... Nö. Die wenigen (wieviel? 1 Promille?), die das WIRKLICH brauchen, nehmen externen S(D)RAM und gut. Wo liegt das Problem? Es scheint eher, daß du daraus eine Ideologie machen willst. Interner RAM ist gut, externer böse. Das ist Unfug.
Falk B. schrieb: > Die wenigen (wieviel? 1 Promille?), die das WIRKLICH brauchen, > nehmen externen S(D)RAM und gut. Wo liegt das Problem? Zu teuer, zu groß, zu viele Pins und Leiterbahnen, zu viel Störstrahlung. > Es scheint eher, daß du daraus eine Ideologie machen willst. > Interner RAM ist gut, externer böse. Das ist Unfug. Und die Erde ist eine Scheibe ;)
Bauform B. schrieb: >> Die wenigen (wieviel? 1 Promille?), die das WIRKLICH brauchen, >> nehmen externen S(D)RAM und gut. Wo liegt das Problem? > > Zu teuer, zu groß, zu viele Pins und Leiterbahnen, zu viel > Störstrahlung. Sagt die Konifere des Forums . . .
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.
c-hater schrieb: > Stefan ⛄ F. schrieb: > >> Er ist nur verwirrt. Einfach weiter gehen ohne hinzuschauen, dann >> passiert nichts. > > Wie meinen? Wer ist verwirrt? Stefan will RAM beim µC-Forum sparen und vergisst deshalb, vernünftig zu zitieren.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.