Datum: 02.05.2008 11:46
Guten Morgen! Ich versuche, mit GCC für den MSP430-Controller eine Bibliothek zusammenzustellen, damit ich meine Funktionen nicht dauernd kopieren muss. Dazu habe ich mir das Tutorial auf dieser Seite durchgelesen (http://www.mikrocontroller.net/articles/Libraries). Zum testen habe ich mir folgende Dateien erstellt: Die Funktion typechange.c: #include "libtest.h" int typechange(char c) { return (int) c; } Und eine Header-Datei libtest.h mit folgendem Inhalt: int typechange(char c); Ich arbeite unter Windows und habe "mspgcc" installiert. Auf der Zeile compiliere ich mit dem Befehl "msp430-gcc.exe -c typechange.c". Dann bekomme ich folgerichtig das Object-File "typechange.o". Im Anschluss packe ich das Object-File zur eigentlichen Library mit "msp430-ar.exe -rcs libtest.a typechange.o". Funktioniert optimal, ich bekomme die Library "libtest.a". Dann schreibe ich mir meine Main (Datei main.c): #include "libtest.h" int main(void) { return typechange('A'); } Auf der Zeile tippe ich zum linken: "msp430-gcc.exe -o test.com main.c -L. -ltest". Keine Fehlermeldung, die Datei "test.com" wird erzeugt und lässt sich ausführen. Nun kann ich aber den Rückgabewert, der "65" sein sollte, nicht kontrollieren, da er auf der Konsole nicht angezeigt wird. Nun möchte ich die erstelle Library in IAR verwenden. Beim Ausführen bekomme ich allerdings die Fehlermeldung "Error[e46]: Undefined external "typechange" referred in main ( C:\Documents and Settings\daniel\Desktop\iartest\Debug\Obj\main.r43 )" Nun frage ich mich, warum der Linker "typechange" nicht auflösen kann und was ich dagegen machen kann. Vielleicht könnt ihr mir dabei ja helfen. Vielen Dank schonmal! Daniel
Datum: 02.05.2008 11:58
Daniel wrote:
> Nun möchte ich die erstelle Library in IAR verwenden.
Es gibt keine echte Normierung wie Libaries aufgebaut sein
müssen. Jeder Hersteller kocht da sein eigenes Süppchen.
Eine Library, die du mit Produkt xxx erstellt hast, wird mit
Produkt yyy nicht funktionieren.
Datum: 02.05.2008 12:12
Deine Headerdatei braucht noch (einen) Verweis(e) auf die Libery(s) in welche(r/n) die die declarierte(n) Funktionen definiert ist(sind).
Datum: 02.05.2008 12:37
stichwort compilerdirektiven:
versuchs mal so.
da keine Pfade dabei sind erstmal alle Dateien in den Arbeitsordner
oder wenn es getrennte Ordner für include- und libery_dateien gibt diese
dort hin
______________________________
libtest.c //hauptprogramm
//****************************
#include "libtest.h"
int main(void)
{
return typechange('A');
}
______________________________
"libtest.h" //headerdatei
//*****************************
#ifndef libtest_INCLUDED
#define libtest_INCLUDED
#pragma used+
int typechange(char c);
#pragma used-
#pragma library libtest.lib // verweis auf libery
#endif
____________________________________
"libtest.lib" //liberydatei(kann beliebig viele Funktionen enthalten
//**********************************
int typechange(char c)
{
return (int) c;
}
___________________________________
gruß winne = bereits weg
Datum: 02.05.2008 13:24
Danke für eure Antworten. Die Pragmas kennt IAR leider nicht. Welchen Zweck hätten diese? Die mit
#ifndef libtest_INCLUDED #define libtest_INCLUDED int typechange(char c); #endif |
abgeänderte libtest.h hat auch nicht funktioniert. Was bewirken diese Direktiven eigentlich genau? Meine Library hat zudem die Endung .a und nicht .lib. Wo wird .lib verwendet und könnte das einen Einfluss haben? Ich dachte, ich habe mit der oben beschriebenen Vorgehensweise eine "Standard C-Bibliothek" erstellt, die jeder Compiler für diesen Controllertyp versteht. Wenn ich aber das Posting von Karl Heinz Buchegger durchlese, könnte mein ganzes Vorhaben völlig um sonst sein. Dann müsste ich die Bibliotheken mit den Tools von IAR erstellen und kann diese dann aber auch nur mit der Entwicklungsumgebung von IAR verwenden. Doof irgendwie, wenn ich später ne andere Umgebung verwenden will... Grüße, Daniel
Datum: 02.05.2008 13:30
>Doof irgendwie, wenn ich später ne andere Umgebung verwenden will...
Klingt doof, ist aber so. Willkommen im Leben...
Und selbst auf Sourcelevel ghibt es keine Kompatibilität. gcc nach IAR,
und umgekehrt, erfordert auch im Sourcecode Änderungen.
Oliver
Datum: 02.05.2008 15:46
Oliver wrote: > Und selbst auf Sourcelevel ghibt es keine Kompatibilität. gcc nach IAR, > und umgekehrt, erfordert auch im Sourcecode Änderungen. Und dann gibts dann noch das weite Feld der "calling conventions". Welcher Compiler übergibt wie Funktionsargumente an Funktionen? Wenn überhaupt, wieviele von den Argumenten landen in welchen Registern? In welchem Register kommt der Returnwert zurück oder liegt der vielleicht doch am Stack? .... Apropos: Wie gross ist eigentlich ein int? Und kann es sein, dass ein int dieselbe Größe wie ein long hat? (Ist ne rethorische Frage, die dich zum Nachdenken über mögliche Unterschiede bei verschiedenen Compilern anregen soll und was daraus für Bibliotheken folgt.) > Dann müsste ich die Bibliotheken mit den Tools von IAR erstellen > und kann diese dann aber auch nur mit der Entwicklungsumgebung > von IAR verwenden. Das ist im Regelfall noch das kleinere Übel. In Bibliotheken schreibt man den Code entweder * so, dass er universell einsetzbar ist: Sprich Standard-C und nur Standard-C. In dem Fall genügt es meist, den Quellcode für die Bibliothek einmal neu zu übersetzen und die Library neu zu bilden. Ist meist kein großes Thema * so, dass man die Hardwareabhängigen Teile in der Library kapselt. Die ist aber meist so compilerspezifisch, dass man sowieso ran muss.
Datum: 02.05.2008 17:23
Hallo daniel meine directivenbeispiele entstammen dem CVAVR wenn dein compiler diese nicht akzeptiert, so bleibt dir nichts anderes als die vür deinen Compiler gültigen zu studieren. #include "libtest.h" // bindet eine headerdatei ein (in ihr sollten externe funktions,variablen und konstantendefinitonen vorgenommen werden, so können programme zum beispiel durch ändern der Chipspezifischen headerdateien auf ander chips der gleiche familie portiert werden.) #ifndef libtest_INCLUDED // begin der if schleife es wird getestet ob "libtest_INCLUDED" noch nicht definert ist #define libtest_INCLUDED in diesem fall wird "libtest_INCLUDED" definiert #pragma used+ // die folgenden funktionen (etc.) werden nur dann dclariert wenn der compiler sie tatsächlich benötigt int typechange(char c); // funtionsdeclaration (prototyp) #pragma used- // used pragma wird wieder ausgeschaltet #pragma library libtest.lib // verweis auf libery #endif // hier endet die if schleife
Datum: 02.05.2008 17:27
Vielleicht aber kennt dein Compiler aber auch diese Direktiven oder ähnliche, und nur die Syntax ist eine andere. Das hat es leider oft wenn man Beispielprogramme von einer Plattform auf eine andere portieren will. :-((
Datum: 05.05.2008 17:35
Alles klar! Danke für eure kompetente Hilfe! Daniel
Antwort schreiben
Die Angabe einer Email-Adresse ist freiwillig. Wenn Sie automatisch per Email über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
- Suchfunktion und Betreffsuche benutzen - vielleicht gibt es schon einen ähnlichen Beitrag
- Aussagekräftigen Betreff wählen
- Im Betreff angeben um welchen Controllertyp es geht (AVR, PIC, ...)
- Groß- und Kleinschreibung verwenden
- Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
- JPEG-Dateien (.jpg) nur für Fotos verwenden, Schaltpläne, Screenshots usw. als PNG oder GIF anhängen
Formatierung (mehr Informationen...)
- [c]C-Code[/c]
- [avrasm]AVR-Assembler-Code[/avrasm]
- [pre]vorformatierter Text (z.B. Code in anderen Sprachen)[/pre]
- [math]Formel in LaTeX-Syntax[/math]
- [[Titel]] - Link zu Artikel


