Programmspeicher beim Tiny26 voll

[Ingo L. (grobian)]

Wie kann es denn kommen, dass bei diesem Programmchen der Speicher 
restlos voll ist und die unten genannte Fehlermeldung ausgibt?


#include <avr/io.h>
#include <math.h>
#define PI 3.1415926
#define SINUS(b) ((sin(2*PI*b/360)))
int a;


 int main(void)
  {
   DDRB  = 0xff;

    for (a=0;a<=360;a++)
        {
            PORTB = SINUS(a)*127+128;
        }

    return 0;
  }

Device: attiny26
Program:    4932 bytes (240.8% Full)
(.text + .data + .bootloader)
Data:        266 bytes (207.8% Full)
(.data + .bss + .noinit)

[... .. (docean)]

rofl

 sinus auf einem tiny...

+ float Rechnung (dein PI)...

[Walter T. (nicolas)]

Hallo,

es gibt Libraries, die es allein schon schaffen, den Flash 
vollzukriegen.

stdio.h

 ist z.B. so ein Kandidat. Versuch das Ganze mal mit einer Sinustabelle, 
die 360 Werte (komische Zahl) nehmen mit Sicherheit weniger Platz ein 
als sämtliche mathematischen Funktionen zusammen.

[Ingo L. (grobian)]

mit der Tabelle hatte ich ja schon gemacht..ging ja auch ganz gut. 
Wollte aber von der Tabelle weg.
Also ist es die math.h die mir den Flash vollstopft, sehe ich das 
richtig ?

[Timmo H. (masterfx)]

>Also ist es die math.h die mir den Flash vollstopft, sehe ich das
>richtig ?
Die math.h selbst nicht, aber das was der linker dazulinkt. Du kannst im 
Listfile auch sehen welche Funktionen das sind. Aber das mit 
Floatingpoint kannst du auf nem tiny vergessen. Da muss man schon selber 
etwas tricksen. Ist doch auch viel schöner wenn man vor einem Problem 
steht, das gelöst werden muss.

[Jörg W. (dl8dtl) (Moderator)]

Nicolas S. wrote:

> es gibt Libraries, die es allein schon schaffen, den Flash
> vollzukriegen.

stdio.h

 ist z.B. so ein Kandidat.

Das ist, mit Verlaub, Quatsch.

Erstens ist stdio.h keine Library, sondern ein Headerfile (welches
das Interface zu Teilen der Standard C Library beschreibt).  Von
einem Headerfile allein entsteht (in aller Regel) kein einziges Byte
an Code.

Zweitens entsteht durch das Linken eine Library selbst auch kein
zusätzlicher Code.  Den muss man erst aus dieser anfordern.  Ganz
nebenbei, die printf- & Co.-Routinen passen entgegen deiner
Behauptung (bis auf die Gleitkommaoption natürlich) in der Tat
sogar noch in einen ATtiny26 hinein.  Nicht, dass ich es in irgend-
einer Weise für sinnvoll hielte, aber so riesig sind sie halt auch
nicht.

[Peter D. (peda)]

Ingo Laabs wrote:
> Device: attiny26
> Program:    4932 bytes (240.8% Full)
> (.text + .data + .bootloader)
> Data:        266 bytes (207.8% Full)
> (.data + .bss + .noinit)

Die 266 Bytes SRAM sagen, daß Du den Linkerschalter -lm nicht benutzt 
hast.
-lm ist ne deutlich schlankere Float-Lib.

Standardmäßig wird leider eine nicht für den AVR optimierte Lib 
eingebunden.
Deshalb auch der extreme SRAM-Bedarf.


Peter

[Ingo L. (grobian)]

@ Peter
>>Die 266 Bytes SRAM sagen, daß Du den Linkerschalter -lm nicht benutzt
>>hast.
>>-lm ist ne deutlich schlankere Float-Lib.

kannst Du mir das genauer erklären?

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

Es gibt eine generische nicht optimierte Lib in der libgcc. Und eine 
optimierte in der libm. Markenzeichen der libgcc Version ist eine 256 
Byte grosse Tabelle im SRAM.

Die libm kriegst du mit -lm in der Library-Liste vom Studio (nicht in 
den Linker-Optionen), bzw hinten dran im Aufruf beim Linken.

[Ingo L. (grobian)]

habe jetzt die libm.a im AVR hinzugefügt und jetzt funktioniert alles 
:-) FREU