CARM gegen RealView

Martin Gast #409227
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Martin Gast #409228
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Martin Thomas Gast #409229
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt. Bitte hier nur auf die ursprüngliche Frage antworten, für neue Fragen einen neuen Beitrag erstellen.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Dein Name und deine E-Mail-Adresse

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.