Vom MPASMWIN zum PIC-ASS : Übersetzungshilfe.

[Be T. (wilhelmt)]

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

[W.S. (Gast)]

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:

     SEG   CODE   ; CSEG hernehmen - vorausgesetzt, dein Assembler kann das
     ORG   300000h
CONFIG1L: DEFB  .... ; naja, was du da eben drin haben willst
CONFIG1H: DEFB  .... ; dito
CONFIG2L: ... usw. bis CONFIG7H

W.S.

[Apollo M. (Firma: @home) (majortom)]

... die Beispiele sollten helfen. Ist Google bei dir kaputt?

https://github.com/dsoze1138/MPLABXv5xx_pic-as_examples

[Volker S. (vloki)]

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)

[Apollo M. (Firma: @home) (majortom)]

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

[Volker S. (vloki)]

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

[Apollo M. (Firma: @home) (majortom)]

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.

[Apollo M. (Firma: @home) (majortom)]

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!

// programm-name: "assembl-test"
#include <xc.inc>
processor 18F14K22

;Config settings
#undef PLLEN //workaround hack
CONFIG IESO = OFF, PLLEN = OFF, FOSC = IRC, FCMEN = OFF, PCLKEN = OFF
CONFIG BOREN = OFF, BORV = 19, PWRTEN = OFF, WDTEN = OFF
CONFIG MCLRE = ON, HFOFST = OFF, DEBUG = OFF, STVREN = ON
CONFIG XINST = OFF, BBSIZ = OFF, LVP = OFF
CONFIG CP0 = OFF, CP1 = OFF
CONFIG CPD = OFF, CPB = OFF
CONFIG WRT0 = OFF, WRT1 = OFF
CONFIG WRTB = OFF, WRTC = OFF, WRTD = OFF
CONFIG EBTR0 = OFF, EBTR1 = OFF
CONFIG EBTRB = OFF

psect udata_acs, global, class=COMRAM, abs, ovrld, space=1, noexec
;psect udata_bank0, class=BANK0, space=SPACE_DATA, reloc, ovrld, noexec
org 0x10
global temp
temp: ds 1

org 0x20
global temp2
temp2: ds 1
;.............................................................................
psect ResetVec, global, class=CODE, abs, ovrld, delta=2
;psect ResetVec, global, class=CODE, delta=2

ResetVec:
   bra      StartInit

org 0x20
StartInit:
   movlw    00000010B       ;set cpu clock speed of 31KHz
   movwf    OSCCON,A       ;move contents of working register into OSCCON
   clrf     OSCTUNE,A
   clrf     LATA,A       ;Configure as output
   clrf     LATB,A
   clrf     LATC,A
   clrf     TRISA,A
   clrf     TRISB,A
   clrf     TRISC,A
MainLoop:
   movlw  20              ;dez 20 in WREG
   movwf  temp,A
   incf  temp2,A
   nop
   bra  MainLoop

   end  ResetVec

[Apollo M. (Firma: @home) (majortom)]

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.