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.
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.
