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:
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
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
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 ;-)
> 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
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
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 ;-).
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
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
@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
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.
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 ;-).
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 ;-).
>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.
@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
@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
>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).
> 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. :-)
"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.
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.
@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
@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
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
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!
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?
> 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.
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. :(
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
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.
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.
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.
> 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.
@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. ;-)
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
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!
> 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.