PIC MPMASMX PIC-AS

'M' too much im title...

Mmh...
Sind hier nur noch {C-Fifis} unterwegs?

nimm GPASM

Ohneela Ssma schrieb:
> Sind hier nur noch {C-Fifis} unterwegs?

Ähem... nö.
Aber dein erster Beitrag verwirrt einen ein bissel:

Ohneela Ssma schrieb:
> Habe bisher z.B. für Displaymasken 'dt' benutzt.
> Der im 'Assembler Migration Guide' angegebene 'Ersatz',
>
> PSECT data
> symbols:
> IRP number,48,65h,6Fh
> retlw number
> ENDM

Hintergrund ist, daß ich den Assembler von Microchip nicht benutze.
Also was erwartest du an Daten im Data-Segment (aka RAM), ohne daß du 
das selber dort hin geladen hast?

W.S.

chris schrieb:
> nimm GPASM

Danke, das wird auch von GCB benutzt, oder?
Allerdings leider kein .inc-File für den 16F15214...

W.S. schrieb:
> Aber dein erster Beitrag verwirrt einen ein bissel:

Das ist ja nur das kopierte Beispiel aus besagtem Michrochip-PDF.
Dass da 'meine' Daten hin sollten ist verstanden... ;)
MPLAB schmeißt aber Fehler wegen des PSECTs.
Habe aber eben gesehen, dass wohl eine Inkompatibilität zwischen v5.35 
und
PIC16F1xxxx_DFP besteht. Erst mal ne cleane v6 installieren...

> Hintergrund ist, daß ich den Assembler von Microchip nicht benutze.
Womit beweist Du dann Deine Genialität? ;)

Ohneela Ssma schrieb:
> chris schrieb:
>> nimm GPASM
>
> Danke, das wird auch von GCB benutzt, oder?
> Allerdings leider kein .inc-File für den 16F15214...

Ja genau, Auszug aus dem Include, habe die ganzen Macros und  helper 
weggeloescht, sollte dann passen.

den 15214 habe ich auch, muss ihn aber erst raussuchen, poste das File 
asap.

Ohneela Ssma schrieb:
> Womit beweist Du dann Deine Genialität? ;)

Oh, nee, laß mal!

Ich benutze seit etwa 30 Jahren die PIC's und der damalige Assembler 
"PICALC" von Microchip hat mich bereits damals so sehr ange*****, daß 
ich mir einen eigenen Assembler geschrieben habe. Den benutze ich noch 
immer, wenngleich auch mit der Zeit ein bissel aktualisiert (DOS-->Win32 
usw.). Es ist kein aufgeblähtes Programm, sondern eher spartanisch: 
Quelle rein, Hexdatei raus.

W.S.

chris schrieb:
> Ja genau, Auszug aus dem Include,...

Das sieht mir aus, daß dort lediglich die im Chip vorhandenen Register 
mit Namen versehen werden. Wäre also etwas, das sich ein Jeder selber 
schreiben kann. Irgendein Statement, das den Codeumfang, also die 
implementierten Maschinenbefehle bezeichnet und tatsächlich die 
Maschinencode-Erzeugung beeinflußt, habe ich dort nicht gesehen. Also 
ist das eher heiße Luft mit der Bemerkung "den 16F15214 benutzen; von 
MPASMX nicht mehr unerstützt". Es fehlen wohl nur die Namen der 
vorhandenen Register. Oder??

W.S.

Ja, das sind die Register definitions.
Fuer die Coderzeugung dient die "processor" direktive, oder eben der 
Kommandozeilenparameter. Da musst du dir halt eine CPU der gleichen 
"codeclasse" raussuchen, z.B. 16f1526 , haengt auch davon ab wie aktuell
dein gpasm ist.

Weiters abhaengig ob du absoluten oder relativen Code erzeugst musst du
den code noch linken, also braucht du ebenfalls ein lks file fuer den 
Linker.
das 15224 geht auch fuer den 15214 .

Das File kommt von GCB .

das Linker file

chris schrieb:
> den 15214 habe ich auch, muss ihn aber erst raussuchen, poste das
> File
> asap.

Ich danke Dir, werde es testen.

W.S. schrieb:
> Ohneela Ssma schrieb:
>> Womit beweist Du dann Deine Genialität? ;)
>
> Oh, nee, laß mal!
>
> Ich benutze seit etwa 30 Jahren die PIC's und der damalige Assembler
> "PICALC" von Microchip hat mich bereits damals so sehr ange*****, daß
> ich mir einen eigenen Assembler geschrieben habe. Den benutze ich noch
> immer, wenngleich auch mit der Zeit ein bissel aktualisiert (DOS-->Win32
> usw.). Es ist kein aufgeblähtes Programm, sondern eher spartanisch:
> Quelle rein, Hexdatei raus.

Bei mir wars Ende '95 der Parallax-'Assembler' (von Wilke...)
Kennt den noch jemand?
Aber auf die Idee, mir einen eigenen Assembler zu schreiben bin ich 
nicht gekommen.

W.S. schrieb:
> chris schrieb:
> Also ist das eher heiße Luft mit der Bemerkung "den 16F15214 benutzen; von
> MPASMX nicht mehr unerstützt". Es fehlen wohl nur die Namen der
> vorhandenen Register. Oder??

Ja, das ist die Frage. Als ich in MPLAB ein Projekt für den 16F15214 
startete, kam die Meldung, dass dieser MC nicht von MPAMX unterstütz 
wird.
Nur weil .inc und .lkr nicht vorhanden sind? Auch hat er 50, statt der 
häufigeren 49 Befehle.
Werde es testen, muss erst Zeit freischaufeln...
Danke für die Überlegungen.

Ohneela Ssma schrieb:
> Aber auf die Idee, mir einen eigenen Assembler zu schreiben bin ich
> nicht gekommen.

Naja, das ist oftmals nur eine Frage der Höhe des Leidensdruckes relativ 
zu den eigenen Fähigkeiten.

Was mir von damals noch so in Erinnerung über den "Picalc" ist, sind 
erstmal das Fehlen von Segmenten. Die PIC16 sind ja keine v.Neumann 
Architekturen, sondern Harvard. Damit kommen Quereleien auf, wenn Marken 
definiert werden, die sich auf verschiedene Adreßräume beziehen. Also 
sollte ein Assembler zwischen den verschiedenen Adreßräumen (Code und 
Ram) unterscheiden können. Das ermöglicht dann auch sinnvolle 
Variablendeklarationen anstelle von fehlerträchtigen EQU Anweisungen:
Beispiel:
             DSEG
             ORG    20h
TuneStart:   DS     6       ; (ulong) Startwert für DDS-Tuningword
TuneCurrent: DS     6       ; (ulong) momentanes DDS-Tuningword
StepSize:    DS     6       ; (ulong) Schrittweite
MaxSteps:    DS     2       ; (word)  Anzahl gewünschter Schritte
CurrentStep: DS     2       ; (word)  momentaner Step


Als nächstes gab es eine elende Schwachstelle bei den Bit-Operationen. 
Ein benanntes Bit steht eben in einem bestimmten Register, so z.B. das 
Carry eben nur im Statusregister und sonst nirgends. Aber bei den 
üblichen Bit-Operationen muß das betreffende Register immer mit 
angegeben werden. Das kann eine Fehlerursache werden, wenn man mal etwas 
verwechselt. Obendrein verschlechtert es die Lesbarkeit der Quelle. 
Daher empfinde ich es weitaus naheliegender, wenn der Assembler selbst 
die richtige Zuordnung erledigt.
Beispiel:
T0CKI:  BIT PortA,4    ; OC out, sonst Takteingang wenn T0 als Zähler

und im folgenden wird nur T0CKI als Argument benutzt:
   SKIP T0CKI
   GOTO TaktIstLow
   ...
Naja, das waren nur zwei der Dinge, die mir damals aufgestoßen waren. Ob 
der gegenwärtige Assembler von Microchip das immer noch so hält, weiß 
ich nicht.

W.S.

W.S. schrieb:
> Naja, das ist oftmals nur eine Frage der Höhe des Leidensdruckes relativ
> zu den eigenen Fähigkeiten.

Schön formul- und treffend analys-iert:
'anpassungsfähig' mit eher durchschnittlichen Fähigkeiten. ;)

Hihi, Deine beiden Beispiele verstehe ich nicht mal, geschweige denn, 
dass ich mich an ihnen gestoßen hätte... kenne 'Picalc' aber nicht
Aber, alles funktioniert wie gewollt.
Bin assemblertechnisch wohl eher barfuß unterwegs; Probleme macht das 
'Drumrum'

Der Rest hatte noch keinen Test; erstmal ist der 617 dran...

Ohneela Ssma schrieb:
> Hihi, Deine beiden Beispiele verstehe ich nicht mal,...

Also was eine Harvard-Architektur im Gegensatz zu einer 
v.Neumann-Architektur ist, weißt du gewiß. PIC10, PIC16, PIC18 sind 
alles Harvard. Da hat man getrennte Adreßräume für Code und Daten, 
sprich ROM und RAM. Beide Adreßräume fangen bei 0 an, aber eine Marke im 
Code hat nix zu tun mit einer Marke in den Variablen. Folglich sollte 
man das ordentlich auseinander halten.

Und was die Bit-Operationen betrifft, da haben wir zwar dedizierte 
Befehle dafür (BSR, BCR, BTFSS und BTFSC), aber die originale Syntax von 
Microchip war so, daß dort sowohl das Register als auch die Bitnummer 
angegeben werden mußte. Also "BSR Register,Bit" und das ist zum einen 
fehlerträchtig als auch ein bissel idiotisch. Es ist ja nicht so, daß es 
wie z.B. beim ARM keine Bitbefehle gibt und man da als Gegenstück zu 
obigem mit arithmetischen Masken arbeiten muß: Register:= Register or 
(1<<Bitnummer)

W.S.

W.S. schrieb:
> Also was eine Harvard-Architektur im Gegensatz zu einer
> v.Neumann-Architektur ist...
>Und was die Bit-Operationen betrifft...

OK, ich weiß was Du meinst. Wobei das RAM ja nicht bei 0 beginnt; 
SFRs...
Da hatte ich noch nie Probleme.
Und was den 2. Punkt betrifft: sowas wie '#define FET LATA,0 - BSF FET' 
ging ja schon immer. Was mich nervt: bei den neueren PICs hat man ja das 
Gefühl, bei 70% aller SFR-Zugriffe BANKSEL verwenden zu müssen. (z.B. 
64! Bänke...) Warum werden einem bei nachfolgenden Bit- oder 
Byte-Befehlen nicht alle SFRs dieser Bank angezeigt?

Und zur Ausgangsfrage: Trotz des Kopierens der INC- bzw. LKR-Files in 
die entsprechenden Ordner sind weder mpasm, noch gpasm zu einer 
Futterspende für den 16F15214 bereit. 'unknown processor'. Bei gpasm 
explizit mit einer Auflistung der unterstützten MCs. Beide Programme 
scheinen eine Liste der unterstützten MCs zu beinhalten. Oder kann 
jemand Erfolg vermelden?
Habe mir vorläufig mit der Verwendung von PIC-AS im absoluten Modus 
geholfen; bis ich Zeit und Lust habe, 'psect' zu durchdringen...

Gruß

Ohneela Ssma schrieb:
> Beide Programme
> scheinen eine Liste der unterstützten MCs zu beinhalten.

Wenn ich deinen Text so lese, dann bin ich heilfroh, dem mit eigenem 
Zeugs entgangen zu sein.

W.S.

W.S. schrieb:
> Wenn ich deinen Text so lese, dann bin ich heilfroh, dem mit eigenem
> Zeugs entgangen zu sein.

Naja, ohne ständig neu zu lernen klappt ja sowieso wenig...
Wie lange hast Du denn gebraucht, um z.B. den Wegfall der RP-Bits in 
STATUS hin zum BSR-Register zu integrieren?
Und normaler Weise wühle ich mich auch alleine durch den für mich 
nötigen Kram, war aber jetzt aufgrund der Nichtverfügbarkeit etlicher 
PICs ein wenig in Zeitnot... ;)

Ohneela Ssma schrieb:
> Wie lange hast Du denn gebraucht, um z.B. den Wegfall der RP-Bits in
> STATUS hin zum BSR-Register zu integrieren?

Gar nicht. Der Assembler kennt nur die (Pseudo-)Befehle CORE10. CORE14, 
CORE16 um die richtigen Maschinencodes zu erzeugen und alles übrige, 
auch die Deklaration der diversen Bits steht in einer Datei, die man in 
der Quelldatei inkludiert und die man für einen neuen PIC sich selber 
schreibt. Dieses Konzept ist ein ganzes Stück pflegeleichter, als das, 
was MicroChip macht. Allerdings habe ich mich dabei nicht um die PIC24 
und PIC32 gekümmert und der ganze Assembler ist ein eher einfaches 
Programm: Quelle rein, Hex raus, Übersetzungsliste ebenfalls raus. 
Fertig.

W.S.

W.S. schrieb:
> Gar nicht. Der Assembler kennt nur die (Pseudo-)Befehle CORE10. CORE14,
> CORE16 um die richtigen Maschinencodes zu erzeugen und alles übrige,
> auch die Deklaration der diversen Bits steht in einer Datei, die man in
> der Quelldatei inkludiert und die man für einen neuen PIC sich selber
> schreibt.

OK, verstehe. Aber, um beim 16F15214 zu bleiben, dieses File für über 
100 SFRs, mit, sagen wir je, 4 Bits, schreibt sich ja nicht in einer 
halben Stunde; selbst wenn Du auf Bestehendem aufbaust. (zumal sich 
Register und Bits im Namen und der Adresse geändert haben...) (auch 
PIC-AS kennt einige 'seiner' Bits nicht, z.B. 'T1CLK, ON' (= ...,0 ...))
Und die verfügbaren Befehle des jeweiligen MCs stehen auch in diesem 
File?
Ich schwanke noch; vielleicht frage ich ja an, ob Du verkaufst... ;)

Peter D. schrieb:
> Ich finde das beim 8051 deutlich einfacher gelöst.

Und was - bittesehr?

Ich mache das so ähnlich wie du beim 8051, nur mit der Erweiterung, daß 
der Assembler mehrere Befehlssätze kann. Für den konkreten Typ 
interessiert sich mein kleiner Assembler überhaupt nicht - aber das ist 
anders als bei den Programmen von MicroChip. Die wollen den konkreten 
Typ wissen und eben damit hat der TO seine mir durchaus verständlichen 
Probleme.

W.S.

Ohneela Ssma schrieb:
> Ich schwanke noch;

Und wohin?

Bevor du dir einen eigenen Assembler schreibst oder ich den meinigen 
hier mal poste, lies erstmal die angehängte Übersetzungsliste, um zu 
sehen, ob er dir überhaupt gefällt. Ich hatte die Quellen für meinen 
kleinen Taschen-Frequenzzähler vor geraumer Zeit hier schon mal 
gepostet, ebenso vor noch längerer Zeit die Schaltung, also nimm die 
angehängte Ü-Liste nur als Geschmacksprobe.

W.S.

Peter D. schrieb:
> Ich finde das beim 8051 deutlich einfacher gelöst. Die 8051 habe
> ja alle die gleiche Architektur...

Sorry, ich weiß über das Teil wenig mehr als das es existiert.
Es geht hier ja auch nicht um die Hardware; der 'CPU-Teil' der 8-bitigen 
PICs ist ja auch relativ identisch.

W.S. schrieb:
> Und wohin?
Na, schwanken eben; rechts-links, vor-zurück... ;)

> lies erstmal die angehängte Übersetzungsliste
Ließt sich flüssig und vertraut.
Erst über Dein 'SKIP bzw. SKIP NOT' gestolpert... ;)
Vielleicht '-SKIP'für 'DECFSZ'?...
Was ich allerdings für wirklich problematisch halte: bei den neueren 
PICs ist das manuelle setzen der RP-Bits keine Option, z.B. 32 oder 64 
Bänke mit den dazugehörigen SFRs auswendig zu kennen ist kaum möglich.
Hast Du eine Idee dazu? (oder schon realisiert?...)

gputils ist recht gut. hat sehr viele header (bis PIC18 glaube ich).
und macht objekt dateien, was bei groesseren sachen doch sehr hilfreich 
ist.
Ausserdem läufts auf jedem dreck.
Die geschichte mit den banksels machst du am besten mit makros die dir 
das banksel zusammen mit der zuweisung machen. Mit function calls isses 
ähnlich.
Eins von den FSR registern benutzt du als stack pointer, und das common 
ram oder einen teil davon als general purpose registers (keine 
banksels).

Johann Klammer schrieb:
> Die geschichte mit den banksels machst du am besten mit makros die dir
> das banksel zusammen mit der zuweisung machen. Mit function calls isses
> ähnlich.

Nein, eben NICHT so. Der Grund für solch vehemente Ablehnung ist das 
erhebliche Aufblasen des Codes. Wer für jeden Variablenzugriff 
automatisch noch ein banksel zufügt, ersäuft in dem Meer von 
Bankselects. Ich hatte mir mal überlegt, im Assembler ein automatisches 
Mitdenken über den Stand von sowas einzubauen, hab das dann aber lieber 
bleiben gelassen.

Ohneela Ssma schrieb:
> Vielleicht '-SKIP'für 'DECFSZ'?...

Eher DECFSS. Das Pendant zum DECFSZ wäre SKIP NOT Bitname.
Aber es gehen auch alle originalen Mnemonics. Auch hier hatte ich mal 
überlegt, eventuell alle DECFSx Register,Nummer durch SKIP und SKIP NOT 
zu ersetzen, hab's dann aber bleiben gelassen. Die Argumente für SKIP 
sind Bits mit Namen, die per EinName: BIT EinRegister,EineBitnummer 
deklariert worden sind.

Ohneela Ssma schrieb:
> bei den neueren
> PICs ist das manuelle setzen der RP-Bits keine Option, z.B. 32 oder 64
> Bänke mit den dazugehörigen SFRs auswendig zu kennen ist kaum möglich.

Sehe ich auch so. Allerdings ist das bei all den älteren und kleineren 
PICs mit nur wenigen Bänken ganz anders. Und offen gesagt benutze ich 
für größere Projekte keinen PIC. Dafür gibt es andere Plattformen. Ich 
meine, daß bei mehr als 256 Byte RAM (incl. Register) die 
PIC-Architektur bereits überfordert ist. Man sollte die Kirche im Dorf 
lassen.

W.S.

W.S. schrieb:
>Ich hatte mir mal überlegt, im Assembler ein automatisches
> Mitdenken über den Stand von sowas einzubauen, hab das dann aber lieber
> bleiben gelassen.
Das wäre auch Wahnsinn... spätestens mit mehreren, zeitlich unabhängigen 
Interrupts von 'außen'...

> Eher DECFSS. Das Pendant zum DECFSZ wäre SKIP NOT Bitname.
> Aber es gehen auch alle originalen Mnemonics. Auch hier hatte ich mal
> überlegt, eventuell alle DECFSx Register,Nummer durch SKIP und SKIP NOT
> zu ersetzen...
;) Nee, da warst Du jetzt auf dem falschen Dampfer... DECFSS gibts 
nicht, sind ja Byte-Befehle...
Also '-SKIP0 und +SKIP0' für 'DECFSZ bzw. INCFSZ'
Und 'SKIP und SKIP NOT' für BTFSS bzw. BTFSC...  ;)

> Sehe ich auch so. Allerdings ist das bei all den älteren und kleineren
> PICs mit nur wenigen Bänken ganz anders. Und offen gesagt benutze ich
> für größere Projekte keinen PIC. Dafür gibt es andere Plattformen.
'Größere' Sachen benutze ich nur privat, ansonsten 8 Bit, 8 Beine... ;)
Den 16F18313 finde ich richtig klasse, der 16F15214 hingegen nervt 
leicht.
Die Idee mit den 12 Core-Registern und den 16 Common-RAMs ist ja schon 
ganz gut, aber eben optimiert für den C-Compiler...

Ohneela Ssma schrieb:
> ;) Nee, da warst Du jetzt auf dem falschen Dampfer...

Ja, sorry.
Ähem, nochmal das Ganze:
BTFSS Reg,Bit  und Äquivalent SKIP Bit
BTFSC Reg,Bit  und Äquivalent SKIP NOT Bit

Hab mal grad geschaut: Die letzte Änderung des Assemblers ist rund 10 
Jahre her. Da hatte ich die PIC18 eingebaut, aber nie benutzt.

W.S.