Hallo,
ich nutze einen STM32F4 mit der EM:Blocks 2.20 IDE.
Dahinter steckt ein GCC 4.7.4..
Jetzt will ich die FPU benutzen.
Alle Defines zum anschalten sind gesetzt und die FPU wird eingeschaltet.
Alle Harken für "hard" sind gesetzt.
Aber so weit bin ich noch nicht.
Ich habe ein einfaches main Programm (ist nicht das wirkliche).
float F_Test, F_Test2;
void main (void)
{
float F_Test3;
F_Test = 1.123f;
F_Test3 = 3.456f * F_Test;
F_Test2 = F_Test / F_Test3;
}
Jetzt lase ich den Compiler laufen, im Code erwarte ich nun diese
V...Befehle. Ich habe aber smul und so weiter drin.
Lib Aufrufe sind nicht drin, nur wenn ich auf "soft..." stelle sind die
drin.
Also denke ich das der Compiler die Flags geliefert bekommt.
Ich kann leider nicht sehen wie der GCC aufgerufen wird, wird irgendwie
unterdrückt. Im der main.s steht .fpu=xxxxx-d16 drin.
Hat jemand eine Idee was ich falsch mache?
Oder was ich testen kann um da weiter zu kommen.
Viele Grüsse Peter
Peter schrieb:> void main (void)> {> float F_Test3;>> F_Test = 1.123f;> F_Test3 = 3.456f * F_Test;> F_Test2 = F_Test / F_Test3;> }
Der Compiler wird das Ergebnis vorher berechnen, sodass die CPU nichts
mehr zu tun hat. Evtl. optimiert er das auch komplett weg.
Das könnte sein.
Optimierung ist aber übrigens aus, damit der GCC nicht auf die Idee
kommt was weg zu lassen.
Ich habe das ganze auch mal zwischen anderen Codezeilen dazwischen
gepackt, mit dem selben Ergebnis.
Hier im Forum gab es schon einige Anfragen zu der FPU, aber da wurde
dann meistens die FPU nicht angeworfen. Und die Beispiele waren nicht
großartig anders wie jetzt meins.
Dann nimm doch mal keine voerher definierten Zahlen zum Multiplizieren,
sondern lies mal was am AD-Wandler ein und multipliziere dese Zahlen.
Dann hat der Compiler keine Chance, das schon vorher zu berechnen.
ich denke der gcc schmeißt den Code raus. Das hat nicht mal was mit
Optimierung zu tun. Da die Variablen nicht gebraucht werden sind sie
überflüssig. Versuch die mal als volatile zu deklarieren. Oder mach ein
printf oder sprintf damit.
Ich mache nachher mal weitere Tests.
In den anderen Beispielen stand aber auch nichts von volatile.
Kann aber wie bei mir nur ein Beispiel sein was nicht zu 100% richtig
ist.
Ich teste es und berichte später, wenn ich zu hause bin.
Habe doch schon gesagt das alle Flags an sind.
Nur richtig ansehen kann ich das nicht.
Ich habe jetzt alles mal auf volatile und einlesen eines Port-Register
geändert.
Und es ändert sich nichts, fmuls wird aufgerufen aber nichts mit v....
Eigentlich blöd weil ich diese Befehle nicht im Befehlssatz finde.
Ich habe noch einen Schalter gefunden um float Werte in FPU Register zu
laden. Und da bekomme ich eine Warnung das das nicht unterstützt wird.
Da stimmt irgend was überhaupt nicht.
Ich lade mir garade die EM:Blocks 2.30 Version mal sehen ob die Jungs
mist gebaut haben bei der 2.20 und einen Defekten GCC mit liefern.
Hat denn niemand mit diese TOOL Kombination die FPU am laufen?
Nun der Cortex M7 ist ja was ganz anderes, aber schön zu wissen das es
da geht.
Hatte noch keine Zeit um weiter zu testen!
Ob ich jemals einen wechsel zu EmBitz mache muss ich mir noch gründlich
überlegen. Nicht wegen Funktionen oder so, sondern weil die Entwickler
ein Lizenzsystem eingebaut haben. Eigentlich alle Projekte die ich
eingesetzt hatte und sowas eingeführt haben sind platt oder dümpeln
jetzt nur noch so dahin. Ich habe die meistens auch recht bald
deinstalliert.
Ich warte auf die .50 und sehe die mir dann an wie die Einschränkungen
aussehen.
Als alternative bleibt zum Glück immer noch das Basis Projekt
CODE:BLOCKS.
So ich habe es gerade getestet.
EM:Blocks 2.30 und EMBlitz 0.40.
Beide erzeugen nicht den erwarteten Code.
Welchen Windows GCC für ARM sollte ich jetzt suchen?
Oder hat jemand einen passenden Link griffbereit.
VG, Peter
Bei emblitz werden die meisten flags innerhalb der IDE eingetragen. Ich
habe nur keine Ahnung wie ich alle prüfen kann.
Ich schaue ins List file Main.s.
Einige flags finde ich da wieder.
Zum linken komme ich später.
Peter schrieb:
>Bei emblitz werden die meisten flags innerhalb der IDE eingetragen
nee makefile geht auch
Das hat beim STM32F746-DISCOVERY den Vorteil das man alles was im extern
angeschlossenen QSPI Speicher landen soll mit objcopy herausheddern
kann.
Der Trick ist dieser Eintrag im makefile:
ifeq ("$(MAKECMDGOALS)","Debug")
BIN_BASE := bin/Debug
CFLAGS += -g -gdwarf-2
ASFLAGS += -g
# optimization
OPT = -O0
else
BIN_BASE := bin/Release
# optimization
OPT = -O2
endif
im BIN_BASE stehen dann die Hexdateien
die eigentlichen Einsprungsmarken sind dann noch
Debug:
Release:
cleanDebug:
cleanRelease:
m.f.G.
Dieter
Hallo Peter,
Ich hab das mal geprüft, ebenfalls STM32F4.
Ich benutze GNU Tools ARM Embedded 4.9.2015q2 (also den aktuellsten)
zusammen mit eclipse.
Bei mir erzeugt dieses Programm
1
intmain(void){
2
floatpi=3.141592653;
3
floatErgebnis;
4
Ergebnis=pi*2.5;
5
while(1);
6
}
dieses Listing:
[asm]
main:
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 1, uses_anonymous_args = 0
@ link register save eliminated.
push {r7}
sub sp, sp, #12
add r7, sp, #0
ldr r3, .L3
str r3, [r7, #4] @ float
flds s15, [r7, #4]
fconsts s14, #4
fmuls s15, s15, s14
fsts s15, [r7]
.L2:
b .L2
.L4:
.align 2
.L3:
.word 1078530011
.size main, .-main
.ident "GCC: (GNU Tools for ARM Embedded Processors) 4.9.3 20150529
(release) [ARM/embedded-4_9-branch revision 224288]"
[/asm]
Nach kurzem googlen habe ich dazu eine Information auf Stackoverflow
gefunden (quelle:
http://stackoverflow.com/questions/21120225/why-does-gcc-generates-fxxx-instead-of-vxxx-floating-point-assembly-instructions)
Die fxxx Instruktionen sind die selben wie die vxxx Instruktionen. Es
hat sich nur die mnemonics geändert. GNU scheint also einen alten
disassembler zu benutzen.
Siehe hierzu folgende Seite von ARM:
http://infocenter.arm.com/help/topic/com.arm.doc.dui0473c/CIHFAHFG.html
~Lil B
Das erklär endlich mal warum ich diese F... Befehle habe, obwohl es die
eigentlich nicht gibt.
Dann bin ich beruhigt und kann ohne bedenken meine float Routinen
einbauen.
Danke Euch,
Peter
