Mpasm Fallen

[PICture]

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

[PicNick]

moment, Kollege, jetzt tust du aber dem armen MPSAM Unrecht.
durch das #define hast du letztlich hingeschrieben:

CLRF Flags, 0
und damit hast du ihn schwer beleidigt, denn für den Befehl CLRF ist alles ab dem Beistrich illegal.

was meinst du mit "unsichtbaren Zeichen" ?

Ich bin kein Aktionär von Microchip

[PICture]

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

[Smokey]

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

[PicNick]

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.

[PICture]

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 :)

[kalledom]

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

[*Mario*]

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

[PICture]

Hallo *Mario*!

Ich verstehe die Beschreibung Deines Problems leider nicht ganz (z.B. was ist *.asm/*.inc ?). Vielleicht kann ich Dir helfen.

MfG :)

[*Mario*]

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

[PICture]

Hallo *Mario*

Schön, dass Du wieder was berichtest. Ich schreibe jetzt ein Programm (in ASM) für mein Logic Analyser und habe ich bis jetzt ca. 16 kB fertig.
Ich wollte mir die Variablen in Bank 5 ablegen, aber es ist leider ohne relocable code nicht möglich (habe ich sogar im Microchip Forum nachgefragt). Ich kann mir aber, wegen den bremsenden "banksel", das nicht leisten, da es sehr schneller multitask ist.

Ich benutze Timer0 und Timer1 zum Messen der Taktfrequenz (variabler LC Oszillator) und musste externen 32 kHz Oscillator verwenden, weil der Timer1 Oszillator mit einem Uhrenquarz nicht funktioniert hat, oder wenn schon, dann nicht auf der Quarzfrequenz, sondern daneben. Ich mache alles echt und halte Simmulationen als Zeitverlust. Um externen Oscillator für Timer1 zu nutzen, muss aber Timer1 Oscillator in T1CON eingeschaltet (T1OSCEN bit gesetzt) sein. Das ist aber eine Falle vom Datenblatt. Ich hoffe, dass ich durch die alle Fallen durchkomme und mein Logic Analyser bald fertig wird.

Schöne Grüsse ! :)

[*Mario*]

Hallo PICture,

ich werd mir das mal im Datenblatt (MCU-Manual) zum Timer1 ansehen. Klingt jedenfalls komisch. Zu den Simulationen: Prinzipiell gebe ich Dir recht, dass Aufbau mehr Wahrheit zeigt. Ich Simuliere hauptsächlich mehr wegen Ermangelung an Ausrüstung und Zeit (da kann ich mal zwischendurch was machen ...).
Der zweite Grund ist, dass man besseres Debugging in MPLAB machen kann. Beispielsweise einen EEPROM mit dessen Protokoll.

Für den Timer kannst Du's wie folgt machen:
Erstelle eine Text-Datei (Endung .scl) mit folgendem Inhalt:

configuration for "pic16f876a" is
end configuration;


testbench for "pic16f876a" is
begin

RTCLKIN: process is
begin
loop
T1CKI <= '0';
wait for 15 us;
T1CKI <= '1';
wait for 16 us;
end loop;
end process RTCLKIN;

end testbench;

Dann kannst Du mit "Attach SCL" die Datei in MPlab einhängen. Damit kannst Du dann den Code testen, der Timer wird brav das machen was er soll, auch interrupt generieren (wenn konfiguriert).
Grüße
Mario

[PICture]

Hallo *Mario*!

Vielen Dank für Deine Bemühungen mich zur Simulation zu bringen, da hast Du aber leider keine Chancen! :)

Was nutzt mir das, wenn in der Wirklichkeit, der Uhrenquarz vom Timer1 Oszillator als Kondensator gesehen wird ?

Schöne Grüsse!

[Ritchie]

Hallo Zusammen,

wäre ein Hinweis auf die verwendete Version nicht von Nutzen ?
Oder ist es bei Euch immer die aktuelle Version.

Gruss Ritchie

[*Mario*]

@Ritchie,

guter Hinweis. Ich beziehe mich auf die Version 7.31. War bis vor kurzem noch die neueste Version ...
Ich glaube dass es ratsam ist, immer auf die neueste Version zu setzen, die Liste der bekannten Fehler ist ja geradezu erschreckend! (wegen SCL werde ich aber nicht auf 8.xx umsteigen (können)).

@PICture,

hast vollkommen recht. Da ich kein Oszi habe, kann ich das sowieso nicht nachprüfen, bzw. nur über den PIC selber (Main-Clock-Vergleich mit 32kHz Clock etc. , sonst ist "gut raten" angesagt. Ich benutze deshalb die Simulation für digitale Anwendungen, analoges ist aussen vor :). Da kriegt man wirklich die blödsten Fehler raus, beispielsweise Display-ansteuerung, digitale nicht-standard Bauteile, etc. ...

Gruß
Mario

[PICture]

Hallo!

Anscheinend ist die Reihenfolge den "#define" Direktiven wichtig. Ich weiss es nicht warum, aber bei dem zweiten Beispiel im Code wird das Unterprogramm "RegClr" nicht ausgeführt, wenn "call Test0" benutzt wird.

Wenn es aber so wie in dem ersten Beispiel definiert wird, funktioniert es.

MfG


#define @DT PORTB,7
#define @CK PORTB,6
#define @TDT TRISB,7
#define @TCK TRISB,6
#define Test0 RegClr
#define _Fcra Flags,0
#define _Fcrp Flags,1
#define _Fdca Flags,2
#define _Ferr Flags,3

#define @DT PORTB,7
#define @CK PORTB,6
#define @TDT TRISB,7
#define @TCK TRISB,6
#define _Fcra Flags,0
#define _Fcrp Flags,1
#define _Fdca Flags,2
#define _Ferr Flags,3
#define Test0 RegClr