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.
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
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 :(
Da war wohl jemand schneller also ich. Aber macht ja nix.
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
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...
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
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
Bitte 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.