Hallo alle Ich möchte gerne das angehängte File zu einem HEX-File builden. Doch ich bekomme Errors. Ich verwende die neuste Version der MPLAB X IDE. Ich verwende den pic-as(v2.5) compiler Danke für Inputs!
Angehängte Dateien:
-
errors.png
310 KB
Nach der hatte ich schon gesucht, kann sie aber nirgends finden im web..
Ich habe das File inzwischen gefunden. Wie muss ich die TXT-Datei in die Library integrieren? Wohl nicht als Textdatei, oder?
Laurin schrieb: > Ich habe das File inzwischen gefunden. Ja und sonst noch? wäre ja schon spannend hier.
Wie gesagt habe ich das File FP.TXT gefunden. Ich kenne mich aber noch nicht wirklich mit MPLAB IDE aus. Deshalb weiss ich nicht, wie ich diesen Text zu einer Library für mein assembler file machen kann.
Ich sehe ja in Zeile 1261:
1 | INCLUDE <FP.TXT> |
Doch egal, ob ich FP.TXT in Source Files oder in Header Files lege, kommen die Errors trotzdem
Einfach ins selbe Verzeichnis wie deinen Quellcode packen, dann lässt sich das problemlos assemblieren. Ich hab das Hexfile mal angehängt. Cyblord -. schrieb: > Warum hat ne library eine .TXT Endung? Das darf die haben. Die dürfte sogar .CYBLORD heißen, aber das will ja niemand.
:
Bearbeitet durch User
H. H. schrieb: >> Warum hat ne library eine .TXT Endung? > > Das darf die haben. Nur war das nicht die Frage.
:
Bearbeitet durch User
Laurin schrieb: > Hier den Anfang des Output-Fensters Dann würde ich mal vorschlagen, mit der Behebung des allerersten Fehlers zu beginnen. Da passt doch etwas ganz grundsätzlich nicht. Gut möglich, dass all die anderen Fehler nur Folgefehler sind.
Ich kenne die aktuelle MPLAB X zu wenig, verwende noch die schon 12 Jahre alte MPLAB 8.84, und damit läuft das problemlos. Haben die einen ganz neuen Assembler mit anderer Syntax eingebaut?
In deinem ersten Bild wird der Assembler mit -mcpu=PIC16F628A, vermutlich von deiner Projekt Definition, aufgerufen. Im .asm-File in Zeile 176 wird der processor auf 16f628 definiert. Angeblich beißt sich das. Ich würde einfach mal Zeile 176 auskommentieren und schauen was dann passiert :-) Edit: Und ggf die richtige .inc Datei includen falls sich der A und der nicht A unterscheiden.
:
Bearbeitet durch User
Cyblord -. schrieb: > Nur war das nicht die Frage. Es ist gar keine Library, aber seit der Arduinoisierung können das viele nicht mehr differenzieren. Weil es ja den einen kleinen Ausnahmefall gibt, daß in C++ tatsächlich Code in einer Headerdatei (*.h) untergebracht sein kann, deswegen muss man die bislang klare Differenzierung zwischen Sourcedatei, Headerdatei, Objektdatei und Library in die Tonne treten. Hilft ja auch total bei der Fehlersuche, so etwas. Früher (tm) hätte diese Datei *.inc geheißen.
Harald K. schrieb: > Es ist gar keine Library, aber seit der Arduinoisierung können das viele > nicht mehr differenzieren. Die gabs schon als Arduino noch in weiter Ferne lag, und sowas wurde auch damals schon Library genannt. ; RCS Header $Id: fp24.a16 2.7 1996/10/07 13:50:29 F.J.Testa Exp $ ; $Revision: 2.7 $ ; PIC16 24 BIT FLOATING POINT LIBRARY
H. H. schrieb: > und sowas wurde > auch damals schon Library genannt. Dann nennen wir doch fortan einfach alles Library. Das macht das Leben viel einfacher, und so Nitpickeligkeiten wie das, was ein Linker macht, die sind für die KI da, damit muss man sich nicht mehr beschäftigen.
Harald K. schrieb: > Weil es ja den einen kleinen Ausnahmefall > gibt, daß in C++ tatsächlich Code in einer Headerdatei (*.h) > untergebracht sein kann, deswegen muss man die bislang klare > Differenzierung zwischen Sourcedatei, Headerdatei, Objektdatei und > Library in die Tonne treten. Das ist doch Unsinn. Auch in C kann man "Code" in Headerdateien schreiben (bei allem, bei dem man inlining forcieren möchte, muss man das sogar). Und in Asm natürlich sowieso. Wenn schon rummeckern, dann am C-Konzept. Denn das hätte hergeben müssen, das in Headern kein Code sein kann und kein Code sein muss. Das hat C nicht leisten können, weil es halt nur ein wahnwitzig aufgeplusterter Macro-Assembler ist. Und naja: C++ hat's dann von C geerbt... > Früher (tm) hätte diese Datei *.inc geheißen. Nö. Die hätte einfach *.asm geheißen. Weil: da wird tatsächlich Code erzeugt. Das entspricht einer *.c-Datei (du scheinst ja sowieso nix anderes zu kennen, deswegen diese Erläuterung für dich). Das Äquivalent zu einer *.h-Datei im C/C++-Umfeld nennt man im Asm-Umfeld dann allerdings tatsächlich bevorzugt *.inc. Das macht klar, dass hier eben kein Code erzeugt werden soll. Code-Konstrukte sollten in solchen Dateien nur als Macros auftauchen, was Funktionen mit force inline in C entspricht.
Ob S. schrieb:
Alles richtig, aber wohl unwichtig für das konkrete Problem des TO.
Da kommt es darauf an, was diese IDE tut und was der verwendete
Assembler tut.
Ich kenne beide nicht, aber im Prinzip gibt es zwei Varianten:
1) Der Kram wird in ein linkbares Zwischenformat übersetzt und am Ende
gelinkt. Dann müsste in der Ausgabe zwei Aufrufe für den Assembler
sichtbar sein und ein Aufruf für den Linker. Sieht allerdings nicht
danach aus, als wenn es so wäre.
2) Das ist noch ein old-school-Assembler. Dann muß der Quelltext der
"Lib" an irgendeiner Stelle im Quelltext des Hauptteils includiert
werden. Dabei kommt es wieder darauf an, ob das ein OnePass- oder ein
Mehrpass-Assembler ist. Bei OnePass muß die Include-Direktive zwingend
vor dem Teil des Quelltextes stehen, der Code erzeugt (zumindest vor dem
ersten Aufruf einer Subroutine aus dem includierten Code). Bei Mehrpass
ist es egal, ob davor oder dahinter. Der Assembler dröselt die
Referenzen in einem späteren Pass alleine passend auf.
Ob S. schrieb: > ein Aufruf für den Linker. So weit kommt es beim TE ja gar nicht, bei meiner älteren IDE schon. Ich hab der aber auch erzählt, dass es um einen PIC16F628 geht, nicht PIC16F628A. Allerdings gäbe es da bei der älteren Version nur eine Warnung, nicht einen Abbruch.
H. H. schrieb: > Ob S. schrieb: >> ein Aufruf für den Linker. > > So weit kommt es beim TE ja gar nicht, bei meiner älteren IDE schon. Ich > hab der aber auch erzählt, dass es um einen PIC16F628 geht, nicht > PIC16F628A. Allerdings gäbe es da bei der älteren Version nur eine > Warnung, nicht einen Abbruch. Das spricht dann eindeutig dafür, dass der verwendete Assembler keine linkbaren Code erzeugt. Der TO sagt: > pic-as(v2.5) compiler Was'n das? Gehört das zur IDE? Ist die darauf vorbereitet? Ist das überhaupt ein Assembler? Fragen über Fragen...
Ob S. schrieb: > Der TO sagt: > >> pic-as(v2.5) Assembler >> compiler Der TE kennt den Unterschied wohl nicht.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.