Assemblerdatei unter Eclipse einbinden

PUSH
Sind meine Fragen zu dumm (wahrscheinlich) oder zu schwer (kann ich mir 
nicht vorstellen), um sie zu beantworten?!

Wär auch schon über einen Tipp aufs richtige Manual/Thread froh.

Mit installiertem Eclipse-plugin und automatischen makefiles gibt es in 
den Project-Properties den Bereich C/C++-Build/Settings, in dem sich 
alles einstellen lässt. Das makefile erstellt Eclipse dann selber.

Alternativ baust du dir ein makefile von Hand (oder besser mit MFile aus 
dem WinAVR-Paket), und nutzt das auch unter Eclipse. Es gibt aber kaum 
Gründe, nicht die automatischen makefiles von Eclipse zu verwenden.

Nicht funktionieren Sourcecode bitte anhängen. Das spart dir seitenlange 
Beschreibungen, die am Ende doch keiner versteht. Prinzipiell ist das 
includieren von .c-Files der falsche Weg.

Oliver

Oliver schrieb:
> Mit installiertem Eclipse-plugin und automatischen makefiles gibt es in
> den Project-Properties den Bereich C/C++-Build/Settings, in dem sich
> alles einstellen lässt. Das makefile erstellt Eclipse dann selber.

Das hab ich gefunden, allerdings gibts da unter "AVR Assembler"/General 
nur "(-Xassembler) options", "Other GCC Flags" oder "Include paths 
(-I)".
Wobei man bei letzterem nur ein Verzeichnis angeben kann, keine 
einzelnen Dateien. Muss ich nun meine .S Dateien in ein Verzeichnis 
legen und das dann dort angeben?! Oder bin ich bei "AVR Assembler" 
falsch?

Für meine dritte Frage hier meine main.c:

1

/* C Test file */

2

#include <avr/io.h>

3

#include <stdint.h> 

4

#include <avr/interrupt.h>

5

#include </home/florian/eclipse/workspace/Beagle IMU/Sources/IO.h>

6

7

//[... paar Variablen für später ...]

8

9

int main(void) {

10

uint8_t pll_loop=0;

11

12

  #include "IO.c"

13

14

//lis auschalten:

15

16

  lis_off();

17

18

//wait for PLL lock:

19

  do {

20

    if(PING & 1){

21

      pll_loop=0;

22

    }

23

    else{

24

      pll_loop++;

25

    }

26

  } while (pll_loop<100);

27

28

//adis konfigurieren und adis_bias berechnen:

29

30

  adis_conf();

31

  adis_bias();

32

33

//auf BeagleBoard warten:

34

35

//boot completed: lis on, red LED off, global interrupts enabled:

36

  lis_on();

37

  PORTD &= !(LED_RED_MASK);

38

  sei();

39

40

  while(1) {

41

42

  }

43

  return 0;

44

}

Die vier Funktionsaufrufe lis_off(); lis_on(); adis_conf(); und 
adis_bias(); sollen aus der Assemblerdatei kommen, werden im Moment noch 
als undefined reference bemeckert.
Meine dritte Frage war jedoch, warum er innerhalb der IO.c dann bei 
simplen Zuweisungen wie " EICRA = 48; " oder " EIMSK = 0x04; " meckert, 
dass der Datentyp nicht stimmt.
Die IO.c ist etwas länger, deswegen hab ich sie mal als Datei angehängt.

>Muss ich nun meine .S Dateien in ein Verzeichnis
>legen und das dann dort angeben?!

Assembler-Dateien sind source-Dateien, und werden im source-Ordner des 
Projektes links in der Projektansich angegeben, doert, wo auch main.c 
und IO.c aufgelistet sind.

>#include </home/florian/eclipse/workspace/Beagle IMU/Sources/IO.h>

Macht man nicht, in <> eingeklammerte Pfade sind Systemdateien 
vorbehalten. User-Includes gehören in "". Das macht man nicht nur aus 
optischen Gründen, die Suchpfade unterscheiden sich. Daher musstest du 
auch den vollen Pfad angeben, damit das file gefunden wurde. Der 
Projektordner gehört nicht zu den System-Includepfaden, wohl aber zu den 
Projekt-Includepfaden. Deshalb reicht

1

#include "IO.h"

 wenn das .h-File im gleichen Ordner wie die .c-Dateien steht.

>Meine dritte Frage war jedoch, warum er innerhalb der IO.c dann bei
>simplen Zuweisungen wie " EICRA = 48; " oder " EIMSK = 0x04; " meckert,

Der Compiler compiliert jede Datei einzeln, völlig unabhängig von allen 
anderen. Daher muß jede C-Datei eigenständig kompilierbar sein. In 
deinem IO.c fehlen aber alle erforderliche includes, in diesem Fall 
#include <avr/io.h>. Daß die auch in main.c icludiert ist, ist egal.

Oliver

> Die vier Funktionsaufrufe lis_off(); lis_on(); adis_conf(); und
> adis_bias(); sollen aus der Assemblerdatei kommen, werden im Moment noch
> als undefined reference bemeckert.

Übergibst du dem Linker die aus der Assemblerfile genererierte 
Objektdatei (*.o) ? Falls ja, könnte es sein, dass du für die Funktionen 
keine Prototypen deklarierst (diese per Header-File einbinden) ?

Erst mal Vielen Dank für die zahlreichen Antworten.

Das heißt bei den Includes unterscheidet <> und "" nur die Suchpfade, 
das erklärt dann auch das verhalten. Demnach ist aber folgende Erklärung 
falsch:

http://www.acm.uiuc.edu/webmonkeys/book/c_guide/1.7.html#include

Denn die suggeriert, dass bei "" der include Befehl ähnlich einem Makro 
einfach die referenzierte Datei an dieser Stelle in den Quellcode rein 
kopiert, so als ob es direkt in der Datei stehen würde.
Da das ja offensichtlich nicht der Fall ist, is auch klar, dass die 
Header in der IO.c nochmal extra eingebunden werden müssen.

Mit der IO.c als korrekter Funktion und einer Header Datei mit 
Deklarationen zu allen Funktionen (auch denen aus der Assemblerdatei) 
und allen globalen Variablen sind nun fast alle Fehler behoben. Er 
scheint jetzt auch die Assemblerdatei zu futtern, war ja im Nachhinein 
doch recht einfach ;).

>Demnach ist aber folgende Erklärung
>falsch:

>http://www.acm.uiuc.edu/webmonkeys/book/c_guide/1....

Nö. Da steht genau das drin.

#include kopiert IMMER die referenzierte Datei an dieser Stelle in den 
Quellcode. Der Unterschied zwischen <> und "" besteht nur darin, in 
welchen Pfaden der Compiler die zu inkludierende Datei sucht.

Oliver