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
:
Bearbeitet durch User
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:
1 | SEG CODE ; CSEG hernehmen - vorausgesetzt, dein Assembler kann das |
2 | ORG 300000h |
3 | CONFIG1L: DEFB .... ; naja, was du da eben drin haben willst |
4 | CONFIG1H: DEFB .... ; dito |
5 | CONFIG2L: ... usw. bis CONFIG7H |
W.S.
... die Beispiele sollten helfen. Ist Google bei dir kaputt? https://github.com/dsoze1138/MPLABXv5xx_pic-as_examples
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!
1 | // programm-name: "assembl-test"
|
2 | #include <xc.inc> |
3 | processor 18F14K22 |
4 | |
5 | ;Config settings |
6 | #undef PLLEN //workaround hack
|
7 | CONFIG IESO = OFF, PLLEN = OFF, FOSC = IRC, FCMEN = OFF, PCLKEN = OFF |
8 | CONFIG BOREN = OFF, BORV = 19, PWRTEN = OFF, WDTEN = OFF |
9 | CONFIG MCLRE = ON, HFOFST = OFF, DEBUG = OFF, STVREN = ON |
10 | CONFIG XINST = OFF, BBSIZ = OFF, LVP = OFF |
11 | CONFIG CP0 = OFF, CP1 = OFF |
12 | CONFIG CPD = OFF, CPB = OFF |
13 | CONFIG WRT0 = OFF, WRT1 = OFF |
14 | CONFIG WRTB = OFF, WRTC = OFF, WRTD = OFF |
15 | CONFIG EBTR0 = OFF, EBTR1 = OFF |
16 | CONFIG EBTRB = OFF |
17 | |
18 | psect udata_acs, global, class=COMRAM, abs, ovrld, space=1, noexec |
19 | ;psect udata_bank0, class=BANK0, space=SPACE_DATA, reloc, ovrld, noexec |
20 | org 0x10 |
21 | global temp |
22 | temp: ds 1 |
23 | |
24 | org 0x20 |
25 | global temp2 |
26 | temp2: ds 1 |
27 | ;.............................................................................
|
28 | psect ResetVec, global, class=CODE, abs, ovrld, delta=2 |
29 | ;psect ResetVec, global, class=CODE, delta=2 |
30 | |
31 | ResetVec: |
32 | bra StartInit |
33 | |
34 | org 0x20 |
35 | StartInit: |
36 | movlw 00000010B ;set cpu clock speed of 31KHz |
37 | movwf OSCCON,A ;move contents of working register into OSCCON |
38 | clrf OSCTUNE,A |
39 | clrf LATA,A ;Configure as output |
40 | clrf LATB,A |
41 | clrf LATC,A |
42 | clrf TRISA,A |
43 | clrf TRISB,A |
44 | clrf TRISC,A |
45 | MainLoop: |
46 | movlw 20 ;dez 20 in WREG |
47 | movwf temp,A |
48 | incf temp2,A |
49 | nop
|
50 | bra MainLoop |
51 | |
52 | end ResetVec |
:
Bearbeitet durch User
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.