Assemblercode in C-Projekt

[plitzi (Gast)]

Ich bin mir darüber im Klaren, dass diese Frage sicherlicherlich für
viele ein "alter Hut" ist und möglicherweise auch das eine oder
andere RTFM provoziert, aber ich komme im Augenblick nicht ernsthaft
weiter.

Trotz meiner bisherigen Abneigung gegenüber C sehe ich mich mehr und
mehr gezwungen, mich doch damit zu beschäftigen. Und damit der Einstieg
nicht so schwer fällt, wollte ich einiges aus meiner
Assemblerprogrammiererei mit hinüberretten. Also Assemblerroutinen in
C-Prgramme einbinden, gibt es ja auch einiges an Literatur dazu
(AVR034.pdf...). Und der eigentliche Quelltext ist es ja auch (bisher)
nicht. Ich scheiter schon daran, wie ich dem Projekt und/oder Workspace
(IAR-AVR) erkläre, dass zu der main.c noch eine Assembler-Datei gehört,
in der er die in main.c deklarierte(?) Funktion dann wirklich findet.
In den Hilfequellen sind zwar die Texte für die Beispiele abgedruckt,
aber die Struktur des Projektes oder einfach nur die Dateinamen kann
ich daraus nicht nachvollziehen. Beides (C und Aseembler) in EINE Datei
geht ja wohl nicht (Syntaxfehlermeldung vom Compiler). Also beide
Dateien einzeln (main.c und asmroutine.s90). In der main.c die Funktion
dann über "extern void ASMTest(void);" deklarieren... aber er findet
diese Funktion (natürlich) nicht, ich befürchte, er kann sie gar nicht
finden, weil er nicht weis, dass er in asmroutine.s90 suchen soll. Aber
wie sage ich ihm das? Hat da jemand ein ganz einfaches Beispiel?

Danke
Jörg

[Peter Dannegger (Gast)]

In der Regel sind Assemblerprogramme so geschrieben, daß sie alleiniger
Herrscher über alle Ressourcen sind.

Es gehört sehr viel Erfahrung und viel Aufwand dazu, es so
umzuschreiben, daß es kooperativ, d.h. mit anderen Objekten und
Bibliotheken linkbar ist.

Kurz gesagt, vergiß es.


Eventuell kann man einzelne Passagen per Inline-Assembler schreiben,
was aber fast nie wirklich nötig ist.


Peter

[plitzi (Gast)]

Vielen Dank, Peter, für den "väterlichen" Rat (überhaupt nicht böse
gemeint!!!), also werde ich wohl nicht umhinkommen, und ganz klein mit
C anzufangen. :(

Ich wollte igentlich ja nur ein paar "Treiber", die ich mir für die
Ansteuerung bestimmter Bauteile (ext. ADC ...) (vorerst)
weiterverwenden. Aber im Grunde genommen hast Du ja Recht und dieser
Mischmasch birgt sicher mehr Problem als Vorteile. Mir ging es ja
eigentlich auch nicht in erster Linie um Sinn und Unsinn von Assembler
in C, sondern vielmehr, wie man das mit dem IAR-Compiler rein vom
Syntax zum laufen bringt. Hat da vielleicht doch noch jemand einen Tip
oder ein einfaches Beispiel (mit *.eww-Datei usw.)?

Jörg

[JojoS (Gast)]

den IAR Compiler kenne ich nicht persönlich, aber grundsätzlich:
>aber er findet diese Funktion (natürlich) nicht
'Er' ist da nicht der Compiler, der muss mit der external Deklaration
zufrieden sein. Im Assembler Code ist das Zauberwort 'Public' (siehe
die AN die du angegeben hast) wichtig, damit wird das Label in dem
übersetzen Output in eine extra Tabelle eingetragen. Meckern wird der
Linker wenn eben ein Modul etwas extern erwartet aber es keiner
Public liefert. Ist die Dateiendung .s90 standard bei IAR? Sonst würde
ich .asm nehmen. Die Projektverwaltungen machen das oft über die Endung
um die Quelle eben mit C-Compiler oder Assembler zu übersetzen. Gibts
bei IAR evtl. so einen Projektbaum wo man im Kontextmenu die Sourcen
hinzufügen kann ? Daraus sollte die Projektverwaltung dann automatisch
die nötigen Compiler aufrufen und das Ganze dem Linker anbieten. Oder
gibt es Projekteinstellungen/Linker wo die nötigen Module angegeben
werden müssen ?

[plitzi (Gast)]

Ich habe mich schon mit eineigen IDEs mit/für C-Compiler gestritten und
vielleicht klebe ich deshalb so an der Assemblerprogrammierung. Da gibt
es ein AssemblerEntry-File und von dort kann/muss ich dann alle anderen
Dateien über include einbinden, fertig.

Bei den Compilern gibt es offensichtlich offensichtlich leider
erheblich Unterschiede in der Projeltverwaltung (ok), im Syntax ("Für
welchen Compiler ist das denn?"), bei den mitgelieferten Bibliotheken
usw. Also sollte man sich so früh wie möglich auf einen Compiler
festlegen. Ich experiemtiere hier gerade mit der KickStart-Version von
IAR für den AVR, den ICCAVR gibt es ja nun auch in einer light-Variante
für den unbefristeten Gebrauch und mit WinAVR habe ich auch schon
rumgemacht. Bei letzterem habe ich einfach das Programm installiert und
ein Beispielprogramm aus dem www (für AVRGCC geschrieben!) ausprobiert.
Im Gegensatz zu den anderen Compilern werde ich hier nicht gleich mit
Fehlermeldungen bombardiert, im Gegenteil, ich sehe überhaupt kein
Output-fenster (obwohl es eingschalten ist) und eine hex-Datei entsteht
auch nicht, nur Stille nach dem "make". Da macht der Ein-/Umstieg
besonders Spaß:( Also doch ganz von vorn, mit einem guten Buch, dem
einfachen "Hello world" und viel Geduld.

Nochmals Danke.

Jörg

[Peter Dannegger (Gast)]

> Vielen Dank, Peter, für den "väterlichen" Rat


Ich hab selber versucht so anzufangen und bin überhaupt nicht
klargekommen.

Jetzt kenne ich den Compiler gut genug, um es machen zu können, aber
brauchen tue ich es nicht mehr.


Der einfachste Weg ist, ein Dummy-Programm in C zu schreiben, das
sämtliche benötigten Variablen und Funktionen enthält und dieses dann
nicht zum Object zu compilieren, sondern zu Assembler.
Dieses Assemblerfile kann man dann als Grundgerüst nehmen, um seinen
Assemblertext einzufügen.

Wichtig ist, daß keinerlei absolute Adressierung (Code, SRAM) enthalten
ist. Das will nämlich der Linker alles selber machen und wird sehr
sauer, wenn er sowas findet.

Damit nun das Assemblerfile auch gefunden wird, muß man es zum Built
hinzufügen. Dann weiß die IDE, daß es assembliert und gelinkt werden
muß.


Aber wie gesagt, es ist ein Henne-Ei-Problem:

Du must Dich mit dem Compiler auskennen, um Assembler einbinden zu
können.

Kennst Du Dich aber erst aus, brauchst und willst Du keinen Assembler
mehr einbinden.


Peter