Hallo, wie vermutlich bei nicht ganz wenigen Dingen im Leben alles nur eine Frage der Gewöhnung, aber : PIC-AS nervt mich mächtig. Will im Moment den 16F15214 benutzen; von MPASMX nicht mehr unerstützt. 2 Fragen: 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 macht zwar viele tolle Fehler, aber keinen tollen Code. How? Funktioniert es, sich eine eigene .inc-Datei für den MC zu schreiben? (so als 'kurzfristige Lösung'...) Danke
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.
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 .
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... ;)
Ich finde das beim 8051 deutlich einfacher gelöst. Die 8051 habe ja alle die gleiche Architektur, d.h. der Assembler muß überhaupt nicht wissen, welchen konkreten Typ man programmiert. Symbole werden über ein Include bekannt gemacht und das wars. Man kann also leicht neue Typen hinzufügen. Ich benutze z.B. noch immer den Keil A51 von 1995 und habe schon mehrfach neue Typen hinzugefügt. Oftmals findet man aber auch im Web passende oder ähnliche Includes zum Download. Das gleiche gilt für den C-Compiler C51, den interessiert auch nicht der konkrete Typ. Das passende .h-File downloaden oder selber editieren und alles läuft.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.