Kann assembler file nicht builden

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

Im Anhang findet ihr die library

Warum hat ne library eine .TXT Endung?

Hab ich gemacht, aber bei mir siehts immer noch so aus:

Hier den Anfang des Output-Fensters

H. H. schrieb:

Warum hat ne library eine .TXT Endung?

Das darf die haben.

Nur war das nicht die Frage.

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.

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.

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.

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.

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...