Hallo!
Ich habe das Thema eröffnet um Fallen im Mpasm zu sammeln. Ich hoffe, dass es nutzlich für alle die in ASM programmieren wird.
Ich möchte damit anfangen, dass Mpasm unsichtbare Zeichen, die direkt vor oder nach einem Label stehen, mit dem Label verbindet und meldet den Fehler: symbol not previously defined. Man sieht also zwei identische Labels, die aber für MPasm nicht identisch sind. Es hilft nur die alle Zeilen, in denen das Symbol vorkommt, komplett löschen und neu schreiben.
Gestern habe ich im Programm ein Fehler gemacht. Ich habe ein Flag "Finc" als Bit in Registef "Flags" definiert
(#define Finc Flags,0) und danach fehlerhaft "clrf Finc" anstatt "bcf Finc" geschrieben. Der Mpasm hat mir dann das als Fehler
", illegal character" gemeldet. Ich habe meinen Augen nicht geglaubt und habe einige Zeit verloren, um den Fehler zu finden.
Ich hoffe, dass ich nicht der einzige bin, der in die Mpasm Fallen reingefallen ist und bin gespannt was es noch gibt, auf was man als Benutzer von Mpasm aufpassen muss.
Viellen Dank für Eure Fallenbeschreibungen im voraus !
MfG
moment, Kollege, jetzt tust du aber dem armen MPSAM Unrecht.
durch das #define hast du letztlich hingeschrieben:
und damit hast du ihn schwer beleidigt, denn für den Befehl CLRF ist alles ab dem Beistrich illegal.CLRF Flags, 0
was meinst du mit "unsichtbaren Zeichen" ?
Ich bin kein Aktionär von Microchip
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Hallo PickNick!
Natürlich, der Befehl ist illegal. Warum schreibt er aber nicht "illegal instruction" oder "illegal argument" sondern "illegal character" und zietiert ein character der in der fehlerhaften Zeile überhaupt nicht vorkommt ?
Als unsichtbare Zeichen meine ich Zeichen wie z.B. Tabulatoren, Esc, Ctrl u.ä. Ich weiss es nicht genau was er da sieht, weil ich es leider nicht sehen kann.
Woher stammt Dein Zitat ? Ich sehe sowas in meinem Beitrag nicht.
MfG
Als Fehler möchte ich noch hinzufügen das der Dateiname des Assembler Files nur 8 Zeichen betragen darf(Sonst gibts beim assemblieren probleme).Ich habe bei meinem ersten Versuch auch den Fehler gemacht das ich die Kommentarzeilen zu lang gelassen habe(jede Zeile darf soweit ich weiß nur 40 Zeilen beinhalten). Ich habe ca 2 Wochen gebraucht um diese Fehler zu finden.
mfg Smokey
Naja, an den Fehlertexten könnt' man sicher arbeiten.
Lustig ist nur, setz einmal 10 Programmierer zusammen und laß sie über sinnvolle Fehlertexte nachdenken. Das gibt Mord- und Totschlag.
Du hast auch sicher recht, daß man unsichtbare Zeichen schlecht beschreiben kann. *g*
An sich isses bei Kompilern/editoren meist so, das alles außer TAB und space pfui-Zeichen sind, weil Trim- und adjust-Routinen darauf ausgelegt sind.
mfg robert
Wer glaubt zu wissen, muß wissen, er glaubt.
Hallo Smokey!
Vielen Dank! Das mit der Beschränkung der Kommentare habe ich nicht gewusst, weil ich fast keine schreibe. Das mit den Dateinamen kenne ich auch nicht. Mein Programm heist z.B. Logic_Analyser.asm und wird assembliert. Ich habe auf meinem Laptop noch Windows 98.
MfG
Hallo,
mit 'unsichtbaren' Zeichen habe ich weniger Probleme, die kann ich mit 'meinem' Editor UltraEdit sichtbar machen.
Mit Kommentaren auch nicht, denn die sind nur so lang, daß ich sie auf meinem Bildschirm mit 800x600 noch sehen kann.
Ansonsten habe ich mit MPASM keine Schwierigkeiten, da bei Fehlern die entsprechende Zeilen-Nummer angegeben wird.
Die meisten Fehler sind logische Fehler und Tipp-Fehler. Was da so alles 'schief laufen' kann habe ich mal auf folgender Seite unter 'Assembler-Programmier(er)-Fehler' aufgelistet: http://www.domnick-elektronik.de/piccheck.htm
MfG Karl-Heinz
HobbyElektronik hier klicken ....
Hallo,
gute idee über mpasm mal einen Gedankenaustausch zu starten. Ich bin zwar noch nicht über Fehler gestoßen (Ausser das zulange Verzeichnisnamen beim Linken/HEx-Datei erzeugen stören), meine aber dass das Segement und Modulkonzept in mpasm zwas nett angedacht, aber eben nicht zuende gedacht wurde. Ich habe es einfach noch nicht gebacken bekommen, eine library in einer separaten *.asm/*.inc Datei gut vom Rest abzugrenzen. Wenn man auf -sagen wir Konfigurationsvariablen - in der Library vom Hauptprogramm zugreifen muss, dann habe ich noch keinen Weg gefunden, eine Deklaration für diese Variable herzustellen. Auch gründliche Suche in der Dokumentation brachte nichts.
Ein anderes Kapitel, dass meines erachtens auch noch zu mpasm gehört ist mplab. Das hat meines erachtens die Schwäche, dass einige HW-Funktionen nicht oder nur unzulänglich simuliert werden (SPI, UART, ...). Da das aber Dokumentiert ist ist das eher zu den schwächen, als zu den Fehlern zu zählen.
Ach ja, mplab hat das PRoblem das es nach dem Aufwachen vom Standby bei Notebooks bei beenden oder speichern abstürzt.
Mario
Hallo *Mario*!
Ich verstehe die Beschreibung Deines Problems leider nicht ganz (z.B. was ist *.asm/*.inc ?). Vielleicht kann ich Dir helfen.
MfG
Hallo PICture,
so je´tzt hab ich endlich mal wieder Zeit (und Thread) gefunden um auf Dein Hilfeangebot zurückzukommen. Also, ich programmiere ausschließlich in Assembler. Die Quelldateien bekommen die Endung *.asm, die in der Source-Datei eingebundenen Dateien mit Beispielsweise Hilfsvariablen/konstanten (Registernamen, Bitpositionen, ...) haben bekanntlich die *.inc Endung. Das ist gleich wie bei C mit den *.c und *.h Dateien.
Wegen der vielen Banken (ich spreche hier nur vom Speicher), hat der Assembler Direktiven, mit denen der Assembler/Linker entscheidet, wohin dann schlussendlich damit (udata_shr, udata_ovr, .. direktiven). Wenn man keinen fixen Speicherplatz vorgibt, Entscheidet der Assembler über Platz. Um die Variable dann auch adressieren zu können, müsste vor jedem Zugriff ein "banksel" stehen. Das wiederum wird in zwei BSC/BCF Befehle umgewandelt => Programmspeicherfresser & Geschwindigkeitsbremser.
Ich möchte nun meine größeren Projekte sinnvoll gliedern. Dazu möchte ich "Library's" erstellen. Die Deklarationen kommen in die zugehörige *.inc-Datei. Tja, und blöderweise genau da hapert es dann, dort sieht man, dass das Speicherverwaltungskonzept noch nicht ganz so durchdacht ist. Ein weiteres Problem das ich habe ist es, teile von Interrupt-Routinen in eine Library auszulagern. Ausser den Code-Teil als Macro zu definieren, habe ich noch kein vernünftigeres Konzept gefunden.
Hoffe mich etwas klarer ausgedrückt zu haben.
Achja, kaum mal wieder aktiv, schon drängt sich der nächste Bug auf: Ich habe den Timer 1 an einen 32kHz Quarz gehängt (In MPLAB per SCL-emuliert). Wenn ich nun den Timer aktiviere und das zugehörige Pin im TRIS-Register nicht als Eingabe geschalten ist, wird das Signal nicht durchgereicht. Lt. Datenplatt sollte aber die Timer-Einstellung das TRIS-Bit überschreiben.
Draufgekommen bin ich, da ich einen "Kick"-Start eingebaut habe und die Kapazitäten vor timer-aktivierung lade (OSZ unstabil mache).
Gruß
Mario
Berechtigungen
Zitieren
Lesezeichen