|
Anzeige
|
MATH.H für MSP430 will nicht so ganz...
Gast
#36061
Hallo! Ich versuche schon seit einiger Zeit die MATH.H für MSPGCC zum Laufen zu bekommen. Hab dann aber immer eigene Funktionen geschrieben. Wenn ich MATH.H include, und dann z.B. SQRT(x) oder so aufrufe, findet der Compiler die Funktion nicht. Muss ich da vieleicht irgend etwas definen oder so? mfg W.U.
Gast
#36062
Nur mal vorweg: Ich besitze keinen MSP und habe den mspgcc aus diesem grunde auch nicht installiert, aber versuch mal 1.) Die funktionen klein zu schreiben, es gibt schlicht und einfach keine SQRT(), sqrt() hingegen schon. 2.) Vergiss das -lm beim compileraufruf nicht, das ding will ja auch gelinkt werden. Im uebrigen, es gibt eigentlich auch keine MATH.H, gewoehn dir an solche sachen klein zu schreiben, nur weil Windows (oft) case insensitive agiert heisst das noch nicht dass das ueberall so ist. mfg
Gast
#36063
1. Es muss sqrt(x) und nicht SQRT(x) sein. 2. Du musst den Linker noch die Option -lm übergeben um die Mathlibrary einzubinden. sqrt kostet dich aber gute 3kb-flash :(
Gast
#36064
Da war wohl jemand schneller also ich. Aber macht ja nix.
Gast
#36065
Hallo, danke. Werde das mit dem -lm versuchen. Die Sache mit der Großschreibung hab ich mir angewöhnt, um Wörter hervorzuheben. Ich versuch mal, ob man so z.B. <b>fett</b> schreiben kann. @r2d2, "sqrt kostet dich aber gute 3kb-flash" Das ist ja der blanke Waaahnsinn ! Ich habs gleich mal auf dem 8051 probiert: sqrt(): 170 Byte Dann brauch ich mich ja nicht mehr zu wundern, warum alle nicht 8051-Nutzer so oft über zu kleinen Flash klagen. Peter
Gast
#36067
Stimmt das mit den 3kb Flash wirklich? Ich hab mir eine kleines C
Unterprogramm geschrieben, dass mir die sqrt funktion erfüllt:
unsigned long Quadratwurzel (unsigned long n)
{
unsigned long answer;
unsigned long prevanswer;
unsigned char x;
if (n!=0)
{
prevanswer=n;
answer=n/2;
for(x=0;x<13;x++)
{
prevanswer=answer;
answer=(prevanswer+(n/prevanswer))/2;
}
}
else answer=0;
return(answer);
}
Entweder ist die sqrt zu kompliziert programmiert worden, oder das mit
den 3kb stimmt nicht...
Gast
#36068
Dieses Testprogramm:
#include <math.h>
int main (void)
{
int c;
c=sqrt(4);
for (;;) ;
}
compiliert mit:
msp430-gcc -c -save-temps -g -O2 -funsigned-char -funsigned-bitfields
-fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Werror
-Wa,-ahlms=test.lst -mmcu=msp430x123 -I. test.c -o test.o
msp430-gcc -Wl,-Map=test.map,--cref -mmcu=msp430x123 test.o -lm
-L/usr/local/msp430/lib --output test.elf
msp430-objdump -S -h test.elf > test.dis
msp430-objcopy -O ihex -R .eeprom test.elf test.hex
msp430-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load"
--change-section-lma .eeprom=0 -O ihex test.elf test.eep
msp430-objcopy: --change-section-lma .eeprom=0x00000000 never used
ergibt:
msp430-size --target=ihex test.hex
text data bss dec hex filename
0 3154 0 3154 c52 test.hex
Da scheint wohl noch einiges machen zu lassen, vorallem weil ich ja mit
4 eine konstante vorgegeben habe die ein spezialfall ist.
@r2d2,
das ist aber für das komplette Programm und nicht nur für die sqrt().
Der Keil schlüsselt das im Map-File schön auf:
INPUT MODULES INCLUDED:
TESTSQRT.OBJ (TESTSQRT)
STARTUP.OBJ (?C_STARTUP)
C:\8051\KEIL_C51\LIB\C51FPS.LIB (?C?CASTF)
C:\8051\KEIL_C51\LIB\C51FPS.LIB (SQRT)
C:\8051\KEIL_C51\LIB\C51FPS.LIB (?C?FPGETOPN)
C:\8051\KEIL_C51\LIB\C51FPS.LIB (?C?FPADD)
C:\8051\KEIL_C51\LIB\C51FPS.LIB (?C?FPDIV)
C:\8051\KEIL_C51\LIB\C51S.LIB (?C?LNEG)
LINK MAP OF MODULE: MAIN.OUT (TESTSQRT)
TYPE BASE LENGTH RELOCATION SEGMENT NAME
-----------------------------------------------------
* * D A T A M E M O R Y * *
REG 0000H 0008H ABSOLUTE "REG BANK 0"
DATA 0008H 0006H UNIT DATA_GROUP
IDATA 000EH 0010H UNIT ?STACK
* * C O D E M E M O R Y * *
CODE 0000H 0003H ABSOLUTE
CODE 0003H 0015H UNIT ?PR?MAIN?TESTSQRT
CODE 0018H 000CH UNIT ?C_C51STARTUP
CODE 0024H 0222H UNIT ?C?LIB_CODE
CODE 0246H 00AAH UNIT ?PR?SQRT?SQRT
Das bedeutet, er benötigt noch einiges aus der floating point lib:
222h = 546 Byte
Insgesamt ergeben sich also 246h+aah = 752 Byte.
Wenn man aber schon mit floating point arbeitet und nur die Funktion
sqrt() hinzufügt, dann ergibt das beim Keil C51 eine Vergrößerung um
die besagten aah = 170 Byte.
752 statt 3154 Byte ist aber immer noch ein bemerkenswerter
Unterschied.
Peter
Gast
#36070
klar, ist das das ganze programm. aber kannst du mir ein einfacheres zeigen, bei den der code <3kb wird? @r2d2, ich habe genau das gleiche Programm übersetzt. Ich fand es eben nur bemerkenswert, daß es bei den verschiedenen MC-Architekturen doch teilweise recht erhebliche Unterschiede in der Codespeicherausnutzung gibt. Peter Beim avr-gcc sind es 572 Byte. 88 davon für sqrt, der Rest Float. Die Codegröße der Float-Lib beim msp430-gcc hat nichts mit der Codespeicherausnutzung des Prozessors zu tun. Der Grund dafür ist einfach, dass der msp430-gcc leider noch eine völlig unoptimierte IEEE754 Float Bibliothek hat. Die optimierte Lib des IAR-Compilers ist um Größenordnungen kleiner und schneller. Peter, würdest du mir den Gefallen tun die angehängte Funktion für 8051 zu kompilieren und das Assembler-Listing hier zu posten? Nur mal so aus Interesse. @Andreas,
ich hab mir den Kopf zerbrochen, wozu diese Funktion nütze ist.
Vielleicht kannst Du Licht ins Dunkel bringen, ich beschäftige mich
nicht gern mit unnützen Dingen.
Ich habs aber trotzdem übersetzt (siehe Anhang). Allerdings ist mir
sofort der doppelte Test "b == 0" ins Auge gesprungen, hab ihn gleich
wegoptimiert. Sowas stört mich einfach.
unsigned int gcd2 (unsigned int a, unsigned int b)
{
if( b == 0 ){
if( a == 0 )
a = 1;
return a;
}
if( a != 0 ){
while( a != b ){
if( a < b ){
b -= a;
}else{
a -= b;
}
}
}
return b;
}
Peter
Die Funktion berechnet den größten gemeinsamen Teiler. Keine Überraschungen beim Codegrößen-Vergleich: MSP430 (gcc): 40 Bytes AVR (gcc): 58 Bytes 8051 (Keil?): 54 Bytes Antwort schreiben |
Anzeige
|
