Wann ist bei einem AVR der Flash-Speicher genau voll?

[Sven L. (friemler)]

Servus Gemeinde,

und zwar bin ich derzeit mit der Programmierung in C eines Mega32 
beschäftigt, welcher schon mit 31677 Byte vollgeschrieben ist und ich 
noch einige Funktionen zusätzlich unterbringen wollte.

Meine Frage daher: ist in den 31677 benutzen Byte schon der Stack mit 
enthalten, oder muß ich bei kompilierten 32768-256=32512 Byte aufhören 
zu programmieren? (oder Optimierungen suchen, hab schon vieles in's 
EEPROM ausgelagert)

[Jean P. (fubu1000)]

Der Stack ist im RAM.

[Sven L. (friemler)]

Uuups, das war knapp, der RAM ist auch schon zu 1698 Byte voll.

Dankeschön.

[vielleicht so (Gast)]

Ich wuerd mal einen Mega64 bestellen und mir die weitere Zeit mit dem 
Mega32 ersparen.

[Jean P. (fubu1000)]

Naja dann schon eher nen 644er da hat er dann auch gleich nen bissl mehr 
RAM.

Gruß

[Sven (Gast)]

Oder mal in ner vernünftigen Sprache programmieren. ASM heisst das 
Zauberwort, um Ressourcen zu schonen.

[Harrobert (Gast)]

> Oder mal in ner vernünftigen Sprache programmieren. ASM heisst das
> Zauberwort, um Ressourcen zu schonen...

... und die Nerven zu strapazieren.

[holger (Gast)]

>> Oder mal in ner vernünftigen Sprache programmieren. ASM heisst das
>> Zauberwort, um Ressourcen zu schonen...
>... und die Nerven zu strapazieren.

ASM ist ne Sackgasse. Schön wenn man es kann.
Im wirklichen Leben reine Zeitverschwendung.
Wanderer zwischen den Welten bevorzugen C.
Da kann man dann recht schnell von einem PIC auf einen
AVR springen, oder auf einen ARM. Ein bißchen muss man
da auch immer noch anpassen. Aber nicht den kompletten
Code neu schreiben.

[Andreas W. (Gast)]

Hey

beides ist empfehlenswert, ASM und C. Großteil des Programms in C und 
kleine wichtige Teile in ASM.
Alles in ASM ist inefficient, man benutz kaum den RAM/Stack neigt mehr 
zu delays, das sieht halt nicht schön aus das Programm. Es ist halt 
verdammt schwierig komplexere Probleme noch effektiv in ASM zu 
programmieren (nicht unmöglich).

zum Topic.
Schau mal wo dein Speicher verbraucht wird, vieleicht lässt sich da ja 
noch was machen. wenn nicht dann halt ein größerer µC.

[melone (Gast)]

>Oder mal in ner vernünftigen Sprache programmieren. ASM heisst das
>Zauberwort, um Ressourcen zu schonen.

Wenn ich sowas höre, krieg ich das Kotzen. Ich programmiere die Firmware 
von Geräten in C. Wenn man in C vernünftig programmiert, hat man nicht 
zuviel Overhead. Außerdemm existieren von Atmel Optimierungsbeispiele, 
die man sich unbedingt anschauen sollte.

[Peter D. (peda)]

melone wrote:
> Wenn ich sowas höre, krieg ich das Kotzen. Ich programmiere die Firmware
> von Geräten in C. Wenn man in C vernünftig programmiert, hat man nicht
> zuviel Overhead.


Woher sollen die Assembler-Programmierer denn das wissen, wenn sie noch 
nie in C programmiert haben?

Sie glauben einfach nur die Gruselmärchen von C-Programmierern auf dem 
PC, die dann auf dem AVR auch unbedingt "double float" für 
Schleifenzähler und Portpins nehmen müssen.

Ein PC-Programmierer kennt warscheinlich überhaupt nicht den Datentyp 
"unsigned char" bzw. "uint8_t".


Peter

[Kachel - Heinz (Gast)]

Naja, ein bissel ASM-Wissen fördert das Verständnis der 
Controller-Architektur, was beim OP wohl noch nicht da ist, sonst würde 
er den Stack nicht im Flash vermuten.

Achja, die Feststellung, dass "ASM-Programmierer" zu Delays neigen, ist 
aus den Fingern gesogen. Es gibt hier wie da Solche und Solche, das ist 
keine Frage der benutzten Programmiersprache.

Zum Thema, wenn Dein AVR langsam voll wird, solltest Du auch mal schaun, 
ob Du nicht hier und da Ressourcen verschwendet hast. Oft hilft es 
schon, vernünftige Algorithmen zu nutzen.

KH

[sebba (Gast)]

einfach mal stop.

die diskussion gabs doch schon zu oft.
ihr habt natürlich alle recht - und jede programmiersprache
hat irgendwo ihre daseinsberechtigung

@sven:
was bastelst du denn grad?
32k vollschreiben is zwar grundsätzlich nicht schwer
allerdings gibt es viele kleine tricks wo man
(teilweise echt viel) sparen kann

und zum generellen verständnis wo was gespeichert wird
empfehl ich dir mal das AVR GCC Tutorial - da steht
einiges drin wo wann was gespeichert wird.

gruß,
auch sven

[Gast (Gast)]

Hi,

(falls noch nicht geschehen) die Compileroptimierung aktivieren bewirkt 
Wunder. Das Debuggen wird jedoch etwas schwieriger.

Gruß

[Sven L. (friemler)]

sebba wrote:
> was bastelst du denn grad?

Bin gerade dabei eine Temperatur- und Zeitanzeige mit Dot-Matrix-Modulen 
aufzubauen. Ist nicht schwer, doch hab ich mich bei der Codegröße völlig 
verschätzt. Vorher verwendete ich einen Mega16, der war aber wegen den 
Menüfunktionen, Grafikbefehlen (welche ich nur zu einem geringen Teil 
nutze) und diverser anderer Spielereien, wie der Anzeige der letzen 
Stunden- und Tageswerte (jeweils min/max) ziemlich schnell voll. Ach ja, 
DCF77 hab ich auch noch mit programmiert. Wenn man bedenkt, dass man vor 
nicht allzu langer Zeit komplette Betriebssysteme in dieser 
Speichergröße unterbringen konnte...

Zum Code: soll doch jeder programmieren wie er will, aber ich finde 3593 
Zeilen in C (incl. Kommentare) viel leichter zu warten, als 19739 Zeilen 
von dem was mein Compiler daraus macht.

Optimierungen beim Compilieren hab ich schon probiert, es wurde aber 
immer schlechter.

Im Anhang sieht man eine ganz normale Anzeige der aktuellen Temperatur 
und Zeit, solange der Empfang des dcf-Signals nicht von dem Zeilentrafo 
meines Monitors gestört wird.

Bitte keine Diskussion über Genauigkeit und Auflösung, man kann die 
Nachkommastellen und Durchschnittswerte individuell per Menü einstellen.

[Sven L. (friemler)]

Hier ein Diagramm der letzten Stunden, wobei die aktuelle Stunde 
vertikal invertiert dargestellt ist.

[Sven L. (friemler)]

Und hier die Temperaturanzeige im Großformat während des scrollens.

[Oliver (Gast)]

Äh, und damit sind 32kB voll? Und mit -Os wird es noch größer?

Zeig doch mal deine Code.

Oliver

[Sven L. (friemler)]

Hab gerade alle Optimierungen durchprobiert und der Rekord liegt bei 
82kByte sowie 2 mit je 33kByte, somit ist das s bei mir schon optimal. 
Aber das war nicht der Grund für meine anfangs gestellte Frage, trotzdem 
danke für die mir hier angebotene Hilfe.

Am Anfang hat auch alles schön brav in einen Mega 16 gepasst, doch dann 
kommen sehr schnell Änderungswünsche und Erweiterungen hinzu. Kleiner 
Auszug aus meinem Menü:
es kann eingestellt werden wieviele Pixel bei der großen Anzeige 
zwischen den Zeichen freigehalten werden soll;
soll das Grad Celsius Zeichen angezeigt werden?;
Anzahl der Nachkommastellen;
Mittelwert ADC;
was soll angezeigt werden (Temp+Uhr, T+U separat; nur Uhrzeit, nur 
Temp.);
soll das : -Zeichen bei der Uhr blinken;
soll die große Anzeige scrollen;
dann wieder Geschw. und Pause dazwischen beim scrollen;
usw. usw.

Irgendwann macht auch Kleinvieh Mist.

Den Temperaturabgleich kann man über ein anderes Menü einstellen, man 
benötigt da nur eine 'Mittentemperatur' und eine andere Referenz, welche 
man selber festlegen kann, den Rest erledigt der Controller.

Ihr könnt dazu gerne noch fragen, doch kann ich die erst nach dem 
Wochenende beantworten.

Also an alle: schönes Wochenende

[Benedikt K. (benedikt)]

Sven L. wrote:
> es kann eingestellt werden wieviele Pixel bei der großen Anzeige
> zwischen den Zeichen freigehalten werden soll;
> soll das Grad Celsius Zeichen angezeigt werden?;
> Anzahl der Nachkommastellen;
> Mittelwert ADC;
> was soll angezeigt werden (Temp+Uhr, T+U separat; nur Uhrzeit, nur
> Temp.);
> soll das : -Zeichen bei der Uhr blinken;
> soll die große Anzeige scrollen;
> dann wieder Geschw. und Pause dazwischen beim scrollen;
> usw. usw.
>
> Irgendwann macht auch Kleinvieh Mist.

Naja, aber das sind wirklich alles Sachen die jeweils mit wenigen 10 
Bytes bis maximal 100Bytes erledigt sind.
Bei 32kByte würde ich mal vermuten, dass sehr viel für Schriftarten usw. 
draufgeht. Ansonsten gibt es ja kaum Sachen die wirklich viel Platz 
brauchen, außer du hast alles als Spagetticode und alles mit float und 
printf usw. programmiert.

Aber davon mal abgesehen: Sieht wirklich schön aus...

[Sven L. (friemler)]

Dankeschön Benedikt.

ganz kurz:
Spaghetticode hab ich eigentlich nicht geschrieben, auch keine printf's 
verwendet (alles eigene Funktionen und der Zeichensatz befindet sich im 
EEPROM (wird durch ein anderes Programm dort hinein geschrieben)), aber 
dafür viele floats benötigt, um die Historienwerte der Temperatur 
(min/max für Stunden/Tage/Monate) zu speichern und dann auch grafisch 
darstellen zu können.

[Benedikt K. (benedikt)]

Sven L. wrote:
> dafür viele floats benötigt, um die Historienwerte der Temperatur
> (min/max für Stunden/Tage/Monate) zu speichern und dann auch grafisch
> darstellen zu können.

Daran wird es vermutlich liegen, dass soviel Flash gebraucht wird.
Ich verpackte Temperaturen meist in einen signed 16bit Wert, wovon das 
höherwertige Byte die Temperatur von -128°C bis +127°C angibt, und das 
niederwertige Byte die Kommastelle (also im Prinzip Temperatur *256). 
Eine Auflösung von 0,004°C sollte eigentlich auch für die meisten 
Berechnungen ausreichen.
Das spart die Hälfte an Speicherplatz (nur 2 Byte statt 4 Byte pro Wert) 
und vor allem Rechenleistung und Programmcode, da 16bit Zahlen für einen 
AVR wesentlich angenehmer sind als Fließkomma.

[(prx) A. K. (prx)]

Dito, nur dass ich in 1/10 oder 1/100 Graden arbeite.

[Simon K. (simon)]

Sven L. wrote:
> Dankeschön Benedikt.
>
> ganz kurz:
> Spaghetticode hab ich eigentlich nicht geschrieben, auch keine printf's
> verwendet (alles eigene Funktionen und der Zeichensatz befindet sich im
> EEPROM (wird durch ein anderes Programm dort hinein geschrieben)), aber
> dafür viele floats benötigt, um die Historienwerte der Temperatur
> (min/max für Stunden/Tage/Monate) zu speichern und dann auch grafisch
> darstellen zu können.

Festkommaarithmetik Lies dir das mal durch.

[*.* (Gast)]

Sogar 32-bit Integer sollten nicht so weh tun wie float.