Forum: Compiler & IDEs Hitex Cortino + CMSIS : selected processor does not support `strex r1,r3,[r2]'


von Gerhard (Gast)


Lesenswert?

Hallo,

ich versuche die Hitex Cortino Umgebung mit der StdPeriph_Lib zum laufen 
zu bekommen. Allerdings bekomme ich bei der core_cm3.c folgenden Fehler:

Error: selected processor does not support `strex r1,r3,[r2]'

Ich habe zwar was gefunden wo bei strex "=r" durch "=&r" ausgetauscht 
werden soll, aber der Fehler bleibt. Wie bekomme ich das zum laufen?
Als Mikrocontroller verwende ich einen STM32F103RB.

Danke
Gerhard

von (prx) A. K. (prx)


Lesenswert?

Der Compiler ist auf den Cortex-M3 eingestellt? Der hat diesen Befehl 
durchaus, nur der Cortex-M0 hat ihn nicht.

Codesourcery (4.3.3) produziert diesen Fehler nur, wenn nicht korrekt 
auf -mthumb -mcpu=cortex-m3 eingestellt.

von Gerhard (Gast)


Lesenswert?

Hallo,

die Compiler Einstellungen sind:

-c -gdwarf-2 -MD -O0 -trigraphs -mcpu=cortex-m3 -mthumb  -Wall 
-fsigned-char  -mlittle-endian -mfpu=vfp -xc  -mno-thumb-interwork 
-mno-tpcs-frame

Version vom arm-hitex-elf-gcc ist ebenfalls 4.3.3.

von (prx) A. K. (prx)


Angehängte Dateien:

Lesenswert?

Codesourcery akzeptiert den angehängten Code mit ebendiesen Optionen. 
Also wirst du ggf. mal Hitex fragen müssen, wie sie das geschafft haben.

von (prx) A. K. (prx)


Lesenswert?

Kurzfristig besteht Abhilfe, indem du diese Funktionen in core_cm3.c 
deaktivierst, denn die werden ohnehin nirgends verwendet.

von Gerhard (Gast)


Lesenswert?

Der Code von dir bringt den gleichen Fehler. Scheint wohl wirklich an 
der Hitex Tool Chain zu liegen.

von J. V. (janvi)


Lesenswert?

Nebenbei eine Anmerkung was aber wahrscheinlich nicht dein Problem mit 
fehlerhafter CMSIS löst: -mfpu=vfp setzt Code für Hardware Vector 
Floating Point Coprozessor ab. Den gibt es im Cortex M3 nicht. Warum 
Hitex sowas ausliefert bleibt mir auch ein Rätsel, bzw. wurde mir in der 
zweiten Mailanfrage nahegelegt einen Consulting Vertrag zu 
unterzeichnen. Ansonsten läuft das Teil bei mir so halbwegs, die cm3 
inline Assembly Zeilen habe ich aber auch nicht in Benutzung.

von Gerhard (Gast)


Lesenswert?

ok, danke für den Hinweis.

Was heißt halbwegs? Soll ich nun die CMSIS nehmen und des STREX 
entfernen oder die alte FWLib 2.03?

Danke

von (prx) A. K. (prx)


Lesenswert?

#if 0
ldrex/strex-Kram
#endif

und gut ist. Wird garantiert niemand vermissen.

von J. V. (janvi)


Lesenswert?

>Was heißt halbwegs?

Namentlich der CMSIS Low Density Startup hat heftige Fehler.

>Soll ich nun die CMSIS nehmen und des STREX
>entfernen

Ich habe die gesamte Datei core_cm3.c entfernt und alles andere von der 
CMSIS tut dabei noch immer wie gewünscht. Normalerweise wird nur 
core_cm3.h (header) für die CPU Register benötigt und um mit den neu 
definierten CMSIS Typen kompatibel zu sein. Wenn ich der Meinung bin, 
dass ich Assembler brauche, schreibe ich das gleich in ein .s File rein 
und probiere nicht den GCC über Makros dazu zu bringen sowas abzusetzen. 
Schliesslich probiert man ja auch nicht, im Hex Editor einen Brief zu 
schreiben. Wahrscheinlich kommt die Datei halt von dem Wunschdenken 
einiger Verkäufer, daß man beim Cortex keinen Assembler mehr braucht. 
Falls doch, kann man es ja trotzdem erst mal in C probieren.

von (prx) A. K. (prx)


Lesenswert?

J. V. schrieb:

> Meinung bin, dass ich Assembler brauche, schreibe ich das gleich in ein
> .s File rein und probiere nicht den GCC über Makros dazu zu bringen
> sowas abzusetzen.

Da geht dir allerdings massiv Optimierungspotential verloren. Die 
Diskussion mit Random um das in CMSIS bisher fehlende Inling hast du ja 
m.W. mitbekommen.

Die aussergewöhnlichen Möglichkeiten der Assembler-Einbettung in GCC 
zeigen sich nämlich erst dann. Denn nur dann wird beispielsweise die 
Aus/Einschaltung der Interrupts zu einem einzigen Befehl im Ablauf des 
aufrufenden Codes, ohne jeden Overhead.

Ohne Inlining wird ein Funktionsaufruf draus, der erstens etliche Takte 
dauert und zweitens den Compiler zu weniger effizienter Registernutzung 
zwingt. Grad bei solchen Operationen (auch BASEPRI&Co) kann das 
erheblichen Einfluss auf die maximale Sperrzeit von Interrupts und damit 
deren Latenzzeit haben.

Mir ist kein anderer Compiler bekannt, der Assembler-Code derart 
effizent in C-Code einbetten kann wie GCC.

von J. V. (janvi)


Lesenswert?

>Also wirst du ggf. mal Hitex fragen müssen, wie sie das geschafft haben.

@Gerhard: Manfred punkt Schnuerer at hitex hat die DW 164. Wäre 
interessant wenn du da was rauskriegt - ich habs dort schon ziemlich 
verzockt.

strexh und strexb und auch ldrex wird assembliert, strex komischerweise 
nicht. Auch nicht mit pseudo ops .cortex-m3 oder .thumb oder .code[16] 
davor. Mit und ohne Condition und mit und ohne Offset probiert.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.