Ein mutiger, vermutlich aber eher wahnsinniger Versuch: die Bitte um
Umschreiben der „Preliminarien“ eines Programmes - erzeugt mit PIC
MPASMWIN – auf PIC-ASS.
Hintergrund: Seit Jahren programmiere ich als Hobby Progs z.B. für den
PIC18F14K22 in dem vormaligen Assembler-Speech des MPASWIN. Das klappt
auch recht gut, übliche Hakeleien inbegriffen, aber da läuft doch
erbaulich viel und gut. Nun hat’s eine neue Hakelei mit der Verwendung
von Sprungbefehlen und der Nutzung von Flags gegeben. Da läuft Etliches
nicht wie erwartet. Die daraus resultierenden Probleme habe ich gelöst,
das läuft also inzwischen, aber ich würde sehr gerne ausprobieren, ob
die neuere Version des PIC-Assemblers, das PIC-ASS sich da anders, rsp.
besser verhält. Das wäre ein super-kurzer Test eines eher niedlich
kleinen Programmes und weil das so kurz wäre, komme ich auf meinen
verwegenen Gedanken.
Natürlich weckt das Anlesen der Microchip Migrationsdokumentation vom
älteren zum neueren Assembler Stirnrunzeln, und ein Blick in das
Databook des neuen PIC-ASS macht die Sache noch unübersichtlicher. Kurz
gesagt, da würde ein Haufen an Einarbeitungszeit drauf gehen. Für einen
kurzen Test, dessen evtl. auch nicht erfreuliches Ergebnis dazu führen
würde, dass vom neuen Ass. erst mal kein Gebrauch gemacht würde, einfach
zu viel Zeit.
Mein Gedanke: Wenn jemand vertraut, rsp. geübt mit dem PIC-ASS wäre,
dann wären es für diesen Geübten ein paar Federstriche, die formalen
Start-Formulierungen des beigefügten Programmes umzuschreiben auf die
neue, erforderliche Syntax. Sind nur ein paar wenige Ausdrücke, und -
nein – das eigentliche Programm schreibe ich schon selbst. Genauer
gesagt, das existiert ja und dessen Umschreiben ist eher eine
Fleißübung.
Ist klar – die wertvolle Pädagogik des Selbstschreibens ! Und – ach ja –
das schäbbige Abwälzen einer Bemühung. Aber bitte, es gibt verschiedene
Wege, eine Programmiersprache zu erlernen. Die vielen Verschiedenen
will ich nicht debattieren, aber mein Zugang zu so was ging immer über
kurze, funktionierende (!) Beispiele. Das war schon bei
Z80-Programmierung über das sagenhafte ZX-80-Kochbuch des
Funkschau-Verlages so, das war auch bei MPASWIN so mit den hoch zu
lobenden Prog-Schnipseln, die Microsoft ihrem Programmier-Adapter
PICKit3 beifügte. Auch ein entlarvend deutliches Prinzip aus der
Pädagogik sei erwähnt: Ein Bild sagt mehr als 1.000 Worte.
Daher auch meine zweite Bitte: wer nicht mag oder den PIC-ASS nicht
kennt oder wem das nicht gefällt, der möge sich seinen Teil denken und
es bitte dabei belassen. Die oder den geneigten Kenner bitte ich um
freundliche Übersetzungshilfe, auch einzelne Zeilen wären Anlass zur
Freude. Die angefügte Text-Datei enthält im oberen Bereich das
Assembler-File, erzeugt mit MPASWIN und im unteren Teil das vom
PIC-ASS-Debugger erzeugte Error-File.
Grüße, wilhelmT
Be T. schrieb:> Natürlich weckt das Anlesen der Microchip Migrationsdokumentation vom> älteren zum neueren Assembler Stirnrunzeln,
Nun ja, da hast du also ein Problem, bei dem dir all die hier
versammelten C-Programmierer nicht wirklich weiterhelfen können. Aber
sei nicht traurig, denn so ähnliches Stirnrunzeln hatte ich schon vor
über 20 Jahren. Die Assembler von MicroChip sind in der mittlerweile
verstrichenen Zeit offenbar nicht besser geworden - jedenfalls wenn ich
in deine Beispieldatei schaue und mir die zugehörige PIC18F14K22.inc
anschaue.
Es ist m.E. eine recht gute Idee, die diversen Konfigurationsdinge incl.
Userkennung usw. im Hexfile unterzubringen, wozu ganz einfach ein nicht
im adressierbaren Bereich gelegener Adreßbereich benutzt wird. Aber das
mit so etwas ähnlichem wie Makros zu tun, ist etwas weniger genial.
Ich nehme mal an, daß all das, was hinter dem 'CONFIG' steht, sowas ist.
Wenn das zutrifft und dein Assembler da keine Zicken macht, dann würde
ich ersatzeshalber so etwas vorschlagen:
Apollo M. schrieb:> ... die Beispiele sollten helfen
Nice ;-)
Die Behauptung bezüglich des #include <xc.inc> beim 14k22 Beispiel ist
zwar etwas seltsam, weil bei Erzeugung über das entsprechende Menü dies
auch erst nach den Config Bits stattfindet. (sogar mit Hinweis)
Perfekt wäre, wenn auch die Interruptvektoren schon im Code vorgesehen
wären (wie bei den "alten" MPASM Templates)
Hat mich trotzdem weiter enorm gebracht, weil durch das "global" bei den
Variablen endlich der Groschen gefallen ist, wie ich es schaffe, dass
diese im Debugger auch angezeigt werden.
Im Nachhinein finde ich das jetzt auch im nützlichen Dokument:
MPLAB_XC8_PIC_Assembler_User_Guide_for_Embedded_Engineers.pdf
(XC8 Compiler docs Verzeichnis)
Volker S. schrieb:> Im Nachhinein finde ich das jetzt auch im nützlichen Dokument:> MPLAB_XC8_PIC_Assembler_User_Guide_for_Embedded_Engineers.pdf> (XC8 Compiler docs Verzeichnis)
Ja, ABER es gibt einige Hürden/Bugs, die ich erst durch trail&error
teilweise klären konnte, z.B. zu den wichtigen Link Anweisungen und
unerwartete Einschränkungen bei Macros. Im Vergleich zur MPASM Doku ist
die zum PIC-AS unbefriedigend.
Die Portierung der PIC-AS Toolchain für den Frequency Counter von DL4YHF
war mühsam (www.qsl.net/dl4yhf/freq_counter/freq_counter.html), aber
dennoch erfolgreich.
Ich habe gerade wieder Lust auf Assembler und bin dabei einen simplen
Frequency Counter mit vielen neuen Funktionen zu schreiben, dem eine
strukturierte SW zu grunde liegen wird, so dass jederzeit eine
Portierung auf beliebige pic16/pic18 gelingen sollte.
Es fehlt auch an einer Unterstützung im MPLABX Editor für den PIC-AS und
der Simulator hat seit Urzeiten tonenweise Bugs ...
Apollo M. schrieb:> s fehlt auch an einer Unterstützung im MPLABX Editor
Ich fange gerade erst an mich mit dem xc8 Assembler zu beschäftigen,
weil MPASM seit MPLABX-IDE >v5.35 nicht mehr integriert ist.
Wundere mich aber auch über die ziemlich schwache Unterstützung :-(
Volker S. schrieb:> weil MPASM seit MPLABX-IDE >v5.35 nicht mehr integriert ist.
MPASM V5.8 habe ich händisch eingebaut unter Tools/Embedded/Build Tools
und läuft. Benutze ich aber bevorzugt nur zur anschliessenden Portierung
von Projekten.
Beispiel wie es geht ...
Ich rate ab, selber Linker zu spielen und mit absolute org zu hantieren,
wie im Beispiel gezeigt!
Sondern benutzt besser immer die -p Option in der Projekt Config. Hier
dann entspr. für Code Segment "-pResetVec", gilt analog auch für RAM u.
EEPROM!
Ich habe jetzt einige große fremde MPASM Projekte nach pic-as portiert,
das ist problemlos in wenigen Stunden an einem Tag realisierbar.
Es gibt für mich keine erkennbaren Nachteile mit pic-as, aber einige
Besonderheiten und vergrabene wichtige Infos im User Guide von pic-as.
Es fehlen im User Guide immer wieder Beispiele zur Klarstellung, daher
musste am Anfang vieles zeitintensiv mit Trail and Error Ansatz
herausgefunden werden.
Es gibt einige Vorteile mit pic-as, z.B. optimiert der Assembler sogar
in Grenzen den Code - was man wissen sollte, weil das nicht immer
gewünscht sein muss z.B. bei der write EEPROM Signature.
Wer Probleme hat MUSS zuvorderst das User Guide intensiv lesen und
Anweisungen ausprobieren.
Es gibt auch Besonderheiten mit/in Macros, zB. geht nicht logisch &
sondern es muss "and" or "&&" sein.
Wer spezielle Probleme hat, dem kann ich weitere Hinweise geben.
