CARM gegen RealView

[Martin (Gast)]

Hallo Leute!

Wer von euch benutzt den Keil-Compiler für ARM-Prozessoren.
Leider hat dort der RealView-Compiler Einzug gehalten.

Der CARM-Compiler ist jener Compiler, der von Keil entwickelt wurde. An
diesem Compiler sieht man, dass sich die Leute von Keil Mühe gegen
haben, es dem Benutzer einfach zu machen.
Ich möchte nur ein paar Punkte ansprechen, die auf einfachste und
unkomplizierte Weise zu bewerkstelligen sind z.B:
IRQs-Handhabung
SWI-Handhabung
Umschalten zwischen ARM- und Thumb-Mode auch für einzelne Funktionen
und das Beste
Man kann jede Variable händisch in jeden beliebigen Speicherbereich
packen.

Leider wird dieser Compiler laut Keil leider nicht mehr
weiterentwickelt.

Aus diesem Grund wäre es nicht schlecht, die alten Projekte auf den
RealView-Compiler umzustellen. Kann mir jemand einen triftigen Grund
nennen es nicht tun zu müssen? Ganz toll fand ich beim CARM-Compiler,
dass man Variablen oder Felder an ganz bestimmte Speicherpositionen
stellen konnte:
uint8_t f_ramfeld[f_byteanzahl] __at f_adresse;

In diesem Fall kommen die ganzen Vorteile der Neumannarchitektur zum
Vorschein.

So habe ich ein Programm entwickelt, wo z.B. einzelne große Felder auf
verschiedene Speicher verteilt waren.

Ich habe zwar gehört, dass dies beim Realview ansatzweise funktionieren
soll, aber nicht so gut wie beim CARM. Beim Realview kann, was ich so
gehört habe, keine einzelnen Variablen in einen bestimmten
Speicherbereich verschieben, sondern man kann dies nur Modulweise.

Was haltet ihr davon?
Verwendet ihr eher RealView oder CARM?
Was liegt euch mehr?

Lasst uns diskutieren.

Tschüss
Martin

[Martin (Gast)]

Hallo Leute!

Ich habe mir vorgenommen die Projekte auf den RV-Compiler umzustellen.
Leider gibt es da noch eine kleine Schwierigkeit.

Beim LPC2138 hat man die Möglichkeit das Flash vor dem Auslesen zu
schützen. Dies gelingt dadurch, indem man an die Speicherstelle 0x1FC
den Wert 0x87654321 programmiert. Diese Speicherstelle befindet ist im
Flash.

Mit dem CARM funktioniert das folgendermaßen:
extern uint32_t const f_protect __at 0x1FC = 0x87654321;
Nach dem Flashen ist der Prozessor lesegeschützt.

Es gibt leider anscheinend keinen offiziellen Weg diese Speicherstelle
mit dem RV-Compiler beschreiben zu können.
In die Ram-Bänke habe ich folgendes eingetragen:
     Start, Size
IROM1 0x0   0x80000
IROM2 0x1FC 0x4

Folgende Fehlermeldung erscheint:
Range IROM2 overlaps range IROM1.

Hei, wie soll ich mit diesem Kinderspielzeug jemals vernünftig arbeiten
können? Aber schimpfen hilft nichts.
Hat jemand von euch eine Lösung parat? Das wäre echt großartig.

Danke nochmal Leute.

Tschüss
Martin

[Martin Thomas (Gast)]

Die Dokumentation schon mal durchgelesen (vor allem die
Linker-Dokumentation z.B. den Abschnitt zu "scatter-loading")?
Prinzip lt. Dokumentation: Konstante in eine Section ablegen und im
scatter-file Addresse der Section angeben. Ich kenne die Realview-Tools
selbst nicht wirklich gut, Vorgehensweise ist aber vergleichbar mit der
bei der GNU-Toolchain. Ansonsten: wenn man eine "Lösung" fuer ein
Problem von jemand erwartet, der sich mit einem bestimmten Produkt gut
auskennt, das Produkt vielleicht nach langer und muehvoller Evaluierung
ausgewaehlt hatund sich in vielen Stunden eingearbeitet hat, ist es
keine wirklich gute Idee das Produkt als "Kinderspielzeug" zu
bezeichnen.

[Dominic R. (dominic)]

Habe RealView nie benutzt, aber wie wär's mit
IROM1 0x0 0x1FC
CRP 0x1FC 4
IROM2 0x200 0x7E000

Die Fehlermeldung scheint doch recht eindeutig zu sein.

Gruss,

Dominic