Forum: Compiler & IDEs Frage zu Assemblerbefehlen für Cortex-M3


von 900ss (900ss)


Lesenswert?

Hallo,

ich versuche gerade ein Cortex-M3 Assemblermodul für IAR geschrieben auf 
den GCC umzusetzen. Leider gelingt es mir nicht.
Es gibt Befehle, die der GCC nicht haben will. Habe dann in der 
IAR-Doku, der GCC-AS-Doku nachgelesen, finde dort aber auch die Mnemonic 
nicht :-(
Bei ARM gibt es auch nichts. Außer für "SUBS".

Z.B. die beiden unten stehenden Befehle versteht GCC nicht und ich finde 
auch keinen Ersatz, da ich der IAR und auch ARM Doku die Mnemonics in 
der Art nicht finde. STM z.B. nur als STMxx, xx steht für folgende 
Möglichkeiten:
IA Increment after.
IB Increment before.
DA Decrement after.
DB Decrement before.
1
SUBS    R0, R0, #0x20     // Save remaining regs r4-11 on process stack
2
STM     R0, {R4-R11}

Und SUBS ist meines Wissens aus dem ARM Befehlssatz, die der CM3 nicht 
kann. Er kann wohl 32-bit Befehle, aber nicht den, wenn ich richtig 
informiert bin. Trotzdem ist das Modul für CM3 geliefert worden.

Mein Compileraufruf:
1
arm-none-eabi-gcc -x assembler-with-cpp -Wall -c -fmessage-length=0 -mcpu=cortex-m3 -mthumb -mthumb-interwork -g3 -gdwarf-2 os_cpu_a.asm

Wenn ich genau wüßte, was die beiden Befehle oben machen, dann würde ich 
das ja umsetzen können, aber so? Mir ist nicht genau klar was denn STM 
macht. Ich denke er sichert R4-R11 ab [R0] im Speicher, aber Adressen 
auf- oder absteigend?

Außerdem sollte es für CM3 lauffähig sein. Hat einer einen Tip wie ich 
das umsetzen kann? Ich mach bestimmt nur einen Denkfehler oder habe 
etwas übersehen.

Danke.
Gruß 900ss

von 900ss (900ss)


Lesenswert?

Kleiner Nachtrag:
Habe inzwischen noch herausbekommen, dass "SUBS" doch wohl vom CM3 
unterstützt wird. Aber wie sag ich es dem Assembler (GCC)?
Was ihm bei STM fehlt ist mir immer noch ein Rätsel. Die Fehlermeldungen 
helfen mir leider nicht.
1
SUBS    R0, R0, #0x20     // Save remaining regs r4-11 on process stack
2
STM     R0, {R4-R11}

Auf erste Zeile lautet die Fehlermeldung:
os_cpu_a.asm:203: Error: instruction not supported in Thumb16 mode -- 
`subs R0,R0,#0x20'

Auf zweite Zeile lautet die Fehlermeldung:
os_cpu_a.asm:205: Error: lo register required -- `stm R0,{R4-R11}'

Ich habe das Gefühl, ich muß ihm irgendwie sagen, dass er Thumb2 
Instruktionen benutzen soll. Aber wie sag ich es dem GCC?
grummel

von (prx) A. K. (prx)


Lesenswert?

ARM hatte auf dem Weg von Thumb zu Thumb2 irgendwann die Mnemotechnik 
etwas verändert, d.h. Befehle umbennnt. Vielleicht hat das damit zu tun.

von 900ss (900ss)


Lesenswert?

Ich habe auf den Support-Seiten (FAQ) zu Codesourcery folgendes 
gefunden:
1
Generating Thumb-2 Instructions
2
3
Question
4
How do I get the compiler to generate Thumb-2 instructions?
5
6
Answer
7
Use the options -march=armv6t2 -mthumb. The compiler will then assume that
8
your target hardware has Thumb-2 support and will generate appropriate code.

Wenn ich jetzt statt "-mcpu=cortex-m3" die Option "-march=armv6t2" 
nutze, dann kommen 2 Fehlermeldungen und dann stürzt der von GCC 
aufgerufene AS ab. :-( Nun, ich werde herausfinden müssen, was die 
Instruktionen machen und dann diese durch Thumb-Instruktionen ersetzen.

Weiß noch jemand etwas dazu? Vielleicht werden ich noch auf den 
ARM-Seiten graben (danke A.K.).

900ss

PS. Das hat man jetzt davon, dass man so neumodischen Plunder benutzt. 
Wäre ich doch beim Z80 oder mit gutem Willen beim AVR gebleiben ;-)

von Martin T. (mthomas) (Moderator) Benutzerseite


Lesenswert?

1
.syntax unified
 schon ausprobiert?

von 900ss (900ss)


Lesenswert?

Martin Thomas schrieb:
>
1
> .syntax unified
2
>
> schon ausprobiert?

Das war ein guter Hinweis. Wieso habe ich es trotz wirklich
intensiven Bemühens bei G nicht gefunden?
Und auch in der AS-Doku findet man nichts dazu.

Also jetzt wird das Modul zwar ohne Fehlermeldungen übersetzt, aber ob 
auch der richtige Code dabei rauskommt? Nun ,das werde ich sehen, wenn 
das alles fertig ist. Dieses war nur ein Modul aus einem Port eines RTOS 
(uc/os-2) für den CM3.

Bin mal neugierig, ob das später läuft.

Danke dir für diesen Tip Thomas.

Gruß
900ss

von Bunix (Gast)


Lesenswert?

Das ist ja super. Du hast praktisch genau das gemacht, was ich gerade 
versuche. Allerdings mit dem Cortex M1 Port von uc/os-ii. Das Problem 
ist das es nur Versionen für den IAR und Keil Compiler gibt, ich aber 
GCC verwenden möchte.
Kannst du mir dein umgeschriebenes Assemblerfile mal zukommen lassen? 
Ich habe nämlich etwas Probleme beim manuellen konvertieren.

Vorallem verstehe ich eines nicht.

IAR Code:

;********************************************
;               CODE GENERATION DIRECTIVES
;********************************************

    RSEG CODE:CODE:NOROOT(2)




Keil (RealView) Code:
;********************************************
;               CODE GENERATION DIRECTIVES
;********************************************

    AREA |.text|, CODE, READONLY, ALIGN=2
  THUMB
  REQUIRE8
  PRESERVE8





Wie muss das ganze für den GNU aussehen? Ich bin soweit gekommen

/***********************************************
*                CODE GENERATIOn DIECTIVES
***********************************************/

.text
.thumb
.align 2


Das kann aber noch nicht alles sein. Denn ich bekomme Compilerfehler 
dass die Werte meiner Offsets zu groß sind.
"Error: invalid offset, value too big (0x000000FE)"



Wäre total super wenn jemand ne Idee hat, und wenn 900ss mir seinen 
konvertierten M3 Code zukommen lassen könnte! :D

von 900ss (900ss)


Lesenswert?

Ja der Kernel läuft inzwischen.
Teile mir per PN deine Email mit. Dann kann ich dir das heute abend 
schicken.
Gruss 900ss

von Gast (Gast)


Lesenswert?

Segger hat doch schon längst embOS ARM und embOS CM3 auf GNU portiert, 
ladet euch doch einfach die entsprechenden Trial Versionen runter und 
schaut da rein ;-).

von Qduda 1. (Firma: student) (qduda)


Lesenswert?

Danke für den Hinweis ich werde da mal rein schauen. 900ss nochmal danke 
für den Code. Ich habe meine Cortex M1 Datei jetzt damit anpassen können 
(keine Syntax Fehler mehr). Leider gibt's Probleme beim Linken. Der Gnu 
C Linker bringt nicht mal ne Fehlermeldung sondern bleibt einfach bei 
der aus dem Assembler Code generierten .o Datei hängen. Sowas hatte ich 
noch nie, eigentlich sollte der sich beschweren das irgendwas nicht 
stimmt. :I

von 900ss (Gast)


Lesenswert?

Solch einen Absturz hatte ich mal beim Assembler. Ich hatte eine gültige 
Option angegeben, aber die hat ihn zum Absturz gebracht. Ich habe die 
freie GNU Toolchain von CodeSourcery benutzt. Die nutze ich immer noch.
Läuft aber jetzt perfekt. Damals war das noch die vorletzte Version, 
jetzt benutze ich die aktuelle. Ob die auch noch abstürzt, habe ich 
nicht ausprobiert.

Gruß 900ss

von 900ss (Gast)


Lesenswert?

@Gast

 embOS hat ja nichts mit uc/OS2 zu tun. Also was soll man sich dort 
abschreiben? Außerdem bekommt man in der Trial-Version meines Wissens 
keine Source-Code, sonder eine Bibliothek, mit der man 3 Tasks zum 
Testen laufen lassen kann. Also könnte man nicht mal versuchen, aus dem 
Source zu lesen.

Gruß 900ss

von Gast (Gast)


Lesenswert?

Es ging doch darum zu sehen wie der Assembler Syntax aussieht, also 
welche Befehle man benutzen kann. Der Teil für den Taskwechsel, also das 
eigentliche Retten der Register wird bei embOS nicht so anders sein ;-).
Von daher einfach mal durchs Disassembly steppen und schauen was da so 
benutzt wird.
Ausserdem kannst du makefile und Linkfile von da benutzen.

Klar embOS als Source bekommst du in der Trialversion nicht direkt, aber 
ein Teil ist schon im Source dabei (Initialisierung der HW zum 
Beispiel).

Nene, das mit den 3 Tasks wird immer falsch verstanden. Du kannst mit 
der Trialversion soviele Tasks anlegen wie du willst. Die einzige 
Einschränkung ist, wenn du mehr als 3 Tasks benutzt, läuft embOS "nur" 
15 Minuten nach dem Reset. Aber das reicht ja völlig zum rumspielen und 
evaluieren.

von Gast (Gast)


Lesenswert?

Nachtrag:

Ein guter Trick, wenn man sich nicht sicher ist, wie der Assembler 
Syntax denn aussieht, ist sie die Funktion in C zu schreiben und dann 
einfach mal ins Listing zu schauen ;-).

von Gast (Gast)


Lesenswert?

Nachtrag, Nachtrag:

Die GCC Optionen für den Cortex M3 sind:
-mcpu=cortex-m3 -mlittle-endian -c -fomit-frame-pointer -Wall 
-Wstrict-prototypes -fverbose-asm -mthumb -O0

Im Assemblerteil sollte sowas wie
        .syntax unified
        .thumb
        .thumb_func
        .balign 4
        .text

stehen.

Falls ihr noch fragen habt beim CortexM3/GCC kann ich euch weiterhelfen.

Wobei ich aber immer noch nicht verstehe wieso man anfängt ein 
veraltetes uC/OS-II zu portieren, wenn es embOS_GNU_CM3 fertig von 
Segger gibt ;-).

von 900ss (Gast)


Lesenswert?

>veraltetes uC/OS-II
Wieso veraltet?

>wenn es embOS_GNU_CM3 fertig von Segger gibt ;-).

Ich nutze das privat. Also soll es möglichst wenig kosten.
Die Preise die Segger aufruft, sind vielleicht gerechtfertigt,
aber für meinen privaten Bedarf einfach zu hoch. Ich bin durchaus
auch bereit, etwas für mein Hobby zu investieren, habe z.B.
den J-Link (none commercial use) von Seggger. Der hat dann
einen Preis, wo ich mit einverstanden war.

Also ist das uc/OS eine Option. Was daran schlechter sein soll, als
bei embOS weiß ich nicht. Vielleicht du? Aber bitte konkrete
Vorteile, nicht "nice to have". Und auch überprüfbare Vorteile.
Wenn z.B. eine unbegrenzbare Anzahl Task ein Vorteil sein soll,
dann sehe ich das nicht, solange ich eine, sagen wir zweistellige
Anzahl Tasks nutzen kann. Also viel hilft viel, ist kein Argument.

von Qduda 1. (Firma: student) (qduda)


Lesenswert?

@900ss:
Ich benutzte auch die code sourcery toolchain. Gefällt mir wirklich gut. 
Ich arbeite noch nicht solange damit. Als IDE verwende ich Eclipse, 
welches dann wiederum die Code Sourcery Toolchain verwendet. Habe mir 
zwar was selber gebastelt, aber dann gesehen das "Actel" eine freie IDE 
hat (SoftConsole), die eigentlich genau meine Tools unter einen Hut 
bringt, mit einem Installer. Ich glaub das Paket werde ich auch mal noch 
irgendwann ausprobieren.

Das Linker Problem hab ich noch nicht behoben, ist schwierig zu 
diagnostizieren wenn man nicht mal nen wirklichen Fehler bekommt. Der 
startet den Linker und bleibt dann stehen. Andere Projekte kann ich 
wunderbar linken lassen.

@Gast:
Es geht mir darumd as ich einen Cortex M1 habe (keinen M3). Für den M1 
ist meines wissens nach nur ein Port von µC/OS (micrium) verfügbar. Von 
EmbOS nicht. Ich wollte jetzt zunächst keinen Port umschreiben (dafür 
sollte man tiefer in der Materie drin sein.) sondern einen fertigen 
verwenden. Es lag für mich nahe den Cortex M1 Port von µC/OS-II zu 
verwenden. Leider stellt Micrium nur Ports für die kommerziellen IDEs 
von Keil und für IAR zur Verfügung. Ich möchte aber freie Tools 
verwenden. GCC ist in meinen Augen die beste freie Compiler Suite. Also 
habe ich mich daran gemacht den Cortex M1 (keil compiler) Port für den 
GCC umzuschreiben. Dabei hatte ich Probleme, und bin hier auf diesen 
Thread gestoßen. 900ss hat saubere Arbeit geleistet mit seinem Cortex-M3 
GCC Port. Ich habe mir erhofft daran etwas ableiten zu können. Und das 
hat auch soweit super geklappt.
Probleme hab ich jetzt mit dem Linker.
embOS werde ich mir auch noch anschauen, aber erst wenn ich mal das 
µC/OS zum laufen gebracht habe.

Meine GCC Optionen sind wie folgt gesetzt:
-mthumb -mcpu=cortex-m1 -O0 -g3 -Wall -c -fmessage-length=0

Im assembler part schaut das so aus:
.section .text
.thumb_func
.syntax unified


den align part hab ich rausgeschmießen, da der bei den 
Compilereinstellungen die richtigen Werte via default setzt. zB "align 
2" wird angenommen wenn es nicht explizit definiert wird.

Ich gehe mal davon aus, dass ich irgend eine Option falsch gesetzt habe, 
und deshalb nicht sauber gelinked werden kann. Aber wie geh ich am 
besten vor? Wie diagnostiziere ich sowas wenn ich keine Fehlermeldung 
vom Linker bekomem? :O

von 900ss (Gast)


Lesenswert?

@Tobias Qduda
>Ich gehe mal davon aus, dass ich irgend eine Option falsch gesetzt habe,
>und deshalb nicht sauber gelinked werden kann. Aber wie geh ich am
>besten vor? Wie diagnostiziere ich sowas wenn ich keine Fehlermeldung
>vom Linker bekomem? :O

Schau mal hier rein:
http://www.codesourcery.com/archives/arm-gnu/maillist.html

Und danke für die Blumen ;-)

Gruß 900ss

von Gast (Gast)


Lesenswert?

>veraltetes uC/OS-II
Wieso veraltet?
Aber bitte konkrete Vorteile, nicht "nice to have".


Nunja, schau dir doch einfach mal den Flyer von uC/OS-III an, die 
Features, die dort drin stehen hat embOS schon seit mindestens 5 Jahren 
drin und bestimmte Features dies es bei embOS seit einiger Zeit gibt, 
sind jetzt auch im uC/OS-III, was für ein Zufall ;-). Ich halte einfach 
embOS für technisch besser und nenne jetzt einfach mal drei Punkte, die 
für mich sowohl privat als auch beruflich interessant wären:
1. embOS ist deutlich schneller, ich weiß jetzt nicht wie es beim 
CortexM3 ist aber bei einem ARM7 ist embOS bei einem Taskwechsel mehr! 
als dopppelt so schnell wie uC/OS-II. Wer es nachvollziehen möchte, 
sowohl von Segger als auch von Micrium Trialversion runterladen und 
Testprogramm von Segger laufen lassen (diese Testapplikation kann man 
dann auch einfach auf uC/OS-II anpassen).
2. Wenn ich ein OS benutzen möchte, dann will ich nicht erst irgendwas 
portieren und zusammenbasteln müssen. Ich will eine passende Trial für 
mein Evalboard runterladen, auspacken und das muss sofort funktionieren. 
Da die embOS Ports alle von Segger selbst kommen, laufen die Projekte 
alle ohne Probleme. Ich habe da schon ne Menge runtergeladen und das 
lief immer auf Anhieb ohne das ich eine Projekteinstellung oder eine 
Zeile Code verändern musste. Und falls doch mal was sein sollte kommen 
wir zu Punkt drei.
3. Bei Segger hast du deutschen Support, der mehr als bemüht ist. Ich 
hab mit den Jungs schon auf ner Messe geredet und da merkt man erstens, 
das die echt nen Plan von der Technik haben und sehr umgänglich sind, 
also gerne weiterhelfen. D.h. du bekommst direkt Support von demjenigen, 
der es auch programmiert hat...versuch das mal bei Micrium.


Ich muss natürlich zugeben, das ich auch keine 2.5KEuro für Privat 
ausgeben wollen würde, da gebe ich dir völlig recht. Das ist bei Micrium 
einfacher. Aber wenn dir so eine J-Link non commercial Lizenz gefällt, 
wieso rufst du nicht mal dort an und fragst, ob du sowas auch für embOS 
bekommen kannst? Ich denke da kann man immer was machen.

Sorry, wenn ich jetzt zuviel Werbung für embOS machen, aber das machen 
die ja leider selber zu wenig, da ist Micrium echt besser (die schaffen 
es ja sogar ein Produkt Manual als tolles uC/OS-III Buch für 199$ zu 
verkaufen lol).



@Tobias Qduda
"Für den M1 ist meines wissens nach nur ein Port von µC/OS (micrium) 
verfügbar. Von EmbOS nicht."

Auch hier nochmal: Wo ist das Problem, mal bei Segger anzurufen oder zu 
mailen, ob die schon was haben oder es sogar eben machen würden? Das ist 
doch weniger Aufwand als selber anzufangen ;-).

Ich denke Segger wird auch Privatleuten wie uns weiterhelfen, so ein 
embOS CortexM1 werden die ja trotzdem verkaufen.

Ausserdem unterstützt Segger ganz stark freie Tools wie GCC, so z.B. die 
Yagarto toolchain (die ich übrigens auch sehr empfehlen kann).

von 900ss (Gast)


Lesenswert?

> 1. embOS ist deutlich schneller, ich weiß jetzt nicht wie es beim

Es ist natürlich technisch eleganter, wenn man einen Taskwechsel auch 
schnell durchführen kann, keine Frage. Ist aber erst WIRKLICH 
interessant, wenn man diese Geschwindigkeit auch braucht. Rechenzeit die 
übrig ist, bekommt man schließlich nicht in Euro erstattet ;-)

> 2. Wenn ich ein OS benutzen möchte, dann will ich nicht erst irgendwas
> portieren und zusammenbasteln müssen.

Ist sicher ein Argument. Ich werde meinen Port zu Micrium schicken. Dann 
gibt es dort auch einen Cortex-M3-Port für GNU GCC für alle. Es ist 
reiner Zufall wenn Segger einen Port hat, der paßt. Also nicht wirklich 
ein Argument.

> 3. Bei Segger hast du deutschen Support, der mehr als bemüht ist.

Das trifft sicher auf die kommerziellen Produkte zu. Also beim J-Link 
bekommst du für die none commercial Version KEINEN direkten Support. 
"Nur" das Forum. Eine "none commercial" Version für embOS mögen sie 
rausrücken, aber da wirst du auch KEINEN Support bekommen. Also für 
kommerzielle Anwendung ist embOS sicher eine gute Wahl. Aber im privaten 
Bereich, wenn es denn eine Version gäbe, sicher nicht besser als uc/OS 
auch.

Und ich habe beim Kauf von dem J-Link keine gute Erfahrung mit Segger 
gemacht. Ich habe dort erstmal angerufen (zweimal) und beidemal war der 
Mitarbeiter wohl gerade eingenickt ("Jaa, öhhh, hmm.. ja also da... 
eigentlich, bla bla bla"). Und dann habe ich eine Auskunft bekommen, die 
hätten sie sich auch schenken können. Der hatte keine Ahnung oder wollte 
nicht. Eben evtl. wegen privaten Gebrauch. Die vergessen aber, dass ich 
das evtl. auch mal im Job in Betracht ziehen könnte. Ich war da erstmal 
ziemlich enttäuscht. Habe den J-Link aber trotzdem gekauft und bin sehr 
zufrieden damit.

So und nun zurück zum Thema des Threads ;-)

Gruß 900ss

PS. Danke für das Hilfeangebot zum ARM GCC. Vielleicht brauche ich die 
ja mal. Bin ziemlich neu auf ARM/Cortex. Hast du (Gast) auch einen 
Namen? Melde dich doch an. Finde ich persönlicher. :-)

von Gast (Gast)


Lesenswert?

"Ist aber erst WIRKLICH interessant, wenn man diese Geschwindigkeit auch 
braucht."
Ja, das sehe ich im Prinzip genauso, aber es zeigt doch wieviel mehr 
Arbeit Segger da rein gesteckt hat.

"Es ist reiner Zufall wenn Segger einen Port hat, der paßt. Also nicht 
wirklich ein Argument."

Häh? Was hat das mit Zufall zu tun? Du kannst davon ausgehen, das Segger 
embOS auf alle gängigen Mikrocontroller/Compiler laufen hat. Und wie 
gesagt, falls nicht, kann man immer nochmal anfragen, ob die eben einen 
Port machen, auch als Privater.


"Das trifft sicher auf die kommerziellen Produkte zu. Also beim J-Link
bekommst du für die none commercial Version KEINEN direkten Support.
"Nur" das Forum. Eine "none commercial" Version für embOS mögen sie
rausrücken, aber da wirst du auch KEINEN Support bekommen. Also für
kommerzielle Anwendung ist embOS sicher eine gute Wahl. Aber im privaten
Bereich, wenn es denn eine Version gäbe, sicher nicht besser als uc/OS
auch."

Hmmm...ok, haste recht, aber ich weiß, das von dieser Regel auch gerne 
mal abgwichen wird. Ich mein ist ja klar, wenn du denen als Privater 
mitteilst, das du einen Fehler gefunden hast oder ein Problem hast, 
werden die nicht sagen, ne, den Fehler beheben wir jetzt nicht... ;-).

"Und ich habe beim Kauf von dem J-Link keine gute Erfahrung mit Segger
gemacht. Ich habe dort erstmal angerufen (zweimal) und beidemal war der
Mitarbeiter wohl gerade eingenickt ("Jaa, öhhh, hmm.. ja also da...
eigentlich, bla bla bla"). Und dann habe ich eine Auskunft bekommen, die
hätten sie sich auch schenken können. Der hatte keine Ahnung oder wollte
nicht. Eben evtl. wegen privaten Gebrauch. Die vergessen aber, dass ich
das evtl. auch mal im Job in Betracht ziehen könnte. Ich war da erstmal
ziemlich enttäuscht. Habe den J-Link aber trotzdem gekauft und bin sehr
zufrieden damit."

Ich schätze das du da einen vom First Level Support und nicht einen 
Entwickler dran hattest. Das darf natürlich nicht sein, ich kann dir da 
nur den Tipp geben dich direkt an eine Entwickler zu wenden, ist ja 
klar, das die mehr Ahnung haben als die Sales/Office Leute.

Da ist aber auch der Vorteil von dem Forum, weil das wird ausschließlich 
von den Entwicklern betreut, sprich ob ein privater dort eine Frage 
stellt oder ein Entwickler von einem Kunden eine Supportanfrage bekommt, 
wird gleich behandelt.


Aber jetzt wirklich zurück zum Topic ;-), sorry, wenn ich etwas 
ausführlicher geantwortet habe. Werde mich bei Gelegenheit mal anmelden.

von Qduda 1. (Firma: student) (qduda)


Lesenswert?

900ss sag mal, hast du noch irgendwas am eigentlich Kernel verändert? 
Ich glaube daher kommen meine Linkerprobleme der hat "Multiple 
definitions", und das kann nur daher rühren dass irgendwelche Header 
nicht oder falsch includiert sind. Ich habe gesehen das sehr viel mit 
#include guards gearbeitet wird, das macht die Struktur extrem 
unübersichtlich.
Ist aber auch egal, weil eigentlich sollte man ja nur die Port Dateien 
"os_cpu_c.c", "os_cpu_a.asm2", "os_cpu.h" anpassen müssen. Die 
eigentlichen µC/OSII ("os_core.c", "ucos_ii.c", etc.) Dateien sollten 
eigentlich unberührt bleiben. Ich bin mir jetzt natürlich nicht sicher, 
ob die irgend einen besonderen Dialekt verwendet haben, die der GNU ln 
so vielleicht nicht verträgt.

Sorry wenn ich dich damit nerve, aber man findet kaum Referenzen zu der 
ganzen Sache.

von 900ss (Gast)


Lesenswert?

@Qduda:
Muß ich Am Wochenende schauen. Ich meine zwar nicht, aber wer weiß.
Ich werde nochmal das Original mit meiner Version vergleichen.
include-Guards sollten immer vorhanden sein.

Evtl. ist dein Projekt fehlerhaft? An multible defs kann ich mich 
jedenfalls auch nicht erinnern. Kompileire das doch erstmal als 
Original, also nur die asm-Dateien tauschen wegen GCC und dann als CPU 
den Cortex-M3 einstellen. Wenn das durchläuft, dann machst du einen 
Schritt weiter.

Gruß 900ss

von Tom (Gast)


Lesenswert?

@Gast
Ich habe letzte Woche genau deswegen bei Segger angerufen, embOS Cortex 
M1/M0 IAR bzw. embOS Cortex M1/M0 GNU steht wohl bei denen auf der ToDo 
Liste und wird in den nächsten Wochen umgesetzt.

Gruß,
Tom

von 900ss (900ss)


Lesenswert?

Qduda 12345 schrieb:
> 900ss sag mal, hast du noch irgendwas am eigentlich Kernel verändert?

Nein, hab gerade nachgesehen.

> Ich glaube daher kommen meine Linkerprobleme der hat "Multiple
> definitions", und das kann nur daher rühren dass irgendwelche Header
> nicht oder falsch includiert sind.

Klein anfangen mit dem Original, nur die ASM-Dateien tauschen, dann 
sollte das meißte gehen.

> Ich habe gesehen das sehr viel mit
> #include guards gearbeitet wird, das macht die Struktur extrem
> unübersichtlich.

Nöö, eigentlich nicht. Ich hab das Gefühl, du bist irgendwie auf dem 
Holzweg.

> Ist aber auch egal, weil eigentlich sollte man ja nur die Port Dateien
> "os_cpu_c.c", "os_cpu_a.asm2", "os_cpu.h" anpassen müssen.

Ich habe kein *.asm2 und die os_cpu_c.c mußt du nicht anfassen. Nur die 
ASM-Dateien.

> Die
> eigentlichen µC/OSII ("os_core.c", "ucos_ii.c", etc.) Dateien sollten
> eigentlich unberührt bleiben. Ich bin mir jetzt natürlich nicht sicher,
> ob die irgend einen besonderen Dialekt verwendet haben, die der GNU ln
> so vielleicht nicht verträgt.

Nein.

>
> Sorry wenn ich dich damit nerve, aber man findet kaum Referenzen zu der
> ganzen Sache.

Referenzen zum C-Dialekt findet man jede Menge. Aber die C-Dateien 
konnte ich zumindest so übersetzen.

Gruß 900ss

von Qduda 1. (Firma: student) (qduda)


Lesenswert?

Danke für die Antwort. Das ".asm2" war ein Schreibfehler. Natürlich muss 
es ".asm" heißen.

von Qduda 1. (Firma: student) (qduda)


Lesenswert?

Also die Linkerprobleme die ich nicht nachvollziehen konnte, habe ich in 
den Griff bekommen. Dieser Link hier ist interessant: 
http://article.gmane.org/gmane.os.micrium/627
Ich habe einfach die ucos_ii.c vom Build ausgeschloßen, und schon 
verschwinden die meisten der Fehler. Verstehe allerdings nicht warum 
denen ihr Port-Package diese Datei enthält, wenn man die nicht verwenden 
soll. Ist klar das es zu multiple Declarations kommt, wenn diese Datei 
andere .c Dateien includiert. Ich dachte immer das darf man auf keinen 
Fall tun.

Naja, jetzt stehe ich allerdings swit Samstag vor dem Problem das der 
Linker wieder hängen bleibt. Ich bin mir nicht ganz sicher ob es am 
Assembler code liegt. Die Ausgabe sieht wie folgt aus:

----------------------------------------------------------------

'Building target: noch_ein_Versuch'
'Invoking: GNU C Linker'
arm-none-eabi-gcc -mthumb -mcpu=cortex-m1 -specs=bare.specs 
-o"noch_ein_Versuch"  ./Source/os_core.o ./Source/os_flag.o 
./Source/os_mbox.o ./Source/os_mem.o ./Source/os_mutex.o ./Source/os_q.o 
./Source/os_sem.o ./Source/os_task.o ./Source/os_time.o 
./Source/os_tmr.o  ./Ports/ARM-Cortex-M1/NO_OS/RealView/os_cpu_a.o 
./Ports/ARM-Cortex-M1/NO_OS/RealView/os_cpu_c.o 
./Ports/ARM-Cortex-M1/NO_OS/RealView/os_dbg.o
c:/programme/sourcery-g++/bin/../lib/gcc/arm-none-eabi/4.2.3/../../../.. 
/arm-none-eabi/lib/armv6-m\armv7m-crt0.o:  In function `start':
/scratch/paul/lite/src/newlib-lite/libgloss/arm/crt0.S:(.text+0x4e): 
undefined reference to `main'
./Ports/ARM-Cortex-M1/NO_OS/RealView/os_cpu_a.o: In function 
`OS_CPU_CM1_ExceptHndlr_CtxSw':

----------------------------------------------------------------

Hier bleibt dann der Linker einfach hängen, und ich muss den Prozess 
abschießen.


Ich habe eigentlich nur den µC/OS-II Source genommen und die CM1 Port 
Dateien. Habe die Assembler Datei getauscht und die Datei app_cfg.h 
(leer) erstellt, da er diese an ein paar stellen inkludiert. Diese muss 
allerdings auch nur Code enthalten, wenn man eine Anwendung einbinden 
möchte.

Bin mir jetzt nicht sicher woran es liegen kann. Kann ja praktisch alles 
sein. Linker, Tool-chain, IDE, assembler Datei.
Hat ein GCC Experte eine Idee?

Bin für jeden Hinweis dankbar!

von Gast (Gast)


Lesenswert?

Wenn ich das richtig sehe, spuckt der Linker doch zwei Fehler aus.
1. Hast du eine Applikation dazu gepackt? Dem fehlt doch ein main().

2. "./Ports/ARM-Cortex-M1/NO_OS/RealView/os_cpu_a.o: In function 
`OS_CPU_CM1_ExceptHndlr_CtxSw':"
Ähhh....tolle Fehlermeldung ;-), schön das der GCC sagt wo was nicht 
stimmt, was jetzt nicht stimmt, müssen wir raten??

Magst du dein Projekt einfach mal zippen und hier posten?

von Paul (Gast)


Lesenswert?

> Ich habe einfach die ucos_ii.c vom Build ausgeschloßen, und schon
> verschwinden die meisten der Fehler. Verstehe allerdings nicht warum
> denen ihr Port-Package diese Datei enthält, wenn man die nicht verwenden
> soll. Ist klar das es zu multiple Declarations kommt, wenn diese Datei
> andere .c Dateien includiert. Ich dachte immer das darf man auf keinen
> Fall tun.

Soll wohl ein tolles Feature von uC/OS-II sein, man soll halt entweder 
die ucos_ii.c einbinden oder die ganzen C Files einzeln.

Ich finde sowas aber auch eher befremdlich und finde es führt wie bei 
dir wohl nur zu Fehlern.

von Qduda 1. (Firma: student) (qduda)


Lesenswert?

Gast schrieb:
> Wenn ich das richtig sehe, spuckt der Linker doch zwei Fehler aus.
> 1. Hast du eine Applikation dazu gepackt? Dem fehlt doch ein main().

Die hab ich mittlerweile drin. Fehler bleibt aber.


> 2. "./Ports/ARM-Cortex-M1/NO_OS/RealView/os_cpu_a.o: In function
> `OS_CPU_CM1_ExceptHndlr_CtxSw':"
> Ähhh....tolle Fehlermeldung ;-), schön das der GCC sagt wo was nicht
> stimmt, was jetzt nicht stimmt, müssen wir raten??
Ich hab mir das assembly schon so oft angeschaut, der Syntax ist 
richtig. Keine Ahnung was der Linker damit für ein Problem hat. Ich kann 
die os_cpu_a.s dem assembler geben, der baut mir nen Object (.o) file 
draus, klappt wunderbar.
>
> Magst du dein Projekt einfach mal zippen und hier posten?
Jupp das werde ich morgen mal machen. Bin nämlich langsam am 
verzweifeln. Wie soll man einen Fehler beheben der einem nicht angezeigt 
wird. Heute sicher 4 Stunden mit Recherche verbraten. :(

von 900ss (900ss)


Lesenswert?

Die Datei ucos_ii.c ist in dem CM3-Port nicht enthalten. Im Z80 oder 
386-Port aber auch. Man darf dann eben nur die einbinden in sein 
Projekt. Ist ja nicht so schwer zu verstehen. Hilft dir allerdings auch 
nicht bei deinem Problem.

Du könntest in dem Assemblersource die Funktion 
`OS_CPU_CM1_ExceptHndlr_CtxSw' mal auskommentieren, evtl. kommt der 
Linker zum Ende und du siehst mehr. Natürlich nicht, warum er in 
`OS_CPU_CM1_ExceptHndlr_CtxSw' stecken bleibt. Ansonsten poste das ins 
Forum von Codesourcery. Vielleicht weiß da einer was mit anzufangen.

Gruß 900ss

von Qduda 1. (Firma: student) (qduda)


Angehängte Dateien:

Lesenswert?

Anbei mein Projekt als Zip Archiv. Das Passwort für das Archive ist 
"mikrocontroller". Falls jemand mal Zeit und lust hat kann er es gerne 
mal versuchen durch den GCC zu jagen.

Ich habe Eclipse + CodeSourcery Toolchain zur Erstellung verwendet.

von Qduda 1. (Firma: student) (qduda)


Lesenswert?

Komisch, wieso kein ich meinen letzten Beitrag nicht editiren?

Naja ich habe noch ne Anmerkung, bei dem Zip File fehlt der Startupcode. 
Das führt zu "undefined reference to `main'" was aber egal ist, solange 
man das .bin nicht auf nen Controller Flashed. Kompilieren und Linken 
sollte es dennoch.

von Qduda 1. (Firma: student) (qduda)


Angehängte Dateien:

Lesenswert?

Sorry für die mehrfach Posts hier, aber die "Bearbeiten"/"Editiren" 
Funktion gibts bei mir irgendwie nicht mehr. :/

@900ss:
Das habe ich schon versucht, dann bleibt er bei der nächsten Funktion 
stehen. Hab schon mal alle Funktionen auskommentiert, dann beschweren 
sich aber die c Dateien (erwartungsgemäß) dass Sie die betroffenen 
Funktionen bzw. Symbole nicht mehr finden können.
Ich werde da wirklich jetzt mal bei CodeSourcery nachfragen, glaube zwar 
nicht das es sich um einen Bug handelt, aber vielleicht haben die einen 
Ansatz zur Lösung.

von Gast (Gast)


Lesenswert?

Mach das mal anders, nicht die ganzen Funktionen ausdokumentieren, 
sondern leere Funktionen stehen lassen, also nur das Label.

von Gast2 (Gast)


Lesenswert?

> bei dem Zip File fehlt der Startupcode.
> Das führt zu "undefined reference to `main'" was aber egal ist, solange
> man das .bin nicht auf nen Controller Flashed. Kompilieren und Linken
> sollte es dennoch.

Häh? Ne, "undefined reference to `main'" kommt wenn kein main() da ist. 
Und dann linkt es auch nicht.

von Qduda 1. (Firma: student) (qduda)


Lesenswert?

@Gast danke für den Tipp wenn ich nur den Funktionskopf stehen lasse 
(Als leere Funktion sozusagen) bleibt er auch hängen. (Bei der leeren 
Funktion)
Kann mir nicht vorstellen das es an der Funktion liegt. Das Verhalten 
ist doch nicht logisch.

@Gast2: ja du hast recht, hatte zwei Dinge im Kopf. Ich meinte dass er 
kein Einsprungsymbol finden wird und dann eine Adresse per default 
annimmt (_start). Das ist aber zum kompilieren und Linken selber egal.
Eine main() muss natürlich vorhanden sein, sonst geht gar nichts. ;-)

von Gast (Gast)


Lesenswert?

Ich kann das Zip File leider nicht öffnen, womit hast du das gepackt???

Dll: C:\Program Files\WinZip\WZ32.DLL - 98-10-17 07:00
Extracting to "c:\tmp\"
Use Path: yes   Overlay Files: no
skipping: noch_ein_Versuch/.cproject  unsupported compression method 99
skipping: noch_ein_Versuch/.project  unsupported compression method 99
skipping: noch_ein_Versuch/app/app.c  unsupported compression method 99
skipping: noch_ein_Versuch/app/app_cfg.h  unsupported compression method 
99
skipping: noch_ein_Versuch/Debug/app/app.d  unsupported compression 
method 99
skipping: noch_ein_Versuch/Debug/app/app.o  unsupported compression 
method 99
skipping: noch_ein_Versuch/Debug/app/subdir.mk  unsupported compression 
method 99
skipping: noch_ein_Versuch/Debug/makefile  unsupported compression 
method 99
skipping: noch_ein_Versuch/Debug/objects.mk  unsupported compression 
method 99
skipping: 
noch_ein_Versuch/Debug/Ports/ARM-Cortex-M1/NO_OS/RealView/os_cpu_a.o 
unsupported compression method 99
skipping: 
noch_ein_Versuch/Debug/Ports/ARM-Cortex-M1/NO_OS/RealView/os_cpu_c.d 
unsupported compression method 99
skipping: 
noch_ein_Versuch/Debug/Ports/ARM-Cortex-M1/NO_OS/RealView/os_cpu_c.o 
unsupported compression method 99
skipping: 
noch_ein_Versuch/Debug/Ports/ARM-Cortex-M1/NO_OS/RealView/os_dbg.d 
unsupported compression method 99
skipping: 
noch_ein_Versuch/Debug/Ports/ARM-Cortex-M1/NO_OS/RealView/os_dbg.o 
unsupported compression method 99
skipping: 
noch_ein_Versuch/Debug/Ports/ARM-Cortex-M1/NO_OS/RealView/subdir.mk 
unsupported compression method 99
skipping: noch_ein_Versuch/Debug/Source/NO_OS/RealView/os_cpu_a.o 
unsupported compression method 99
skipping: noch_ein_Versuch/Debug/Source/NO_OS/RealView/os_cpu_c.d 
unsupported compression method 99
skipping: noch_ein_Versuch/Debug/Source/NO_OS/RealView/os_cpu_c.o 
unsupported compression method 99
skipping: noch_ein_Versuch/Debug/Source/NO_OS/RealView/os_dbg.d 
unsupported compression method 99
skipping: noch_ein_Versuch/Debug/Source/NO_OS/RealView/os_dbg.o 
unsupported compression method 99
skipping: noch_ein_Versuch/Debug/Source/NO_OS/RealView/subdir.mk 
unsupported compression method 99
skipping: noch_ein_Versuch/Debug/Source/os_core.d  unsupported 
compression method 99
skipping: noch_ein_Versuch/Debug/Source/os_core.o  unsupported 
compression method 99
skipping: noch_ein_Versuch/Debug/Source/os_flag.d  unsupported 
compression method 99
skipping: noch_ein_Versuch/Debug/Source/os_flag.o  unsupported 
compression method 99
skipping: noch_ein_Versuch/Debug/Source/os_mbox.d  unsupported 
compression method 99
skipping: noch_ein_Versuch/Debug/Source/os_mbox.o  unsupported 
compression method 99
skipping: noch_ein_Versuch/Debug/Source/os_mem.d  unsupported 
compression method 99
skipping: noch_ein_Versuch/Debug/Source/os_mem.o  unsupported 
compression method 99
skipping: noch_ein_Versuch/Debug/Source/os_mutex.d  unsupported 
compression method 99
skipping: noch_ein_Versuch/Debug/Source/os_mutex.o  unsupported 
compression method 99
skipping: noch_ein_Versuch/Debug/Source/os_q.d  unsupported compression 
method 99
skipping: noch_ein_Versuch/Debug/Source/os_q.o  unsupported compression 
method 99
skipping: noch_ein_Versuch/Debug/Source/os_sem.d  unsupported 
compression method 99
skipping: noch_ein_Versuch/Debug/Source/os_sem.o  unsupported 
compression method 99
skipping: noch_ein_Versuch/Debug/Source/os_task.d  unsupported 
compression method 99
skipping: noch_ein_Versuch/Debug/Source/os_task.o  unsupported 
compression method 99
skipping: noch_ein_Versuch/Debug/Source/os_time.d  unsupported 
compression method 99
skipping: noch_ein_Versuch/Debug/Source/os_time.o  unsupported 
compression method 99
skipping: noch_ein_Versuch/Debug/Source/os_tmr.d  unsupported 
compression method 99
skipping: noch_ein_Versuch/Debug/Source/os_tmr.o  unsupported 
compression method 99
skipping: noch_ein_Versuch/Debug/Source/subdir.mk  unsupported 
compression method 99
skipping: noch_ein_Versuch/Debug/sources.mk  unsupported compression 
method 99
skipping: noch_ein_Versuch/Linker_Skript/ram-debug.ld  unsupported 
compression method 99
skipping: noch_ein_Versuch/Ports/ARM-Cortex-M1/NO_OS/RealView/os_cpu.h 
unsupported compression method 99
skipping: noch_ein_Versuch/Ports/ARM-Cortex-M1/NO_OS/RealView/os_cpu_a.s 
unsupported compression method 99
skipping: noch_ein_Versuch/Ports/ARM-Cortex-M1/NO_OS/RealView/os_cpu_c.c 
unsupported compression method 99
skipping: noch_ein_Versuch/Ports/ARM-Cortex-M1/NO_OS/RealView/os_dbg.c 
unsupported compression method 99
skipping: noch_ein_Versuch/Source/os_cfg.h  unsupported compression 
method 99
skipping: noch_ein_Versuch/Source/os_core.c  unsupported compression 
method 99
skipping: noch_ein_Versuch/Source/os_flag.c  unsupported compression 
method 99
skipping: noch_ein_Versuch/Source/os_mbox.c  unsupported compression 
method 99
skipping: noch_ein_Versuch/Source/os_mem.c  unsupported compression 
method 99
skipping: noch_ein_Versuch/Source/os_mutex.c  unsupported compression 
method 99
skipping: noch_ein_Versuch/Source/os_q.c  unsupported compression method 
99
skipping: noch_ein_Versuch/Source/os_sem.c  unsupported compression 
method 99
skipping: noch_ein_Versuch/Source/os_task.c  unsupported compression 
method 99
skipping: noch_ein_Versuch/Source/os_time.c  unsupported compression 
method 99
skipping: noch_ein_Versuch/Source/os_tmr.c  unsupported compression 
method 99
skipping: noch_ein_Versuch/Source/ucos_ii.c  unsupported compression 
method 99
skipping: noch_ein_Versuch/Source/ucos_ii.h  unsupported compression 
method 99

von 900ss (900ss)


Lesenswert?

Bei mir geht es mit Totalcommander. Danke übrigens für die hilfreichen 
Fehlermeldungen deines Entpackers. Windows XP selber sagt auch 
"ungültige Komprimierungsmethode".

Leider kann ich es aber nicht in mein Eclipse importieren. :-(

900ss

von Qduda 1. (Firma: student) (qduda)


Lesenswert?

Das Archiv ist mit WinZip11 gepackt. Ich kanns mit WinZip, WinRar und 
unzip entpacken. Sorry wenn das Probleme macht. Ich denke das liegt an 
der Verschlüsselung des Archivs.

Ich habe jetzt den Fehler gefunden. Es lag am Parser! Der ist hängen 
geblieben! Irgendwie gabs nen Problem zwischen Eclipse, Cygwin und dem 
Parser. Ich verwende jetzt einen anderen und jetzt geht's. Die Fehler 
die noch kamen waren in erster Linie hinweise auf noch nicht 
implementierte Funktionen, was sich schnell beheben lies.
Ich habe das OS jetzt kompiliert bekommen, und auch schon einen ersten 
Task zum testen geschrieben. Läuft auf meiner Targethardware. Bin jetzt 
erstmal dran die Interrupts anzubinden etc.

Danke für eure Hilfe!

von Gast (Gast)


Lesenswert?

> Danke übrigens für die hilfreichen Fehlermeldungen deines Entpackers

Jaja, sorry, hatte das nur einfach rüberkopiert und nicht gemerkt, das 
das ein bisschen mehr war ;-).

Ich benutze auch den Total Commander, und bei mir gehts nicht :-(.

Aber ich freu mich, das Qduda auch so weitergekommen ist.

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.