Problemy z GCC dla ARMów...

Witam!!

Dostaję taki oto komunikat przy próbie "budowy projektu" przy pomocy GCC (z pakietu Yagarto):

arm-elf-ld: ERROR: swi_handler.o uses hardware FP, whereas main.out uses software FP arm-elf-ld: failed to merge target specific data of file swi_handler.o

Czyli problem przy linkowaniu, ale "wyróżnia się" tylko jeden plik ;)... niestety, nie wiem nawet czym, bo co to znaczy to FP?? Floating point?? ;) chyba nie :).. dodam, że wszystkie pliki tworzę z tymi samymi flagami przekazywanymi do kompilatora, dlatego nie rozumiem, czemu ten jeden inaczej używa tajemniczego FP... Co dziwniejsze - takie zachowanie obserwuje tylko na jednym komputerze, a drugim wszystko jest OK... a na obu instalowalem DOKLADNIE TA SAMA WERSJE oprogramowania!! Co moze byc nie tak?? PRzesyłam cały plik makefile :)...

Pozdrawiam Konop

PS Oczywiście make clean nie pomaga ;)

NAME = demo2378_blink_flash

CC = arm-elf-gcc CXX = arm-elf-g++ LD = arm-elf-ld -v AR = arm-elf-ar AS = arm-elf-as CP = arm-elf-objcopy OD = arm-elf-objdump

CFLAGS = -I./ -c -fno-common -O0 -g CXXFLAGS = -I./ -c -fno-common -O0 -g AFLAGS = -ahls -mapcs-32 -o LFLAGS = -Map main.map -Tdemo2378_blink_flash.cmd CPFLAGS = -O binary HEXFLAGS = -O ihex ODFLAGS = -x --syms

all: test

clean: -rm SPI_SSP0.o crt.lst main.lst fio.o irq.o crt.o swi_handler.o swi_calls.o uart0.o target.o main.o main.out main.hex main.map main.dmp main.bin

test: main.out @ echo "...copying" $(CP) $(CPFLAGS) main.out main.bin $(OD) $(ODFLAGS) main.out > main.dmp @echo "...building hex" $(CP) $(HEXFLAGS) main.out main.hex @echo "...creating main.lst file" $(OD) -h -S main.out >main.lst

main.out: crt.o swi_handler.o swi_calls.o target.o fio.o irq.o main.o uart0.o SPI_SSP0.o demo2378_blink_flash.cmd @ echo "..linking" $(LD) $(LFLAGS) -o main.out crt.o main.o SPI_SSP0.o uart0.o swi_handler.o swi_calls.o target.o fio.o irq.o

target.o: target.c

$(CC) $(CFLAGS) target.c

fio.o: fio.c

$(CC) $(CFLAGS) fio.c irq.o: irq.c

$(CC) $(CFLAGS) irq.c

crt.o: crt.s @ echo "...assembling crt.S" $(AS) $(AFLAGS) crt.o crt.s > crt.lst swi_calls.o: swi_calls.c $(CC) $(CFLAGS) swi_calls.c swi_handler.o: swi_handler.S @ echo "...assembling swi_handler.S" $(AS) $(AFLAGS) swi_handler.o swi_handler.s > swi_handler.lst

uart0.o: uart0.c @ echo "...compiling uart0.c file" $(CC) $(CFLAGS) uart0.c SPI_SSP0.o: SPI_SSP0.c @ echo "...compiling SPI_SSP0.c file" $(CC) $(CFLAGS) SPI_SSP0.c

main.o: main.c @ echo "...compiling main.c file" $(CC) $(CFLAGS) main.c

Reply to
Konop
Loading thread data ...

FP tutaj to właśnie floatig point... Zauważ, że ten jeden plik masz w asemblerze (nielicząć crt.s, ale ten raczej nie używa zmiennego przecinka) i w związku z tym używa innych flag kompilacji. Pakietu yagarto nie używałem, w gcc domyślnie jest hardware FP, ale, teoretycznie, pakiet mógł zostac wybudowany z innymi flagami domyślnymi.

Przyszło mi jeszcze do głowy - porównaj zmienne środowiskowe na tych komputerach. Może zostały gdzieś ustawienia z innego projektu (CFLAGS ?). W make-u zmienne środowiskowe mają wyższy priorytet, niż ustawienia w makefile-u.

Szeluś

Reply to
szelus

Hmm, okej, wiesz, ja nie bardzo się w tym wszystkim orientuję ;P... dla mnie to całe gcc, makefile itp to totalna głupota ;P... ale nieważne :)... wczoraj już nic mi się nie chciało z tym robić, dziś w firmie pisałem dalej (tam to zawsze działało), wróciłem do domu i o dziwo - działa bez zarzutu ;P... dlatego teraz nie będę na siłę szukał problemu, skoro sam się rozwiązał ;P... a co do tego Floating Point - dziwi mnie to dlatego, że plik, przez który było to całe zamieszanie, chyba nie korzysta z FP :P... Wyciąłem z niego komentarze i zamieszczam poniżej ;).. ma to być włączanie i wyłączanie przerwan sprzętowych przez przerwania programowe, plik nie jest mojego autorstwa. Patrzę i patrzę - i FP nie widzę, choć baaaardzo bym chciał;)..

Ale wielkie dzięki za odpowiedź!! :)....

Pozdrawiam Konop

.equ SWI_IRQ_DIS, 0 .equ SWI_IRQ_EN, 1 .equ SWI_FIQ_DIS, 2 .equ SWI_FIQ_EN, 3

.equ I_Bit, 0x80 .equ F_Bit, 0x40

.arm .text

SoftwareInterrupt: LDR R0, [LR, #-4] /* get swi instruction code (ARM-mode) */ BIC R0, R0, #0xff000000 /* clear top 8 bits leaving swi "comment field"=number */ CMP R0, #4 /* range check */ LDRLO PC, [PC, R0, LSL #2] /* get jump-address from table */ MOVS PC, LR /* if out of range: do nothing and return */

SwiFunction: .word IRQDisable .word IRQEnable .word FIQDisable .word FIQEnable

IRQDisable: MRS R0, SPSR ORR R0, R0, #I_Bit MSR SPSR_c, R0 MOVS PC, LR

IRQEnable: MRS R0, SPSR BIC R0, R0, #I_Bit MSR SPSR_c, R0 MOVS PC, LR

FIQDisable: MRS R0, SPSR ORR R0, R0, #F_Bit MSR SPSR_c, R0 MOVS PC, LR

FIQEnable: MRS R0, SPSR BIC R0, R0, #F_Bit MSR SPSR_c, R0 MOVS PC, LR

Reply to
Konop

Witam,

tu nie chodzi o to czy kod uzywa FP czy nie, ale z jakimi flagami byla kompilacja. A swoja droga, widze ze wlaczasz i wylaczasz przerwania w ARM. Z wylaczaniem jest maly trik, opisany w nocie aplikacyjnej Atmela:

formatting link

-------------------------------- When the application must not be interrupted, interrupts must be disabled at core level. This can be done using the following code: mrs r0, CPSR orr r0, r0, #0x80 (or 0x40 for FIQ) msr CPSR, r0 While the processor is executing the 'msr CPSR, r0' instruction, the active interrupts are disabled only on the next clock cycle. If an IRQ or FIQ interrupt occurs during the execution of this instruction the bit IRQ or FIQ is set both in the CPSR and in the SPSR (Saved Program Status Register) and the processor enters the interrupt handler routine. The application developer must take care not to modify the IRQ or FIQ bit in the SPSR before exiting from the interrupt service routine. If the interrupt handler does something like: mrs r0, SPSR bic r0, r0, #0x80 (or 0x40 for FIQ) msr SPSR, r0 The IRQ or FIQ interrupt is re-enabled at the exit and the processor resumes execution after the 'msr CPSR, r0' instruction. The interrupt is enabled while the application routine assumes that it is not.

---------------------------------

Pozdr AK

Konop pisze:

Reply to
AK

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.