Wollte mir gerade einen AVR mit viel SRAM aussuchen. Da hab ich doch ordentlich gestaunt: Bei der Tabelle nach Parametern auf der Atmel-Webseite ist die Grösse des SRAM nicht etwa an prominenter Stelle gelistet, sondern weit, weit hinten nach einer ganzen Menge an Peripherie usw. Die grösse des Flash hingegen steht gleich in der ersten Spalte. Da frage ich mich: Ist die SRAM-Grösse eine solch unbedeutende Eigenschaft eines Mikrocontrollers? SRAM hatte ich bei vielen Projekten schon äusserst ausgereizt, Flash noch nie. Und die Peripherie reicht für sehr viele Anwendungen sowieso aus, und sonst holt man sich einen speziellen AVR.
Ja. Nein. Gummibauch. Such' Dir einfach den passenden 'raus und sche...ss drauf in welcher Spalte die RAM-Grösse angezeigt wird.
Ich könnte mir vorstellen, dass die Info weiter hinten steht, weil die Werte "schlecht" sind. Man möchte vielleicht lieber die Dinge zeigen, die gut sind. Irgendwo mittendrin streut man dann die schlechten Eigenschaften ein. Das ist halt so beim Marketing. Die Leute werden sich schon was dabei gedacht haben. Vielleicht haben sie sogar Untersuchungen durchgeführt, bei welcher Reihenfolge der Infos eine Testperson das Teils am ehesten kaufen würde.
Stefan K. schrieb: > Man möchte vielleicht lieber die Dinge zeigen, die gut sind. Irgendwo > mittendrin streut man dann die schlechten Eigenschaften ein. Das ist > halt so beim Marketing. Wird wohl irgendwie so sein. Mich wundert halt trotzdem, dass das SRAM überhaupt so weit abrutschen kann. Für allgemeine Aufgaben ist es IMHO sogar die wichtigste Eigenschaft, noch vor der Flash-Grösse. Darum habe ich mal nachgefragt, ob evtl. der Grossteil der Community da völlig andere Anforderungen hat...?!?
-.- schrieb: > Für allgemeine Aufgaben ist es IMHO > sogar die wichtigste Eigenschaft, noch vor der Flash-Grösse. Vor der Flashgröße ja - für allgemeine Aufgaben finde ich es jedoch nicht so wichtig. Für viele kleinere Projekte reichen 128Byte und weniger.
Vermutlich hast Du bis jetzt nur auf PCs programmiert. Die strenge Trennung zwischen Programm- und Datenspeicher gibt es da so nicht. Ich war auch überrascht, mit dem ATTiny2313 zuerst an die Grenze des Flash zu kommen. Die RAM-Größe ist mit 128 Byte eigentlich unritisch.
Komisch im Datenblatt vom Tiny13 steht auf der ersten Seite: "- 64K Bytes Internal SRAM" In Microcontrollern geht es auch ganz ohne wie z.B. Tiny11. Den SRAM braucht's auch nur wenn man einen Stack benötigt, z.B. bei C-Programmierung, in Assembler braucht's nur die Register ...
Viele Projekte brauchen nur mäßig SRAM aber dafür heftig Peripherie. Dazu kommt noch, dass du größere tables in dem flash auslagerst... Damit muss in den SRAM nur die paar variablen passen.
loller schrieb: > Komisch im Datenblatt vom Tiny13 steht auf der ersten Seite: > "- 64K Bytes Internal SRAM" Nimm mal das 'k' weg, dann passt es. Oder Du hast ein anderes Datenblatt als ich.
>Den SRAM braucht's auch nur wenn man einen Stack benötigt, z.B. bei >C-Programmierung, in Assembler braucht's nur die Register ... Stack hat mit C nichts zu tun. Ich kann genauso in Assembler einen Stack verwenden. Und wenn ich in C die Funktion ohne Parameter aufrufe, wie man es in Assembler macht. Und auch nur globale Variablen oder Register benutze, wie man es in Assembler macht, dann brauch ich auch keinen Stack.
Knut Ballhause schrieb: > Nimm mal das 'k' weg, dann passt es. Oder Du hast ein anderes Datenblatt > als ich. Tja nun ist vielleicht bissle älter aber da sthet das so drin :-P Hamse da das mitm EEPROM verwechselt ?
acryl schrieb: >>Den SRAM braucht's auch nur wenn man einen Stack benötigt, z.B. bei >>C-Programmierung, in Assembler braucht's nur die Register ... > Stack hat mit C nichts zu tun. > Ich kann genauso in Assembler einen Stack verwenden. > > Und wenn ich in C die Funktion ohne Parameter aufrufe, wie man es in > Assembler macht. Und auch nur globale Variablen oder Register benutze, > wie man es in Assembler macht, dann brauch ich auch keinen Stack. Aha und warum meckert dann der GCC wenn ich sowas für einen Tiny11 machen will ? "main.c:1: error: MCU 'attiny11' supported for assembler only"
Hi >Aha und warum meckert dann der GCC wenn ich sowas für einen Tiny11 >machen will ? >"main.c:1: error: MCU 'attiny11' supported for assembler only" Weil dein GCC nicht mit dem Hardwarestack des ATTiny11 nicht umgehen kann. Ohne Stack kann man auch in Assembler kein Unterprogramm oder Interrupt nutzen. MfG Spess
Spess53 schrieb: > Weil dein GCC nicht mit dem Hardwarestack des ATTiny11 nicht umgehen > kann. Ohne Stack kann man auch in Assembler kein Unterprogramm oder > Interrupt nutzen. Ja stimmt Stackpointer und Stack sind ja da, mein Fehler ...
Joachim Drechsel schrieb: > Ich war auch überrascht, mit dem ATTiny2313 zuerst an die Grenze > des Flash zu kommen. Die RAM-Größe ist mit 128 Byte eigentlich > unritisch. Ist auch meine Erfahrung. Der Flash geht deutlich eher aus, als der SRAM. Bzw. bei engem RAM hat man deutlich mehr Möglichkeiten zu optimieren, als bei zu wenig Flash. Peter
Joachim Drechsel schrieb: > Ich war auch überrascht, mit dem ATTiny2313 zuerst an die Grenze > des Flash zu kommen. Die RAM-Größe ist mit 128 Byte eigentlich > unritisch. Also bei mir ist das ähnlich. Der Flash war zuerst das Problem, weil viele Systemfunktionen einfach viel mehr Speicher gefressen haben als nötig. Insbesondere bei Arduino ist schon ein "leeres" Projekt bald 1/2 bis 1 KB groß... ohne dass was passiert. Mit dem RAM ist das so eine Sache. Ich habe mich damit abgefunden, dass einfach so wenig da ist und deswegen fallen einfach die Anwendungen Flach, die mehr RAM brauchen. Zum Beispiel wenn ein Roboter eine Karte des Raumes aufbauen soll, in dem er sich bewegt... das passt da einfach nicht hinein. Im Prinzip könnte man aber den SRAM des AVR als L1 Cache der CPU betrachten. Wenn man jetzt eine SD-Karte nimmt (z.B. 2 GB) und die als "RAM" oder "SWAP"-Speicher betrachtet, wird's interessant. Ja man muss wegen Begrenzung der Schreibzyklen sich noch einen Algorithmus überlegen, der dann Speicherzellen "umlagert" und immer wieder woanders hin schreibt... aber das is mal Nebensache. Natürlich hat ein einfacher AVR keinerlei Unterstützung für SWAP oder externen RAM (der größer als 64KB ist), aber mit einem Trick könnte man einen Compiler bauen, der aus einem direktem Speicherzugriff einen entsprechenden Zugriff auf den virtuellen Speicher vornimmt. Am besten würde man ein paar der Allzweckregister für diesen Zweck für den normalen Compiler sperren und dann alle ld/std-Befehle im Assembler durch entsprechenden Code ersetzen. Damit kommt man natürlich noch schneller an die Grenzen der Flash-Größe. Aber... Wenn man jetzt noch den Programmcode auf die SD-Karte auslagert und interpretiert (z.B. sowas wie ne JavaVM bastelt), funktioniert auch das. Wenn man dann noch einige wichtige, größere Aktionen direkt nativ programmiert und im Flash-Speicher ablegt, könnte man bei ca. 1/3 bis 1/4 der Taktrate von der Geschwindigkeit her landen. Oder aber auch nicht. Das würde extrem vom Programm (und vor allem dessen Speicherlokalität) abhängig sein. So wie's auf den normalen Desktop-PCs auch ist... Nunja, es war auch nur ne Idee...
-.- schrieb: > Da frage ich mich: Ist die SRAM-Grösse eine solch unbedeutende > Eigenschaft eines Mikrocontrollers? SRAM hatte ich bei vielen Projekten > schon äusserst ausgereizt, Flash noch nie. Und die Peripherie reicht für > sehr viele Anwendungen sowieso aus, und sonst holt man sich einen > speziellen AVR. Wenn Du viel RAM brauchst, nimm einfach eine andere Architektur. dsPICs gibts bis 96k, PIC32 bis 128k eingebaut, oder irgend ein Ärmchen mit externem Bus-Interface - da kannst Du dann gigabyteweise RAM anklemmen. Alles kein Problem. fchk
Stefan K. schrieb: > Zum Beispiel wenn ein Roboter eine Karte des Raumes aufbauen soll, in > dem er sich bewegt... das passt da einfach nicht hinein. Das wär für mich eher gerade die Herausforderung. So eine Karte sollte locker reinpassen. Ganz naiv: Ein Raum von 6m x 6m mit einer Auflösung von 10cm hat 3600 Datenpunkte. Die kriegt man in 450 Bytes untergebracht. Aber es gibt bestimmt noch sehr viele Varianten, wie man die Datenmenge verkleinern könnte: Man könnte die Karte sektorweise komprimieren. Man könnte versuchen die Hindernisse zu größeren Objekten zusammenzufassen und dann deren Koordinaten speichern. Sozusagen statt einem Bitmap eine Vektorgrafik benutzen. Man könnte einen Baum aufbauen, ähnlich wie es bei Raytracing gemacht wird: Wenn ein Sektor Hindernisse enthält wird er in 4 weitere Untersektoren aufgeteilt so lange bis man eine ausreichende Auflösung erreicht hat. Wenn der Raum größtenteils leer ist spart man dadurch sehr viel Speicher.
Peter Dannegger schrieb: > Joachim Drechsel schrieb: >> Ich war auch überrascht, mit dem ATTiny2313 zuerst an die Grenze >> des Flash zu kommen. Die RAM-Größe ist mit 128 Byte eigentlich >> unritisch. > > Ist auch meine Erfahrung. > Der Flash geht deutlich eher aus, als der SRAM. > Bzw. bei engem RAM hat man deutlich mehr Möglichkeiten zu optimieren, > als bei zu wenig Flash. Entspricht auch meinen Erfahrungen. Zu Beginn der "Karriere" war schneller das RAM knapp. Irgendwann legt man dann auf die RAM-Belegung schon beim Planen/Entwickeln viel mehr Wert, so dass das i. d. R. kein Problem mehr ergibt. Teilweise stellt man auch Funktionen, welche wie sprintf einen Puffer benötigen auf "streaming" um. Diese brauchen dann keine Puffer, belegen aber u. U. mehr Platz im Flash. Vermutlich wächst einfach mit der Zeit auch die Anzahl und die Größe der (allgemeinen) Funktionen, die man gerne mit ins Projekt aufnimmt. Insofern: Für mich spielt die Größe des RAMs tatsächlich eine untergeordnete Rolle, Flash und die sonstige Peripherie sind wichtiger.
loller schrieb: > Aha und warum meckert dann der GCC wenn ich sowas für einen Tiny11 > machen will ? > "main.c:1: error: MCU 'attiny11' supported for assembler only" Weil avr-gcc diesen µC nicht unterstützt. Das sagen dir diese Meldung und auch die Dokumentation des Compilers. Die Meldung bekommst du unabhängig vom Quelltext und z.B. auch für eine leere Quelldatei.
Vielleicht koennte der Poster ja mal darlegen wozu er so grosse Mengen an RAM braucht. Ich komme mit den 4k meines favorisierten 644 gut klar.
Wie wäre es einfach externes SRAM anzuschließen? Es gibt genug Typen die das Hardwaremässig unterstützen.
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.