ARM C-Compiler

Ach, die haben auch ein Mikro-Pascal im Angebot. Nett, aber kann auch 
keine SVC's.

Mein Rat: Lade dir zu allererst die Demoversion des Keil für Arm 
herunter. Die ist erstmal gut für 32 K Code (glaub ich..) und es ist ein 
fähiger Compiler, mit dem man die Features der Hardware auch wirklich 
benutzen kann. Du kannst ja später dir ne Demo eines anderen Compilers 
besorgen und mal gegen den dir dann schon bekannten Keil testen. Häufig 
genug stecken bei anderen Angeboten nur eine IDE plus GCC dahinter. Ich 
hatte bei der "Lernbetty" hier im Forum diverse Grrrr-Momente mit dem 
GCC erlebt: keine Pragmas, umständliche Interrupt-Deklarationen, 
überhaupt keine SVC's (!!!), undokumentierte Seltsamkeiten beim Linken, 
kurzum mein Rat: Lern als Maßstab erstmal die originalen ARM-Tools 
kennen und teste dann das, was du dir evtl. kaufen willst.

Nebenbei: Es ist ja nicht mehr lange hin bis zur nächsten Embedded, wo 
man sowas auch mal aus der Nähe sehen kann vor dem Kauf.

W.S.

eigendlich wollte ich keine odyssee starten und diverse Compiler 
"durchprobieren". Selbst wenn der Keil mit Abstand der beste ist wäre 
für mich einfach zu teuer. ich wollte nur wissen ob jemand besagten 
Compiler verwendet oder schon benutzt hat und einigermassen einstufen 
kann in brauchbar oder Finger weg.
Jürgen

Ja, Crossworks ist nicht schlecht. Leider aber etwas eigen. Hier ist 
zwar auch der gcc drunter aber eben nur anders. Programme die mit dem 
gnu-arm-tool gcc erstellt werden lassen sich problemlos in Keil, 
LpcXresso, Coocox (etwas umständlich) debuggen. Der verwendete 
Startupcode ist dafür nicht relevant. Das ist bei Crossworks anders. 
Wenn man nicht den Crossworks-Startupcode verwendet und deren Libs und 
Linkerscripts, enden die meisten Versuche in Hardfaults. Jedenfalls beim 
LPC1769. Ich muss wirklich sagen leider, weil der Debugger sonst 
wirklich sehr gut ist. Wenn man als Ziel ein Programm hat was nur aus 
freien Bestandteilen besteht, hat man somit ein Problem. Für mich 
inakzeptabel.

A. B. schrieb:
> Die Keil IDE z.B. ist  total unkomfortabel und auf nem Stand von
> (gefühlt) 1990. Andere (Eclipse-basierte) IDEs bieten da deutlich mehr.

Du findest Eclipse komfortabel? Was daran jetzt genau? Die Startzeiten? 
Das sonderbare Workspace-Konzept in dem man nicht einfach "mal eben" ein 
Projekt oeffnen kann? Oder sind es die durch die Bank unfähigen 
Debugger-Plugins für MCUs die dir das Leben erleichtern?

moin moin,

zur Zeit nutze ich das oben angegebene mikroPascal.
Gut:
- Project aufmachen, Typ einstellen
 oder
- Projectdatei starten, compelieren, flashen..fertig.

- kein handtieren mit make, script usw.

Schlecht:
- Die IDE hat einige ShortCuts die anders belegt sind, als z.B in 
Delphi.
- Der Preis.
- keinen direkten Sourcecodes der Libs.

Mit Gruß
Pieter

A. B. schrieb:
> Ich habe nicht den Anspruch an eine aktuelle Entwicklungsumgebung, das
> sie auf nem 486 Grabbelkisten PC blitzschnell startet

Ist eben Java - und Java IST eben langsam im Vergleich zu jeder im 
Maschinencode vorliegenden IDE.

Geht es euch hier eigentlich um Oberflächensachen, wie bunt, wie in 
Projekte,Workspaces usw. organisiert?

Ich weiß ja, daß ich mit meiner Art, ohne IDE und ohne Debugger zu 
arbeiten, hier der Exot bin und daß die meisten erstmal drauflos daddeln 
wollen und sich dann davon überraschen lassen müssen, was zum Schluß an 
Code herauskommt. OK, beim GCC ist das erwiesenermaßen auch bitter 
nötig.

Aber mir ging es erstmal um die Qualitäten des Compilers und nicht um 
irgendwelche IDE's. Und ich glaube, der Jürgen wollte genau DAS auch zu 
allererst wissen.

W.S.

Übertreibts mal nicht mit dem Schlechtmachen des gcc. Die vielen 
verschiedenen gcc die mit den IDEs kommen und den freien wie 
https://launchpad.net/gcc-arm-embedded unterscheiden sich kaum. Die 
meisten Unterschiede liegen in Anpassungen der newlib. Wenn man die 
Funktionen, die aus der newlib kommen und immer mal wieder zu Problemen 
führen (printf, malloc u.s.w.), durch eigene angepasste Implementationen 
ersetzt, ist man die Sorgen los. Ich habe bisher noch keinen Fehler im 
gcc gefunden der definitiv ein Compiler-Fehler war. Ich entwickle und 
debugge zu 90% unter VC. Das was dabei rauskommt, ist aber zu 90% mit 
dem gcc unter Linux übersetzt und läuft auch da. Hin und wieder mag der 
gcc mal was nicht was der VC frisst und umgekehrt. Aber wenn der Code 
unter beiden Compilern übersetzt ist, läuft er auch auf beiden. Ich 
wüsste nicht was ein Compiler so viel besser machen kann wie der gcc, 
dass es einen 4-5stelligen Betrag rechtfertigt. Das lässt sich auch auf 
den embedded Bereich übertragen. Ob der Keil-Compiler eventuell 10% 
kleineren Code macht oder nicht, will ich nicht mal wissen. Das größte 
Optimierungspotential liegt bei einem selbst. Sobald es aber um 
Assembler oder Assemblercode in C-Dateien geht, ist man mit Keil auf 
einer einsamen Straße. Das ist nur zu sich selbst kompatibel. Deswegen 
benutze ich den Keil zwar zum Debuggen, aber nur in Verbindung mit gcc. 
(und makefiles).

temp schrieb:
> Ob der Keil-Compiler eventuell 10%
> kleineren Code macht oder nicht,

Ja, das willst du nach eigenem Bekunden nicht wissen.

Ich aber.

Mir haben die kürzlich gesammelten Erfahrungen mit der Lernbetty 
gereicht, um im Nachhinein die Anschaffung des Keils als genau richtige 
Entscheidung zu bestätigen. Und: unter den professionellen Tools ist er 
noch einer der billigeren. Guck auf der nächsten Embedded mal zu IAR 
oder Green Hills und Konsorten oder zu ARM selber.

Das Schreiben der gesamten Lernbetty-Quellen und das Ausprobieren 
derselben hat mich nicht mal halb soviel Zeit gekostet wie den GCC zum 
Laufen zu bringen. Wenn ich das auf die Dinge umrechne, die ich 
beruflich mache, dann hat sich die Anschaffung des Keils schon beim 
allerersten Projekt voll und ganz bezahlt gemacht.


Aber mal zum GCC selber:

Erstmal stören die elenden Probleme, die man bei GCC mit dem Linken 
kriegt und die man auch durch Lesen der Doku nicht in den Griff kriegt - 
stattdessen ist Probieren angesagt. Stichwort: fälschlich vom Linker 
eingesetzte Stubs.

Zweitens die diversen Dinge, die der GCC eben überhaupt nicht kann und 
für die man Workarounds braucht, die natürlich wieder Code+Zeit kosten.

Drittens die Unterschiede im erzeugten Code. Der Code vom GCC ist lausig 
im Vergleich zu dem vom ARM. Bei der Lernbetty hab ich fast Faktor 1.5 
feststellen müssen. Also mal im Klartext: Das, was der ARM in einen 32 K 
großen Codespeicher hineinbekommt, erfordert beim GCC fast 48 K. Das ist 
ne Menge Holz und es macht schon nen preislichen Unterschied, ob man nen 
32K Flash Controller einsetzen kann oder auf nen >=64K Flash Controller 
zurückgreifen muß, den man obendrein mit Faktor 1.5 schneller takten muß 
für die gleiche Funktionalität.


Und nochwas:
temp schrieb:
> Sobald es aber um
> Assembler oder Assemblercode in C-Dateien geht,...

...erschlage ich jeden mit nem nassen Feudel, der auch nur ansatzweise 
so etwas zu praktizieren beabsichtigt. Assembler gehört in ne separate 
Assemblerquelle und nicht in ne C-Quelle.

Wohlgemerkt, ich hab nix gegen den GCC, aber in seiner arm-none-eabi 
Ausführung ist er ein recht mäßiger Compiler, der viel Streß verursacht 
und nicht wirklich gut an die Zielarchitektur angepaßt ist. Im 
Bastlerumfeld hat niemand was dagegen, aber ihn beruflich einsetzen zu 
wollen, hätte ich ernste Bedenken.

W.S.

W.S. schrieb:
> Drittens die Unterschiede im erzeugten Code. Der Code vom GCC ist lausig
> im Vergleich zu dem vom ARM. Bei der Lernbetty hab ich fast Faktor 1.5
> feststellen müssen.

Stell mal 2 Projekte zum Vergleich hier rein die diesen Unterschied 
beweisen. Bis dahin: Märchen!!!

>Wohlgemerkt, ich hab nix gegen den GCC, aber in seiner arm-none-eabi
>Ausführung ist er ein recht mäßiger Compiler, der viel Streß verursacht
>und nicht wirklich gut an die Zielarchitektur angepaßt ist. Im
>Bastlerumfeld hat niemand was dagegen, aber ihn beruflich einsetzen zu
>wollen, hätte ich ernste Bedenken.
>
>W.S.

An Deiner Stelle würde ich mit meiner Unwissenheit nicht bei jeder
unpassenden Gelegenheit hausieren gehen.

Das ist nicht erst langsam peinlich.

A. B. schrieb:
> ...ich bin z.B. daran gescheitert das mit einem
> Codesourcery Compiler zum laufen zu kriegen.

Sollte mittels: http://gnuarmeclipse.livius.net plugin gehen.
Damit Yagarto einzurichten war jedenfalls einfacher als die Beschreibung 
von Yagarto selbst.
Ansonsten find ich Rowley ziemlich gut, zumal die meinen Segger J-Link 
direkt unterstützen. Insbesondere auch Databreakpoints, die gehen via 
GDB-Server nicht (zumindest hab ich es noch nicht hinbekommen).

A. B. schrieb:
> Ich maße mir nicht an die Qualität eines Compilers beurteilen zu können.
> Ich programmiere und wenn die Funktionalität erreicht ist, welche ich
> erwarte dann bin ich glücklich. Ich wüsste jetzt auch nicht, was an GCC
> so schlecht sein soll?

Bitte etwas genauer. Hier geht es um den arm-none-eabi-gcc und es gibt 
ja eine ganze Reihe Portierungen auf diverse Zielarchitekturen, bei 
denen der erzeugte Code jeweils besser oder schlechter sein mag.

Aber weiter oben hat ja jemand dumm herumgerülpst, ohne auch nur im 
Mindesten sich zum Lesen zu bequemen, also geb ich hier mal ein 
konkretes Zahlenbeispiel:

Die Basiskomponente der Lernbetty heißt BettyBase und man kann sie in 
compilierter Form (einmal Arm/Keil und einmal GCC) hier in der 
Codesammlung herunterladen. Darin enthalten sind 7 Fonts und ein Bild, 
zusammen 22900 Bytes groß. Der Rest ist Code und kleinere konstante 
Daten.

BettyBase per Arm/Keil erzeugt: 38780 Bytes,
dasselbe  per GCC erzeugt:      48448 Bytes

Zieht man die Fonts+Bild ab, so ergibt das 15880 Bytes bei Keil und 
25548 Bytes bei GCC. Das macht ein Verhältnis von 1 : 1.6 aus oder mit 
anderen Worten: Wo der Keil mit 2 Befehlen auskommt, braucht der GCC 
rund 3 Befehle. Sowas nenne ich keinen guten Code. OK, er funktioniert, 
das ist wahr und gut und damit ist die Benutzbarkeit gegeben, aber mehr 
auch nicht. Zum Basteln ist das allemal ausreichend und auch du wärest 
damit glücklich. Auch ich finde das in Anbetracht der übrigen Umstände 
in Ordnung, aber man sollte sich den realistischen Blick bewahren und 
die Dinge so sehen wie sie sind. Genau deswegen mein Rat ganz weit oben: 
erstmal den Keil herunterladen und damit anfangen - damit man mal ne Art 
Referenz bekommt. Dann kann man immer noch je nach Projekt auf den GCC 
umschwenken oder eben bei kleineren Sachen unterhalb 32K beim Keil 
bleiben. Hier lese ich jedoch andauernd Beiträge von Leuten, die außer 
dem GCC noch nie was anderes gehabt haben und dennoch recht überheblich 
große Töne spucken.

W.S.

W.S. schrieb:
> BettyBase per Arm/Keil erzeugt: 38780 Bytes,

wurde ohne Optimierung erzeugt

> dasselbe  per GCC erzeugt:      48448 Bytes

wurde mit -O3 erzeugt

Desshalb kannst du wohl nicht aufgrund der Grösse des Hex-Files auf die 
Qualität des Compilers/Linkers schliessen.

Mit
-O3
    Optimize yet more. -O3 turns on all optimizations specified by -O2 
and also turns on the -finline-functions, -funswitch-loops, 
-fpredictive-commoning, -fgcse-after-reload, -ftree-vectorize, 
-fvect-cost-model, -ftree-partial-pre and -fipa-cp-clone options.

wird wohl eher auf Speed optimiert, wenn dir die Grösse wichtig ist 
solltest du wohl

-Os
    Optimize for size. -Os enables all -O2 optimizations that do not 
typically increase code size. It also performs further optimizations 
designed to reduce code size.

verwenden.

Cheers

Ich habe mir grade mal das zip "LernBetty_R0.03aktualisiert.zip" 
reingezogen.
So wie das makefile gebaut ist wundert's mich nicht. Wenn man -O3 gegen 
-Os ersetzt landet man schon bei 41k. Wenn dann noch die beim gcc 
üblichen
-ffunction-sections -fdata-sections und --gc-sections beim ld verwendet 
werden, wird das bin nur noch 34.924 Bytes lang.
Ob das so noch funktioniert kann ich nicht sagen, da ich dafür keine 
Hardware habe.

So, LernBetty_R0.03aktualisiert.zip wollte ich auch mal schnell 
durchlaufen lassen... ging aber nicht. Verwendet man ein Datei- bzw. 
Betriebsystem, was Groß- und Kleinschreibung unterscheidet, muss man 
schon etwas anpassen:

klaus@LittlX:~/src/stm32/LernBetty_R0.03/BettyBase$ grep -i Tasten.h *
Appfinder.c:#include "tasten.h"
BettyWorkMenu.c:#include "tasten.h"
cmd.c:#include "tasten.h"
Interrupts.c:#include "tasten.h"
Interrupts.c~:#include "Tasten.h"
main.c:#include "tasten.h"
setup.c:#include "tasten.h"
Systemtick.c:#include "Tasten.h"
Tasten.c:#include "Tasten.h"
tasten.h:/* SwissBetty-TV-Fernbedienung: Tasten.h */

(Tasten.h ist nur ein Beispiel). Dies könnte man bei einer zukünftigen 
Release evtl. noch vereinheitlichen.

Andreas Schwarz schrieb:
> Das ist eine Milchmädchenrechnung, weil du damit nicht nur den vom
> Compiler generierten Code, sondern auch die Bibliotheken vergleichst.

Milchmädchen hin oder her..
Im Grunde ist das egal, denn wenn der Compiler eben auch ne Menge 
umfänglicher Bibliotheksfunktionen braucht, um lauffähigen Code zu 
erzeugen, dann ist das Ergebnis halt länger und in aller Regel auch 
langsamer.

Ich hatte schweren Ärger beim GCC-Linker mit Wrapper-Funktionen für den 
SVC, die ich in Assembler geschrieben habe, weswegen ich mir den 
erzeugten Code per Reassembler angeschaut habe. Von da her weiß ich, wie 
umständlich der Code vom Gcc im Vergleich zu dem vom Arm dabei gewesen 
ist.

Ach ja, ich habe wirklich nix dagegen, wenn hier jemand aus der 
GCC-Riege sich mal hinsetzt und für die Yagarto-Distribution eine 
vernünftige Dokumentation schreibt, wo man nachlesen kann, wie dort 
was aufgerufen und benutzt werden muß, damit man ein gutes Ergebnis vom 
GCC bekommt. Das wäre endlich mal was Nützliches.

W.S.

W.S. schrieb:
> Milchmädchen hin oder her..
> Im Grunde ist das egal, denn wenn der Compiler eben auch ne Menge
> umfänglicher Bibliotheksfunktionen braucht, um lauffähigen Code zu
> erzeugen, dann ist das Ergebnis halt länger und in aller Regel auch
> langsamer.

Das ist gelinde gesagt Blödsinn. Wenn ich mich dazu entscheide z.B. die 
printf aus der newlib zu verwenden, dann weiss ich auch was für ein 
Klotz das ist. Dafür hat man dann auch den vollen Umfang aller 
erdenklicher Formatierungsoptionen. Warum soll das aber großartig 
langsamer werden? Das eine hat mit dem anderen nicht unbedingt was zu 
tun. Ohne --gc-sections beim Linken kommt eben einiges an nicht 
verwendeten Code ins Binary. Das sollte einem aber auch klar sein bevor 
man meckert. Beim Keil sind diese Optionen sogar in der GUI anklickbar, 
wenn man auf gcc umschaltet. Dokumentationen zum gcc sind nun zur Genüge 
vorhanden.

So, Leute. Damit wir hier nicht im luftleeren Raum diskutieren mal ein 
paar Fakten:

Codesize für die BettyBase mit unterschiedlicher Optimierung
(alle nur übersetzt, nix tatsächlich ausprobiert)

Size der erzeugten BettyBasexxx.bin Dateien
Arm/Keil:
-O0         42144 Bytes
-O1         40020
-O2         38780
-O3         38784
-Otime      39796
-Ospace     38780

GCC (Yagarto 4.7.2)
-O0         48916
-O1         42612
-O2         42724
-O3         48448
-Ofast      48512
-Os         41380

Zieht man die konstanten 22900 Bytes für Grafik+Fonts ab,
dann gibt das für den reinen Code
Arm/Keil:
-O0         19244 Bytes
-O1         17120
-O2         15880
-O3         15884
-Otime      16896
-Ospace     15880

GCC (Yagarto 4.7.2)
-O0         26016
-O1         19712
-O2         19824
-O3         25548
-Ofast      25612
-Os         18480

und im Verhältnis:
-O0         1 : 1.35
-O1         1 : 1.15
-O2         1 : 1.25
-O3         1 : 1.61
-O(fast)    1 : 1.51
-O(size)    1 : 1.16

ist schon interessant, mal den direkten Vergleich an derselben Quelle zu 
haben. Gelle?

Wenn man sich also vor der Falle -O3 oder -Ofast hütet, dann sieht das 
Ganze schon ein bissel gelinder aus. Aber wie gesagt, nicht am lebenden 
objekt ausprobiert.

W.S.

Meiner ist länger!!!

Mit folgenden Änderungen im Makefile und dem gcc aus den gnu-arm-tools:

CPUFLAGS = -mcpu=arm7tdmi-s
OPTFLAGS = -Os
CFLAGS = -Wall -mthumb-interwork -msoft-float -DGCC -ggdb 
-Wa,-adhln=$*.lst

#hier
CFLAGS += -ffunction-sections -fdata-sections

INC = -I$(INCLUDEPATH) -I.
ASFLAGS = --gstabs -mthumb-interwork -mfpu=softfpa  -a=$*.lst
LDFLAGS = -Tlpc2220_Base.ld -Map BettyBase.map -eHard_Reset

#und hier
LDFLAGS += --gc-sections

LIBS = --start-group -lgcc -lc -lm --end-group
THUMBFLAGS = -mthumb



-O0     41860
-O1     36004
-O2     35956
-O3     40576
-Os     34924
-Ofast  40576

minus 22900=

-O0     18960 (0.98)
-O1     13104 (0.76)
-O2     13056 (0.82)
-O3     17676 (1.04)
-Os     12024 (0.75)
-Ofast  17676


Warum im Makefile 2 mal CFLAGS=xxx bei euch steht ist mir unklar. Die 
Zeile
   CFLAGS = -Wall -mthumb-interwork -msoft-float -ggdb
ist somit Müll, da später sie später wieder überschrieben wird.

Beseitigt das bitte mal, das trägt nur zur Verwirrung bei.

Noch ein Nachtrag. Nur zum Beispiel. Die Funktion:

1

const float FRound[5] = { 10.0, 100.0, 1000.0, 10000.0, 100000.0 };

2

3

float FF_round (float aValue, byte Digits)

4

{ float f;

5

  int n;

6

  n = Digits-1;

7

  if (n<0) n = 0;

8

  if (n>4) n = 4;

9

  f = floor((fabs(aValue) * FRound[n]) + 0.5);

10

  if (aValue<0) f = -f;

11

  f = f / FRound[n];

12

  return f;

13

}

aus conv.c wird nirgends im gesamten Code verwendet. Deshalb schmeißt 
der Compiler sie mit geeigneten Einstellungen auch raus. Ebenso die 
Konstanten FRound[5]. Bevor nicht geklärt ist ob solche Funktionen beim 
Keil drin sind oder nicht erübrigt sich jeglicher Vergleich. Außer man 
argumentiert sich selbst die Welt schön.

temp schrieb:
> Warum im Makefile 2 mal CFLAGS=xxx bei euch steht ist mir unklar.

Das kann ich dir erklären:

Ich selber arbeite mit Keil und habe den GCC hier ausschließlich per 
Batchfile benutzt, um die diversen -Oxx auszuprobieren. Ich selbst 
verwende also weder GCC noch Makefile und bin deshalb für diese Frage 
der falsche Ansprechpartner.

Aber Siegfried u.a. benutzen Make und da es offenbar nicht nur für mich, 
sondern auch für andere einen erheblichen nicht gedeckten Bedarf an 
Dokumentation gibt, haben die Makefile-Benutzer eben einfach einige alte 
Files (makefile, Linkersteuerfile, Eclipse-Files...) von anderen 
Projekten herüberkopiert und drin solange geändert, bis es lief.

So pflanzt sich das fort...

Wirklich gute Makefiles zu schreiben ist offenbar nicht einfach und sich 
zwischen den schier unendlichen Optionen des GCC durchzuwursteln 
ebenfalls. Da wundert es mich nicht, daß man schon seit Jahren von 
Insidern den Tip bekommt, einfach ein altes File herzunehmen und nur das 
Nötigste darin zu editieren.

btw: das hatte ich wirklich ernst gemeint:
"Ach ja, ich habe wirklich nix dagegen, wenn hier jemand aus der
GCC-Riege sich mal hinsetzt und für die Yagarto-Distribution eine
vernünftige Dokumentation schreibt, wo man nachlesen kann, wie dort
was aufgerufen und benutzt werden muß, damit man ein gutes Ergebnis vom
GCC bekommt."

W.S.

Johann L. schrieb:
> Was fehlt dir denn an der make-Dokumentation?

Garnichts. Ich benutze Make nicht, Dafür fehlt es mir an Doku für den 
arm-none-eabi-ld und zwar massiv. Guck dir mal meinen hier in diesem 
Forumsteil geposteten Versuch an, Hilfe bei den massiven Problemen zu 
bekommen, die ich mit diesem Linker hatte. Dieses Mistteil hat 
unaufgefordert zwischen zwei thumb Funktionen einen arm-stub gebaut, was 
natürlich voll in die Hose ging. Irgendwas dazu in der Yagarto-Doku 
(soweit man dieses ascii-File so nennen darf..) war nicht auffindbar. Im 
Prinzip bräuchte ich nen Parameter 
"-DoNotInsertArmStubsBetweenThumbCodes", da der Linker offenbar per 
default alles falsch macht, was man ihm nicht explizit verboten hat. Bin 
ich vom Keil, von IAR, von Fujitsu und von allen anderen C-Toolchains 
nicht gewohnt.

Johann L. schrieb:
> Einerseits wollen Anwender maximale Flexibilität und nach Möglichkeit
> Feinjustierungen vornehmen, andererseits wird darüber geklagt, daß es
> die entsprechenden Stellschräubchen und -hebel gibt.

Es sollte die Toolchain per Default bereits alle soweit richtig machen, 
daß zumindest lauffähiger Code dabei herauskommt. Meine - allerdings 
kurzen - Erfahrungen mit dem GCC sind jedoch gegenteilig. Ich  habe 
schlußendlich per ellenlangem Probieren und Reassemblieren eine Art 
Kochrezept hinbekommen, mit dem es funktioniert. Aber das finde ich 
intellektuell extrem unbefriedigend.

W.S.

Chris D. schrieb:
> Aber ich denke, als erstes Fazit kann man für einen Großteil der
> Anwender sagen: der GCC ist auf jeden Fall keine schlechte Wahl

... bezüglich der Kosten :-)

Bezüglich der Verwendung, hatte ich ähnliche Probleme wie W.S., auch 
wenn ich es nicht so drastisch formulieren würde.

@ W.S.


Unter
Beitrag "Re: kann arm-none-eabi-ld mit thumb umgehen?"

habe ich dir die Auflösung des Rätsels mit dem ld gepostet. Und es 
handelt sich nicht um einen Bug.

Hmm... erstmal danke für den Tip.

Aber..
wozu ist dann .thumb gut, wenn es nicht zu einem Objektcode führt, der 
in thumb assembliert ist und dann eben auch als thumb behandelt wird - 
und man stattdessen .thumb_func schreiben muß?

Ich könnte mir allenfalls eine Funktion vorstellen, die als ARM-code 
ausgewiesen werden soll, aber tatsächlich THUMB-code enthält - aber das 
wäre doch blanker Irrsinn und ich könnte mir dafür beim besten Willen 
keinen Anwendungsfall vorstellen. Also, aus welcher Logik kommt das her 
und wie muß man das begreifen?

Bei Keil/Arm ist das eindeutig: wo thumb steht, wird auch thumb draus 
gemacht und der Linker kann das eindeutig dem Objektfile entnehmen. Da 
gibt es gar keine Unklarheiten: thumb ist thumb und arm ist arm.

Uff, ich fühle mich beim GCC immer weniger zuhause. Es reicht da eben 
nicht zu sagen "fahr rechts rum!" sondern "fahr rechts rum, fahr aber 
nicht gradaus, fahr auch nicht links rum und fahr auch nicht zurück und 
bleib auch nicht stehen!"  stressig - zumindest für unsereiner.


W.S.

W.S. schrieb:
> Aber..
> wozu ist dann .thumb gut, wenn es nicht zu einem Objektcode führt, der
> in thumb assembliert ist und dann eben auch als thumb behandelt wird -
> und man stattdessen .thumb_func schreiben muß?


Eindeutig steht das auch in der Doku:

http://sourceware.org/binutils/docs/as/ARM-Directives.html


Ich will mir nicht zutrauen zu beurteilen ob es dafür sinnvolle 
Anwendungen gibt. Allerdings ist es wie bei vielen Sachen: kaum macht 
man's richtig, schon geht es. Ich verstehe nur nicht, warum du so 
penetrant Seitenhiebe verteilen musst. Der gcc ist für eine Unmenge vom 
Prozessoren verfügbar ohne dass man dafür einen 5stelligen Betrag auf 
den Tisch legen muss. Und die Ergebnisse sind zu mindestens ähnlich zu 
denen der kommerziellen Compiler.
Der Fallstrick mit den .thumb_func Schlüsselwort hat im übrigen nichts 
mit dem gcc zu tun. Der as und ld gehören zu den binutils.
Es steht dir ja frei den Keil zu benutzen.
Im übrigen habe ich im Leben noch keine einzige Zeile für einen Arm7 
geschrieben. Ich beschränke mich auf Cortex M3 und M0. Trotzdem hat die 
Suche im Web nach einer Lösung für dein Problem ca. eine Stunde 
gedauert. Vielleicht hättest du die investieren sollen bevor du in 
mehreren Threads  den gcc geprügelt hast.

temp schrieb:
> Eindeutig steht das auch in der Doku:

erstmal danke für den Link, aber wenn ich dort folgendes bei 
".thumb_func"
lese:

"This directive is not neccessary when generating EABI objects. On these 
targets the encoding is implicit when generating Thumb code."

dann ist mir jetzt sonnenklar, daß wir hier einen echten Bug entdeckt 
haben. Der Assembler wird mit

echo Assembliere BettyApiGcc
ARM-NONE-EABI-AS -mcpu=arm7tdmi-s --gstabs -mthumb-interwork 
-mfpu=softfpa -a=BettyApiGcc.lst -o BettyApiGcc.o BettyApiGcc.asm
if Errorlevel==1 goto ende

aufgerufen und in der Quelle steht eindeutig .thumb drin. Deswegen 
sollte die obige Direktive lt. Doku implizit aktiviert sein - aber sie 
ist es offenbar nicht, denn wir erhalten einen Objektcode, wo zwar thumb 
code drin ist, aber selbiger als arm code ausgewiesen wird, wodurch der 
Linker Mist baut.

So. Was machen wir jetzt?

- für die Lernbetty-User, die den GCC benutzen wollen, die zugehörigen 
Files verbessern und das WARUM dazu in die Doku schreiben?

- für die Lernbetty-User, die Make benutzen wollen, ein gutes Makefile 
kreieren und ebenfalls das WARUM dazu dokumentieren?

- entdeckte Bugs jemandem zur Kenntnis zu geben, der sich darum kümmern 
kann?


W.S.

W.S. schrieb:
> So. Was machen wir jetzt?
>
> - für die Lernbetty-User, die den GCC benutzen wollen, die zugehörigen
> Files verbessern und das WARUM dazu in die Doku schreiben?
>
> - für die Lernbetty-User, die Make benutzen wollen, ein gutes Makefile
> kreieren und ebenfalls das WARUM dazu dokumentieren?
>
> - entdeckte Bugs jemandem zur Kenntnis zu geben, der sich darum kümmern
> kann?

Ich würde sagen zu erst nimmmst du mal deine arrogante, 
besserwisserische Art etwas zurück. Bug hin oder her das interessiert 
mich nicht mal so sehr. Selbst bei deinem geliebten Keil stehen die 
.thumb_func Anweisungen in den Startupcodes die für den GCC mitgeliefert 
werden. Ebenso bei Crossworks und allen anderen die Assembler für den 
Startupcode verwenden. Die Leute von diesen Firmen sind auch nicht so 
überheblich und packen jedesmal wenn sie .thumb_func schreiben müssen 
ein paar gehässige Kommentare mit dazu. Wie die wohl darauf gekommen 
sind, dass das da hin gehört? Such mal hier im Forum, da findest du auch 
Treffer. Der einzige Bug den ich sehe ist der in der Doku. Obwohl ich 
die Unterschiede zwischen arm-eabi und arm-none-eabi noch nicht 
verstanden habe. Und hier gehts um den none-eabi. Vielleicht ist es ja 
nichtmal ein Bug.
Jedenfalls hast du die Doku ja vorher nicht mal gelesen. Also kann die 
dich nicht auf den Holzweg geführt haben.
Mach ganz einfach nicht so ein Federlesen drum, schreibs rein in deinen 
Code und gut ist.
Daß der as (oder ld) irgendwann mal anders geht wirst du wohl nicht 
erleben. Vielleicht kommt mal noch ein Kommandozeilenschalter dazu. Es 
wäre ja extrem gefährlich wenn der as bzw. ld von einer Version zur 
nächsten völlig anderen Code generiert.

guck mal bei rowley crossworks. Da gibt es eine billige
version für privatuser. die benutze ich auch und bin zufrieden damit...

http://www.leo.org/information/freizeit/fun/Vatical.html

:-)

temp schrieb:
> Ich würde sagen zu erst nimmmst du mal deine arrogante,
> besserwisserische Art etwas zurück. Bug hin oder her das interessiert
> mich nicht mal so sehr. Selbst bei deinem geliebten Keil stehen..


Ach nö, das ist nicht die Ebene, auf der ich hier weiter diskutieren 
will. Was fällt dir eigentlich ein, hier solche Äußerungen loszulassen??

W.S.

W.S. schrieb:
> temp schrieb:
>> Ich würde sagen zu erst nimmmst du mal deine arrogante,
>> besserwisserische Art etwas zurück. Bug hin oder her das interessiert
>> mich nicht mal so sehr. Selbst bei deinem geliebten Keil stehen..
>
>
> Ach nö, das ist nicht die Ebene, auf der ich hier weiter diskutieren
> will. Was fällt dir eigentlich ein, hier solche Äußerungen loszulassen??
>
> W.S.

Wo er recht hat...

Und das ist nicht der einzige Thread, wo Du so rüberkommst.

Hach, wäre das schön, wenn du dich einfach verziehen würdest.

Wird nur wohl nicht geschehen. :-(

Was ich hier heraushöre - ist das die 250 Euro oder wie viel auch immer 
für den Keil gut angelegt sind wenn man keine Zeit oder Lust hat sich 
die umfangreiche GCC Doku reinzuziehen. Ja, und dann noch ewig 
herumprobieren muss bis man ein akzeptables Ergebnis gefunden hat. Nee, 
ich spare schon mal und investiere die Zeit lieber in was anderes. Jedem 
das seine.

au Sch... - ich habe mir jetzt erst die Preise richtig angesehen.

> Was bedeutet "in der Spitze"?

Die "beste" Optimierung: 
Beitrag "Re: ARM C-Compiler"

> Höchst unwahrscheinlich.

Warum? Wenn die Ergebnisse von oben stimmten, dann eher höchst 
wahrscheinlich. Nicht vergessen: alle haben das Drachenbuch im Schrank.

Hallo,
zuerst mal Danke für die vielen Antworten, ihr haut Euch die Sachen ja 
ganz schön um die Ohren. Zuerst vorweg ich bin Amateur und betreibe den 
"Sport" als reines Privatvergnügen.
Mir geht es eher darum bequem einzusteigen als das letzte Quäntchen 
Performance auszuquetschen. Was mir an Mikroe noch gefallen hat ist das 
Board das ich eingangs erwähnte.
Es wird zu 90% das abdecken was ich noch vorhabe. Es geht mir 
haupsächlich um eine komfortable Bedienoberfläche und Visualisierung mit 
Speichermöglichkeiten. (SD-Card). Ich hatte dafür auch schon mit Arduino 
geliebäugelt aber der Aufbau mit dem Umfang wie Mikroe es bietet besteht 
aus 3 Platinen und schaut ganz schön gebastelt aus. Der 8051 wird auch 
noch einige Zeit zum einsatz kommen.

@Pieter 250.- € ist zwar nicht nachgeschmissen aber bevor ich unzählige 
Abende damit verbringe bis der Compiler läuft und ich die ersten LED's 
zum leichten bringe investiere ich das Geld.
@Jörg ich werde mal die Foren durchforsten

Gruß Jürgen

Wenn du von der 8x51 Architektur kommst dann ist der Übergang zu ARM 
durchaus ein paar Tests wert. Es gibt ARM Boards für rund 20 Euro oder 
für das was du dir vorgenommen hast würde auch das folgende Board 
passen...

http://www.steitec.net/ARM-Boards/ARM-LPC1768-Cortex-M3-LCD-Board.html

Die Frage nach dem Compiler stellt sich beim Testen noch nicht allzu 
sehr aber für Hobbyzwecke fällt der Keil dann heraus. Wurde schon 
genannt...

http://www.coocox.org/Index.html

Brendes Emulator... lange her :-)

>> Emulator eigentlich recht komfortabel aber ich bin jetzt doch auf seine
>> (8051) Grenzen gestoßen. (Touch Screen SD Card etc.)

Bin mir sicher das man ein solches Vorhaben durchaus mit einem 8x51 
Derivat durchziehen kann, das bringt moderne 8x51 Typen noch lange nicht 
an deren Grenze.

Hat mich doch jetzt auch mal interessiert :-) aus dem gleichen Stall...

http://www.mikroe.com/big8051/

@ Bernd,
mag schon sein das das ich mit einem leistungsfähigeren 8051 Derivat das 
auch hinbekommen kann. Aber ich müsste dann das gleiche Geld ausgeben. 
Mein Keil Compiler ist schon sehr betagt und noch mit einem Dongle an 
der Paralellschnittstelle, auf einem neuen Rechner läuft das nicht mehr.
Ich habe bisher fast ausschließlich den AT89C51ED2 verwendet.Die 2K RAM 
sind nun auch nicht gerade üppig.Ich habe mir damals dafür extra ein 
eigenes POD gemacht damit ich die Softhook Restriktionen umgehen konnte. 
Ich bin auch etwas versessen auf das "mikromedia for STM32 M4 
(Mikroelektronika)" Bord weil es wunderbar in eine doppelte 
Unterputzdose passt. Es also an der Zeit mal was neues zu probieren.

Ich wollte es dir auch nicht ausreden :-) War nur als Hinweis gemeint da 
es für dich "nur" Hobby ist und die ARM Architektur doch ziemlich weit 
weg ist von deinem 8051. Die Silabs Chips hingegen bieten einem die 
gleichen Debug Möglichkeiten wie seiner Zeit der Biceps 51 von Brendes, 
Emulator sozusagen On Chip. Software gibts für den 8x51 Kern Haufenweise 
und kostenlos dazu, den Keil in Ehren aber den verwende ich schon ewig 
nicht mehr für 51er.

Wie dem auch sei, ARM ist in jedem Fall interessant und sicherlich der 
richtige Schritt, für Profis führt da eh kein Weg vorbei und schließlich 
ist der Einstieg nicht allzu schwer. Dennoch macht man häufig den Fehler 
eine neue Architektur zu verwenden obwohl ein 8Bit MC noch allemal gut 
genug ist.

Was mich bei deiner Auswahl ein wenig stört, ist die Tatsache keinen 
Vollzugriff auf die Sourcen zu haben. Gerade im ARM Segment gibt es 
unglaublich Viele Boards und freie Software. Seis drum, Viel Spaß mit 
dem Teil und vielleicht schreibst du dann mal deine Erfahrungen damit 
zusammen und postest dies hier.

@Bernd
was für einen Compiler verwendest Du für den 8051?

Für ASM http://plit.de/asem-51/download.htm

In C http://sdcc.sourceforge.net/

mit der Entwicklungsumgebung von Silabs.

http://www.silabs.com/Support%20Documents/TechnicalDocs/an198.pdf

@Bernd
DANKE!